netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 2.6.34-rc6] net: Improve ks8851 snl transmit performance
@ 2010-05-06 22:50 Ha, Tristram
  2010-05-07  5:02 ` Arce, Abraham
  2010-05-16  7:26 ` David Miller
  0 siblings, 2 replies; 8+ messages in thread
From: Ha, Tristram @ 2010-05-06 22:50 UTC (permalink / raw)
  To: Ben Dooks; +Cc: David Miller, netdev, linux-kernel, Abraham Arce, Sebastien Jan

From: Tristram Ha <Tristram.Ha@micrel.com>

Under heavy transmission the driver will put 4 1514-byte packets in queue and stop the device transmit queue.  Only the last packet triggers the transmit done interrupt and wakes up the device transmit queue.  That means a bit of time is wasted when the CPU cannot send any more packet.

The new implementation triggers the transmit interrupt when the transmit buffer left is less than 3 packets.  The maximum transmit buffer size is 6144 bytes.  This allows the device transmit queue to be restarted sooner so that CPU can send more packets.

For TCP receiving it also has the benefit of not triggering any transmit interrupt at all.

There is a driver option no_tx_opt so that the driver can revert to original implementation.  This allows user to verify if the transmit performance actually improves.

Signed-off-by: Tristram Ha <Tristram.Ha@micrel.com>
---
This replaces the [patch 01/13] patch I submitted and was objected by David.

Other users with Micrel KSZ8851 SNL chip please verify the transmit performance does improve or not.

