All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomonari Horikoshi <t.horikoshi@jp.fujitsu.com>
To: xen-devel <xen-devel@lists.xensource.com>
Cc: xen-ia64-devel <xen-ia64-devel@lists.xensource.com>
Subject: [PATCH] Add netfornt tx_queue_len
Date: Wed, 24 Jan 2007 10:37:55 +0900	[thread overview]
Message-ID: <3DC73F584529FAt.horikoshi@jp.fujitsu.com> (raw)

[-- Attachment #1: Mail message body --]
[-- Type: text/plain, Size: 1590 bytes --]



Thank you for your comment. ( -> Isaku Yamahata)

Isaku Yamahata wrote:----------------------
Sent:    Tue, 23 Jan 2007 22:29:47 +0900
Subject: Re: [Xen-ia64-devel] [PATCH] Add netfornt tx_queue_len

> 
> The patch modifis common-code, not ia64 specific.
> You should send it to xen-devel with Cc to xen-ia64-devel.
> 


----------------------------------------------

Hi all.

When I executed "netperf" by a short message of UDP, 
PV domain and PV-on-HVM driver issued Call trace.

I think that GrantEntry was filled with a lot of messages processings.

This problem is generated in IA64 only.
Probably, I think that I am the following problems. 

  In IA64
    NET_TX_RING_SIZE 1024,  NR_GRANT_ENTRIES 2048
  In x86
    NET_TX_RING_SIZE  256,  NR_GRANT_ENTRIES 2048

I corrected to check "number of unprocessing queue > tx_queue_len" before Grant was filled.

However, my correction influences x86. 
Please teach to me in that when there is a better improvement. 

--------------------

# ./netperf -t UDP_STREAM -H 10.34.179.101 -l 3 -- -m 10 -M 10

netperf[2474]: bugcheck! 0 [1]
Modules linked in:

Pid: 2474, CPU 0, comm:              netperf
psr : 00001010081a2010 ifs : 8000000000000b9b ip  : [<a0000001006c9ce0>]    Not tainted
ip is at network_start_xmit+0xa00/0xe40
unat: 0000000000000000 pfs : 8000000000000b9b rsc : 000000000000000b
rnat: 0000000000000000 bsps: 0000000000000000 pr  : 0104682415669999
ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c8a70033f
csd : 0000000000000000 ssd : 0000000000000000


--------------------

Best regards,
Tomonari Horikoshi


[-- Attachment #2: tx-queue-len-support.patch --]
[-- Type: application/octet-stream, Size: 2278 bytes --]

# HG changeset patch
# User root@vmi06.sky.yk.fujitsu.co.jp
# Date 1168940841 -32400
# Node ID 64ceac593b7a1a65e33726e6d4beba686633ff30
# Parent  c6b683ba68f5417a5b397d8530edd9df14ad586c
fix short_message of UDP error

Signed-off-by: Tomonari Horikoshi <t.horikoshi@jp.fujitsu.com>
Signed-off-by: Hirofumi Tsujimura <tsujimura.hirof@jp.fujitsu.com>

diff -r c6b683ba68f5 -r 64ceac593b7a linux-2.6-xen-sparse/drivers/xen/netfront/netfront.c
--- a/linux-2.6-xen-sparse/drivers/xen/netfront/netfront.c	Sun Jan 14 22:18:38 2007 -0700
+++ b/linux-2.6-xen-sparse/drivers/xen/netfront/netfront.c	Tue Jan 16 18:47:21 2007 +0900
@@ -82,9 +82,15 @@ static int MODPARM_rx_flip = 0;
 static int MODPARM_rx_flip = 0;
 module_param_named(rx_flip, MODPARM_rx_flip, bool, 0);
 MODULE_PARM_DESC(rx_flip, "Flip packets from network card (rather than copy)");
+static int MODPARM_tx_queue_len = 256;
+module_param_named(tx_queue_len, MODPARM_tx_queue_len, int, 0);
+MODULE_PARM_DESC(tx_queue_len, "Tx limit queue size.");
 #else
 static const int MODPARM_rx_copy = 1;
 static const int MODPARM_rx_flip = 0;
+static int MODPARM_tx_queue_len = 256;
+module_param_named(tx_queue_len, MODPARM_tx_queue_len, int, 0);
+MODULE_PARM_DESC(tx_queue_len, "Tx limit queue size.");
 #endif
 
 #define RX_COPY_THRESHOLD 256
@@ -613,7 +619,7 @@ static int network_open(struct net_devic
 
 static inline int netfront_tx_slot_available(struct netfront_info *np)
 {
-	return RING_FREE_REQUESTS(&np->tx) >= MAX_SKB_FRAGS + 2;
+	return MODPARM_tx_queue_len >= (np->tx.sring->req_event - np->tx.req_prod_pvt);
 }
 
 static inline void network_maybe_wake_tx(struct net_device *dev)
@@ -1695,6 +1701,7 @@ static int network_connect(struct net_de
 
 	IPRINTK("device %s has %sing receive path.\n",
 		dev->name, np->copying_receiver ? "copy" : "flipp");
+	IPRINTK("tx queue len of device %s is %d.\n", dev->name, MODPARM_tx_queue_len);
 
 	spin_lock_irq(&np->tx_lock);
 	spin_lock(&np->rx_lock);
@@ -1983,6 +1990,7 @@ static struct net_device * __devinit cre
 	netdev->uninit          = netif_uninit;
 	netdev->change_mtu	= xennet_change_mtu;
 	netdev->weight          = 64;
+	netdev->tx_queue_len    = MODPARM_tx_queue_len;
 	netdev->features        = NETIF_F_IP_CSUM;
 
 	SET_ETHTOOL_OPS(netdev, &network_ethtool_ops);

[-- Attachment #3: Type: text/plain, Size: 152 bytes --]

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel

             reply	other threads:[~2007-01-24  1:37 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-24  1:37 Tomonari Horikoshi [this message]
2007-01-24  2:29 ` [PATCH] Add netfornt tx_queue_len Herbert Xu
2007-01-25  4:44   ` [Xen-devel] " Tomonari Horikoshi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3DC73F584529FAt.horikoshi@jp.fujitsu.com \
    --to=t.horikoshi@jp.fujitsu.com \
    --cc=xen-devel@lists.xensource.com \
    --cc=xen-ia64-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.