Add netfornt tx_queue_len

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

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

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

# HG changeset patch
# User [email protected]
# Date 1168940841 -32400
# Node ID 64ceac593b7a1a65e33726e6d4beba686633ff30 # Parent c6b683ba68f5417a5b397d8530edd9df14ad586c fix short_message of UDP error

diff -r c6b683ba68f5 -r 64ceac593b7a linux-2.6-xen-sparse/drivers/xen/netfront/netfront.c
@@ -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);

_______________________________________________
Xen-ia64-devel mailing list
[email protected]
http://lists.xensource.com/xen-ia64-devel

Sorry, but this patch looks bogus. The tx queue is maintained by Linux and has nothing to do with the driver. So limiting its length based on internal state of the driver can't be right.

We need to find out what's really going wrong with the grant table entries here.

Cheers,

Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Hi Herbert-san

Thank you for your comment.

I agreed.
I examine the another way.

It is likely to go well if something is added to the check on netfront_tx_slot_available().

Best regards.

Tomonari Horikoshi,

Herbert Xu wrote:----------------------

Sent:    Wed, 24 Jan 2007 13:29:51 +1100
Subject: Re: [Xen-devel] [PATCH] Add netfornt tx_queue_len