--- a/drivers/net/ks8851.c	2010-04-29 20:02:05.000000000 -0700
+++ b/drivers/net/ks8851.c	2010-05-06 15:30:40.000000000 -0700
@@ -74,6 +74,9 @@ union ks8851_tx_hdr {
  * @rxd: Space for receiving SPI data, in DMA-able space.
  * @txd: Space for transmitting SPI data, in DMA-able space.
  * @msg_enable: The message flags controlling driver output (see ethtool).
+ * @tx_space: The current available transmit buffer size.
+ * @tx_avail: The maximum available transmit buffer size.
+ * @tx_chk_cnt: Used to indicate how often to check the transmit buffer.
  * @fid: Incrementing frame id tag.
  * @rc_ier: Cached copy of KS_IER.
  * @rc_rxqcr: Cached copy of KS_RXQCR.
@@ -103,6 +106,8 @@ struct ks8851_net {
 
 	u32			msg_enable ____cacheline_aligned;
 	u16			tx_space;
+	u16			tx_avail;
+	u8			tx_chk_cnt;
 	u8			fid;
 
 	u16			rc_ier;
@@ -124,6 +129,7 @@ struct ks8851_net {
 };
 
 static int msg_enable;
+static int no_tx_opt;
 
 #define ks_info(_ks, _msg...) dev_info(&(_ks)->spidev->dev, _msg)
 #define ks_warn(_ks, _msg...) dev_warn(&(_ks)->spidev->dev, _msg)
@@ -580,10 +586,21 @@ static void ks8851_irq_work(struct work_
 
 		/* update our idea of how much tx space is available to the
 		 * system */
+		ks->tx_chk_cnt = 0;
 		ks->tx_space = ks8851_rdreg16(ks, KS_TXMIR);
 
 		if (netif_msg_intr(ks))
 			ks_dbg(ks, "%s: txspace %d\n", __func__, ks->tx_space);
+
+	/* Update tx space when packets are being transmitted. */
+	} else if (ks->tx_space < ks->tx_avail) {
+		ks->tx_chk_cnt++;
+
+		/* Read the transmit buffer register every 4th rx interrupt. */
+		if (4 == ks->tx_chk_cnt) {
+			ks->tx_chk_cnt = 0;
+			ks->tx_space = ks8851_rdreg16(ks, KS_TXMIR);
+		}
 	}
 
 	if (status & IRQ_RXI)
@@ -715,6 +732,7 @@ static void ks8851_tx_work(struct work_s
 	struct ks8851_net *ks = container_of(work, struct ks8851_net, tx_work);
 	struct sk_buff *txb;
 	bool last = skb_queue_empty(&ks->txq);
+	bool tx_irq;
 
 	mutex_lock(&ks->lock);
 
@@ -724,7 +742,11 @@ static void ks8851_tx_work(struct work_s
 
 		if (txb != NULL) {
 			ks8851_wrreg16(ks, KS_RXQCR, ks->rc_rxqcr | RXQCR_SDA);
-			ks8851_wrpkt(ks, txb, last);
+			if (ks->tx_avail)
+				tx_irq = (CHECKSUM_UNNECESSARY == txb->ip_summed);
+			else
+				tx_irq = last;
+			ks8851_wrpkt(ks, txb, tx_irq);
 			ks8851_wrreg16(ks, KS_RXQCR, ks->rc_rxqcr);
 			ks8851_wrreg16(ks, KS_TXQCR, TXQCR_METFE);
 
@@ -917,11 +939,17 @@ static netdev_tx_t ks8851_start_xmit(str
 		ret = NETDEV_TX_BUSY;
 	} else {
 		ks->tx_space -= needed;
+		/*
+		 * Indicate to enable transmit done interrupt when transmit
+		 * buffer is less than a certain size.
+		 */
+		if (ks->tx_avail && ks->tx_space < 1514 * 3)
+			skb->ip_summed = CHECKSUM_UNNECESSARY;
 		skb_queue_tail(&ks->txq, skb);
+		schedule_work(&ks->tx_work);
 	}
 
 	spin_unlock(&ks->statelock);
-	schedule_work(&ks->tx_work);
 
 	return ret;
 }
@@ -1224,7 +1252,6 @@ static int __devinit ks8851_probe(struct
 
 	ks->netdev = ndev;
 	ks->spidev = spi;
-	ks->tx_space = 6144;
 
 	mutex_init(&ks->lock);
 	spin_lock_init(&ks->statelock);
@@ -1279,6 +1306,10 @@ static int __devinit ks8851_probe(struct
 		goto err_id;
 	}
 
+	ks->tx_space = ks8851_rdreg16(ks, KS_TXMIR);
+	if (!no_tx_opt)
+		ks->tx_avail = ks->tx_space;
+
 	ks8851_read_selftest(ks);
 	ks8851_init_mac(ks);
 
@@ -1351,6 +1382,8 @@ MODULE_DESCRIPTION("KS8851 Network drive
 MODULE_AUTHOR("Ben Dooks <ben@simtec.co.uk>");
 MODULE_LICENSE("GPL");
 
+module_param(no_tx_opt, int, 0);
+MODULE_PARM_DESC(message, "No TX optimization");
 module_param_named(message, msg_enable, int, 0);
 MODULE_PARM_DESC(message, "Message verbosity level (0=none, 31=all)");
 MODULE_ALIAS("spi:ks8851");

^ permalink raw reply	[flat|nested] 8+ messages in thread

* RE: [PATCH 2.6.34-rc6] net: Improve ks8851 snl transmit performance
  2010-05-06 22:50 [PATCH 2.6.34-rc6] net: Improve ks8851 snl transmit performance Ha, Tristram
@ 2010-05-07  5:02 ` Arce, Abraham
  2010-05-13  5:38   ` Ha, Tristram
  2010-05-16  7:26 ` David Miller
  1 sibling, 1 reply; 8+ messages in thread
From: Arce, Abraham @ 2010-05-07  5:02 UTC (permalink / raw)
  To: Ha, Tristram, Ben Dooks
  Cc: David Miller, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, Jan, Sebastien

Hi,

[snip]

> There is a driver option no_tx_opt so that the driver can revert to original
> implementation.  This allows user to verify if the transmit performance
> actually improves.

Should we limit patch description to 80 characters also?

> Signed-off-by: Tristram Ha <Tristram.Ha@micrel.com>
> ---
> This replaces the [patch 01/13] patch I submitted and was objected by David.
> 
> Other users with Micrel KSZ8851 SNL chip please verify the transmit
> performance does improve or not.

Tested-by: Abraham Arce <x0066660@ti.com>

Executing some nuttcp scenarios:

- Without Patch -

# /testsuites/ethernet/bin/nuttcp -u -i -Ri50m <serverip>
 1.2676 MB /   1.00 sec =   10.6330 Mbps     0 /  1298 ~drop/pkt  0.00 ~%loss
 1.2705 MB /   1.00 sec =   10.6579 Mbps     0 /  1301 ~drop/pkt  0.00 ~%loss
 1.2686 MB /   1.00 sec =   10.6414 Mbps     0 /  1299 ~drop/pkt  0.00 ~%loss
 1.2695 MB /   1.00 sec =   10.6496 Mbps     0 /  1300 ~drop/pkt  0.00 ~%loss
 1.2695 MB /   1.00 sec =   10.6496 Mbps     0 /  1300 ~drop/pkt  0.00 ~%loss
 1.2686 MB /   1.00 sec =   10.6414 Mbps     0 /  1299 ~drop/pkt  0.00 ~%loss
 1.2686 MB /   1.00 sec =   10.6414 Mbps     0 /  1299 ~drop/pkt  0.00 ~%loss
 1.2646 MB /   1.00 sec =   10.6086 Mbps     0 /  1295 ~drop/pkt  0.00 ~%loss
 1.2686 MB /   1.00 sec =   10.6412 Mbps     0 /  1299 ~drop/pkt  0.00 ~%loss
 1.2695 MB /   1.00 sec =   10.6498 Mbps     0 /  1300 ~drop/pkt  0.00 ~%loss

12.7314 MB /  10.02 sec =   10.6637 Mbps 4 %TX 0 %RX 0 / 13037 drop/pkt 0.00 %loss

- With Patch -

# /testsuites/ethernet/bin/nuttcp -u -i -Ri50m 10.87.231.229
    1.2891 MB /   1.00 sec =   10.8133 Mbps     0 /  1320 ~drop/pkt  0.00 ~%loss
    1.2900 MB /   1.00 sec =   10.8217 Mbps     0 /  1321 ~drop/pkt  0.00 ~%loss
    1.2900 MB /   1.00 sec =   10.8217 Mbps     0 /  1321 ~drop/pkt  0.00 ~%loss
    1.2910 MB /   1.00 sec =   10.8298 Mbps     0 /  1322 ~drop/pkt  0.00 ~%loss
    1.2910 MB /   1.00 sec =   10.8299 Mbps     0 /  1322 ~drop/pkt  0.00 ~%loss
    1.2900 MB /   1.00 sec =   10.8216 Mbps     0 /  1321 ~drop/pkt  0.00 ~%loss
    1.2900 MB /   1.00 sec =   10.8216 Mbps     0 /  1321 ~drop/pkt  0.00 ~%loss
    1.2891 MB /   1.00 sec =   10.8135 Mbps     0 /  1320 ~drop/pkt  0.00 ~%loss
    1.2900 MB /   1.00 sec =   10.8216 Mbps     0 /  1321 ~drop/pkt  0.00 ~%loss
    1.2910 MB /   1.00 sec =   10.8298 Mbps     0 /  1322 ~drop/pkt  0.00 ~%loss

   12.9492 MB /  10.02 sec =   10.8461 Mbps 4 %TX 0 %RX 0 / 13260 drop/pkt 0.00
%loss

Also simulated heavy transmission consisting of 40 processes executed in parallel:

 - 20 ping instances using packet size of 32768
 - 20 dd instances creating a 50MB file each under the nfs rootfs

If any specific test scenario/application is required please do let me know...

Best Regards
Abraham

^ permalink raw reply	[flat|nested] 8+ messages in thread

* RE: [PATCH 2.6.34-rc6] net: Improve ks8851 snl transmit performance
  2010-05-07  5:02 ` Arce, Abraham
@ 2010-05-13  5:38   ` Ha, Tristram
  2010-05-13 23:39     ` Arce, Abraham
  2010-05-14 23:22     ` Bill Fink
  0 siblings, 2 replies; 8+ messages in thread
From: Ha, Tristram @ 2010-05-13  5:38 UTC (permalink / raw)
  To: Arce, Abraham, Ben Dooks
  Cc: David Miller, netdev, linux-kernel, Jan, Sebastien

I use a web browser to send patches through my company's e-mail system.  The message is composed by cut and paste, so it may not conform to Linux standard.

The latest nuttcp default size for UDP is 1500 bytes, rather than 8192 bytes.  In my case, the transmit performance improves from 10 Mbps to 11.  Have you tried TCP?


-----Original Message-----
From: Arce, Abraham [mailto:x0066660@ti.com]
Sent: Thu 5/6/2010 10:02 PM
To: Ha, Tristram; Ben Dooks
Cc: David Miller; netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Jan, Sebastien
Subject: RE: [PATCH 2.6.34-rc6] net: Improve ks8851 snl transmit performance
 
Hi,

[snip]

> There is a driver option no_tx_opt so that the driver can revert to original
> implementation.  This allows user to verify if the transmit performance
> actually improves.

Should we limit patch description to 80 characters also?

> Signed-off-by: Tristram Ha <Tristram.Ha@micrel.com>
> ---
> This replaces the [patch 01/13] patch I submitted and was objected by David.
> 
> Other users with Micrel KSZ8851 SNL chip please verify the transmit
> performance does improve or not.

Tested-by: Abraham Arce <x0066660@ti.com>

Executing some nuttcp scenarios:

- Without Patch -

# /testsuites/ethernet/bin/nuttcp -u -i -Ri50m <serverip>
 1.2676 MB /   1.00 sec =   10.6330 Mbps     0 /  1298 ~drop/pkt  0.00 ~%loss
 1.2705 MB /   1.00 sec =   10.6579 Mbps     0 /  1301 ~drop/pkt  0.00 ~%loss
 1.2686 MB /   1.00 sec =   10.6414 Mbps     0 /  1299 ~drop/pkt  0.00 ~%loss
 1.2695 MB /   1.00 sec =   10.6496 Mbps     0 /  1300 ~drop/pkt  0.00 ~%loss
 1.2695 MB /   1.00 sec =   10.6496 Mbps     0 /  1300 ~drop/pkt  0.00 ~%loss
 1.2686 MB /   1.00 sec =   10.6414 Mbps     0 /  1299 ~drop/pkt  0.00 ~%loss
 1.2686 MB /   1.00 sec =   10.6414 Mbps     0 /  1299 ~drop/pkt  0.00 ~%loss
 1.2646 MB /   1.00 sec =   10.6086 Mbps     0 /  1295 ~drop/pkt  0.00 ~%loss
 1.2686 MB /   1.00 sec =   10.6412 Mbps     0 /  1299 ~drop/pkt  0.00 ~%loss
 1.2695 MB /   1.00 sec =   10.6498 Mbps     0 /  1300 ~drop/pkt  0.00 ~%loss

12.7314 MB /  10.02 sec =   10.6637 Mbps 4 %TX 0 %RX 0 / 13037 drop/pkt 0.00 %loss

- With Patch -

# /testsuites/ethernet/bin/nuttcp -u -i -Ri50m 10.87.231.229
    1.2891 MB /   1.00 sec =   10.8133 Mbps     0 /  1320 ~drop/pkt  0.00 ~%loss
    1.2900 MB /   1.00 sec =   10.8217 Mbps     0 /  1321 ~drop/pkt  0.00 ~%loss
    1.2900 MB /   1.00 sec =   10.8217 Mbps     0 /  1321 ~drop/pkt  0.00 ~%loss
    1.2910 MB /   1.00 sec =   10.8298 Mbps     0 /  1322 ~drop/pkt  0.00 ~%loss
    1.2910 MB /   1.00 sec =   10.8299 Mbps     0 /  1322 ~drop/pkt  0.00 ~%loss
    1.2900 MB /   1.00 sec =   10.8216 Mbps     0 /  1321 ~drop/pkt  0.00 ~%loss
    1.2900 MB /   1.00 sec =   10.8216 Mbps     0 /  1321 ~drop/pkt  0.00 ~%loss
    1.2891 MB /   1.00 sec =   10.8135 Mbps     0 /  1320 ~drop/pkt  0.00 ~%loss
    1.2900 MB /   1.00 sec =   10.8216 Mbps     0 /  1321 ~drop/pkt  0.00 ~%loss
    1.2910 MB /   1.00 sec =   10.8298 Mbps     0 /  1322 ~drop/pkt  0.00 ~%loss

   12.9492 MB /  10.02 sec =   10.8461 Mbps 4 %TX 0 %RX 0 / 13260 drop/pkt 0.00
%loss

Also simulated heavy transmission consisting of 40 processes executed in parallel:

 - 20 ping instances using packet size of 32768
 - 20 dd instances creating a 50MB file each under the nfs rootfs

If any specific test scenario/application is required please do let me know...

Best Regards
Abraham


^ permalink raw reply	[flat|nested] 8+ messages in thread

* RE: [PATCH 2.6.34-rc6] net: Improve ks8851 snl transmit performance
  2010-05-13  5:38   ` Ha, Tristram
@ 2010-05-13 23:39     ` Arce, Abraham
  2010-05-14 23:22     ` Bill Fink
  1 sibling, 0 replies; 8+ messages in thread
From: Arce, Abraham @ 2010-05-13 23:39 UTC (permalink / raw)
  To: Ha, Tristram, Ben Dooks
  Cc: David Miller, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, Jan, Sebastien

Tristram,

> The latest nuttcp default size for UDP is 1500 bytes, rather than 8192 bytes.
> In my case, the transmit performance improves from 10 Mbps to 11.  Have you
> tried TCP?
> 

Not yet... one point to highlight before:

  - SPI controller clock rate is 24 MHz, unable to set ~40 MHz, 

Now testing in 2.6.34 rc7 using now TCP, nuttcp version 6.1.2:

Before the patch

  # /testsuites/ethernet/bin/nuttcp -i -Ri50m 10.87.231.229
      1.1460 MB /   1.00 sec =    9.6134 Mbps
      1.1858 MB /   1.00 sec =    9.9473 Mbps
      1.2258 MB /   1.00 sec =   10.2828 Mbps
      1.1996 MB /   1.00 sec =   10.0628 Mbps
      1.2203 MB /   1.00 sec =   10.2365 Mbps
      1.2258 MB /   1.00 sec =   10.2828 Mbps
      1.2134 MB /   1.00 sec =   10.1786 Mbps
      1.2235 MB /   1.00 sec =   10.2636 Mbps
      1.2134 MB /   1.00 sec =   10.1785 Mbps
      1.2120 MB /   1.00 sec =   10.1670 Mbps

     12.6250 MB /  10.46 sec =   10.1240 Mbps 2 %TX 0 %RX 0 retrans 7.91 msRTT

  # /testsuites/ethernet/bin/nuttcp 10.87.231.229
     12.9319 MB /  10.58 sec =   10.2553 Mbps 1 %TX 0 %RX 0 retrans 7.90 msRTT

After the patch

  # /testsuites/ethernet/bin/nuttcp -i -Ri50m 10.87.231.229
      1.1671 MB /   1.00 sec =    9.7902 Mbps
      1.2169 MB /   1.00 sec =   10.2077 Mbps
      1.2175 MB /   1.00 sec =   10.2134 Mbps
      1.2396 MB /   1.00 sec =   10.3986 Mbps
      1.2396 MB /   1.00 sec =   10.3987 Mbps
      1.2387 MB /   1.00 sec =   10.3910 Mbps
      1.2410 MB /   1.00 sec =   10.4102 Mbps
      1.2203 MB /   1.00 sec =   10.2365 Mbps
      1.2382 MB /   1.00 sec =   10.3871 Mbps
      1.2369 MB /   1.00 sec =   10.3755 Mbps

     12.8125 MB /  10.45 sec =   10.2820 Mbps 2 %TX 0 %RX 0 retrans 7.90 msRTT

  # /testsuites/ethernet/bin/nuttcp 10.87.231.229
     13.0808 MB /  10.64 sec =   10.3123 Mbps 1 %TX 0 %RX 0 retrans 7.90 msRTT

Best Regards
Abraham

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 2.6.34-rc6] net: Improve ks8851 snl transmit performance
  2010-05-13  5:38   ` Ha, Tristram
  2010-05-13 23:39     ` Arce, Abraham
@ 2010-05-14 23:22     ` Bill Fink
  1 sibling, 0 replies; 8+ messages in thread
From: Bill Fink @ 2010-05-14 23:22 UTC (permalink / raw)
  To: Ha, Tristram
  Cc: Arce, Abraham, Ben Dooks, David Miller, netdev, linux-kernel,
	Jan, Sebastien

On Wed, 12 May 2010, Ha, Tristram wrote:

> I use a web browser to send patches through my company's e-mail system.  The message is composed by cut and paste, so it may not conform to Linux standard.
> 
> The latest nuttcp default size for UDP is 1500 bytes, rather than 8192 bytes.  In my case, the transmit performance improves from 10 Mbps to 11.  Have you tried TCP?

Just a nuttcp correction.  The default unicast UDP buflen in any
recent nuttcp is the largest power of 2 less than the MSS of the
control connection.  This means that the default UDP buflen for a
1500 byte MTU link is 1024, while for 9000 byte jumbo capable
networks it would be 8192.  This was done to avoid IP fragmentation
by default in most common scenarios (can be overridden by explicitly
setting the buflen with the "-l" nuttcp option).

						-Bill



> -----Original Message-----
> From: Arce, Abraham [mailto:x0066660@ti.com]
> Sent: Thu 5/6/2010 10:02 PM
> To: Ha, Tristram; Ben Dooks
> Cc: David Miller; netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Jan, Sebastien
> Subject: RE: [PATCH 2.6.34-rc6] net: Improve ks8851 snl transmit performance
>  
> Hi,
> 
> [snip]
> 
> > There is a driver option no_tx_opt so that the driver can revert to original
> > implementation.  This allows user to verify if the transmit performance
> > actually improves.
> 
> Should we limit patch description to 80 characters also?
> 
> > Signed-off-by: Tristram Ha <Tristram.Ha@micrel.com>
> > ---
> > This replaces the [patch 01/13] patch I submitted and was objected by David.
> > 
> > Other users with Micrel KSZ8851 SNL chip please verify the transmit
> > performance does improve or not.
> 
> Tested-by: Abraham Arce <x0066660@ti.com>
> 
> Executing some nuttcp scenarios:
> 
> - Without Patch -
> 
> # /testsuites/ethernet/bin/nuttcp -u -i -Ri50m <serverip>
>  1.2676 MB /   1.00 sec =   10.6330 Mbps     0 /  1298 ~drop/pkt  0.00 ~%loss
>  1.2705 MB /   1.00 sec =   10.6579 Mbps     0 /  1301 ~drop/pkt  0.00 ~%loss
>  1.2686 MB /   1.00 sec =   10.6414 Mbps     0 /  1299 ~drop/pkt  0.00 ~%loss
>  1.2695 MB /   1.00 sec =   10.6496 Mbps     0 /  1300 ~drop/pkt  0.00 ~%loss
>  1.2695 MB /   1.00 sec =   10.6496 Mbps     0 /  1300 ~drop/pkt  0.00 ~%loss
>  1.2686 MB /   1.00 sec =   10.6414 Mbps     0 /  1299 ~drop/pkt  0.00 ~%loss
>  1.2686 MB /   1.00 sec =   10.6414 Mbps     0 /  1299 ~drop/pkt  0.00 ~%loss
>  1.2646 MB /   1.00 sec =   10.6086 Mbps     0 /  1295 ~drop/pkt  0.00 ~%loss
>  1.2686 MB /   1.00 sec =   10.6412 Mbps     0 /  1299 ~drop/pkt  0.00 ~%loss
>  1.2695 MB /   1.00 sec =   10.6498 Mbps     0 /  1300 ~drop/pkt  0.00 ~%loss
> 
> 12.7314 MB /  10.02 sec =   10.6637 Mbps 4 %TX 0 %RX 0 / 13037 drop/pkt 0.00 %loss
> 
> - With Patch -
> 
> # /testsuites/ethernet/bin/nuttcp -u -i -Ri50m 10.87.231.229
>     1.2891 MB /   1.00 sec =   10.8133 Mbps     0 /  1320 ~drop/pkt  0.00 ~%loss
>     1.2900 MB /   1.00 sec =   10.8217 Mbps     0 /  1321 ~drop/pkt  0.00 ~%loss
>     1.2900 MB /   1.00 sec =   10.8217 Mbps     0 /  1321 ~drop/pkt  0.00 ~%loss
>     1.2910 MB /   1.00 sec =   10.8298 Mbps     0 /  1322 ~drop/pkt  0.00 ~%loss
>     1.2910 MB /   1.00 sec =   10.8299 Mbps     0 /  1322 ~drop/pkt  0.00 ~%loss
>     1.2900 MB /   1.00 sec =   10.8216 Mbps     0 /  1321 ~drop/pkt  0.00 ~%loss
>     1.2900 MB /   1.00 sec =   10.8216 Mbps     0 /  1321 ~drop/pkt  0.00 ~%loss
>     1.2891 MB /   1.00 sec =   10.8135 Mbps     0 /  1320 ~drop/pkt  0.00 ~%loss
>     1.2900 MB /   1.00 sec =   10.8216 Mbps     0 /  1321 ~drop/pkt  0.00 ~%loss
>     1.2910 MB /   1.00 sec =   10.8298 Mbps     0 /  1322 ~drop/pkt  0.00 ~%loss
> 
>    12.9492 MB /  10.02 sec =   10.8461 Mbps 4 %TX 0 %RX 0 / 13260 drop/pkt 0.00
> %loss
> 
> Also simulated heavy transmission consisting of 40 processes executed in parallel:
> 
>  - 20 ping instances using packet size of 32768
>  - 20 dd instances creating a 50MB file each under the nfs rootfs
> 
> If any specific test scenario/application is required please do let me know...
> 
> Best Regards
> Abraham

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 2.6.34-rc6] net: Improve ks8851 snl transmit performance
  2010-05-06 22:50 [PATCH 2.6.34-rc6] net: Improve ks8851 snl transmit performance Ha, Tristram
  2010-05-07  5:02 ` Arce, Abraham
@ 2010-05-16  7:26 ` David Miller
  2010-05-24 17:28   ` Ha, Tristram
  1 sibling, 1 reply; 8+ messages in thread
From: David Miller @ 2010-05-16  7:26 UTC (permalink / raw)
  To: Tristram.Ha; +Cc: ben, netdev, linux-kernel, x0066660, s-jan

From: "Ha, Tristram" <Tristram.Ha@Micrel.Com>
Date: Thu, 6 May 2010 15:50:27 -0700

> From: Tristram Ha <Tristram.Ha@micrel.com>
> 
> Under heavy transmission the driver will put 4 1514-byte packets in
> queue and stop the device transmit queue.  Only the last packet
> triggers the transmit done interrupt and wakes up the device
> transmit queue.  That means a bit of time is wasted when the CPU
> cannot send any more packet.
> 
> The new implementation triggers the transmit interrupt when the
> transmit buffer left is less than 3 packets.  The maximum transmit
> buffer size is 6144 bytes.  This allows the device transmit queue to
> be restarted sooner so that CPU can send more packets.
> 
> For TCP receiving it also has the benefit of not triggering any transmit interrupt at all.
> 
> There is a driver option no_tx_opt so that the driver can revert to
> original implementation.  This allows user to verify if the transmit
> performance actually improves.
> 
> Signed-off-by: Tristram Ha <Tristram.Ha@micrel.com>

First, if you want to post patches you have to format them properly as
ascii text with no longer than 80 column lines in your commit message.
I really don't want to hear about your email client being a reason
you can't do this properly :-)

Second, I don't think you can use the skb->ip_summed for this hacked
state tracking you are using.  The packet might be shared with other
entities, and therefore if you change the field it won't be correct
for them any more.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* RE: [PATCH 2.6.34-rc6] net: Improve ks8851 snl transmit performance
  2010-05-16  7:26 ` David Miller
@ 2010-05-24 17:28   ` Ha, Tristram
  2010-05-24 17:44     ` David Miller
  0 siblings, 1 reply; 8+ messages in thread
From: Ha, Tristram @ 2010-05-24 17:28 UTC (permalink / raw)
  To: David Miller; +Cc: ben, netdev, linux-kernel, x0066660, s-jan

David Miller wrote:
> From: "Ha, Tristram" <Tristram.Ha@Micrel.Com>
> Date: Thu, 6 May 2010 15:50:27 -0700
> 
>> From: Tristram Ha <Tristram.Ha@micrel.com>
>> 
>> Under heavy transmission the driver will put 4 1514-byte packets in
>> queue and stop the device transmit queue.  Only the last packet
>> triggers the transmit done interrupt and wakes up the device transmit
>> queue.  That means a bit of time is wasted when the CPU cannot send
>> any more packet.
>> 
>> The new implementation triggers the transmit interrupt when the
>> transmit buffer left is less than 3 packets.  The maximum transmit
>> buffer size is 6144 bytes.  This allows the device transmit queue to
>> be restarted sooner so that CPU can send more packets.
>> 
>> For TCP receiving it also has the benefit of not triggering any
transmit interrupt at all.
>> 
>> There is a driver option no_tx_opt so that the driver can revert to
>> original implementation.  This allows user to verify if the transmit
>> performance actually improves.
>> 
>> Signed-off-by: Tristram Ha <Tristram.Ha@micrel.com>
> 
> First, if you want to post patches you have to format them properly as
ascii text with no longer
> than 80 column lines in your commit message. 
> I really don't want to hear about your email client being a reason you
can't do this properly :-)
> 
> Second, I don't think you can use the skb->ip_summed for this hacked
state tracking you are
> using.  The packet might be shared with other entities, and therefore
if you change the field it
> won't be correct for them any more.  

Sorry about the patch description.  I must have forgotten the rules.

As the socket buffer is accepted by the lowest level network driver and
reaches the end of its life, I think using one of its variables
temporarily does not cause any harm.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 2.6.34-rc6] net: Improve ks8851 snl transmit performance
  2010-05-24 17:28   ` Ha, Tristram
@ 2010-05-24 17:44     ` David Miller
  0 siblings, 0 replies; 8+ messages in thread
From: David Miller @ 2010-05-24 17:44 UTC (permalink / raw)
  To: Tristram.Ha; +Cc: ben, netdev, linux-kernel, x0066660, s-jan

From: "Ha, Tristram" <Tristram.Ha@Micrel.Com>
Date: Mon, 24 May 2010 10:28:40 -0700

> As the socket buffer is accepted by the lowest level network driver and
> reaches the end of its life, I think using one of its variables
> temporarily does not cause any harm.

The packet can be referenced by packet sniffers and other entities in
the kernel.

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2010-05-24 17:44 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-05-06 22:50 [PATCH 2.6.34-rc6] net: Improve ks8851 snl transmit performance Ha, Tristram
2010-05-07  5:02 ` Arce, Abraham
2010-05-13  5:38   ` Ha, Tristram
2010-05-13 23:39     ` Arce, Abraham
2010-05-14 23:22     ` Bill Fink
2010-05-16  7:26 ` David Miller
2010-05-24 17:28   ` Ha, Tristram
2010-05-24 17:44     ` David Miller

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).