Mugunthan V N, Thank you SO much for your repsonse. That did help enormously. # ./iperf-arm -i 1 -t 3000 -c 10.22.255.5 ------------------------------------------------------------ Client connecting to 10.22.255.5, TCP port 5001 TCP window size: 19.6 KByte (default) ------------------------------------------------------------ [ 3] local 10.22.0.17 port 40201 connected with 10.22.255.5 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0- 1.0 sec 8.88 MBytes 74.4 Mbits/sec [ 3] 1.0- 2.0 sec 10.7 MBytes 90.0 Mbits/sec [ 3] 2.0- 3.0 sec 8.24 MBytes 69.1 Mbits/sec [ 3] 3.0- 4.0 sec 8.54 MBytes 71.6 Mbits/sec [ 3] 4.0- 5.0 sec 7.23 MBytes 60.6 Mbits/sec [ 3] 5.0- 6.0 sec 11.2 MBytes 93.6 Mbits/sec [ 3] 6.0- 7.0 sec 10.6 MBytes 89.2 Mbits/sec [ 3] 7.0- 8.0 sec 10.1 MBytes 84.9 Mbits/sec [ 3] 8.0- 9.0 sec 7.76 MBytes 65.1 Mbits/sec [ 3] 9.0-10.0 sec 4.66 MBytes 39.1 Mbits/sec [ 3] 10.0-11.0 sec 6.79 MBytes 57.0 Mbits/sec [ 3] 11.0-12.0 sec 7.30 MBytes 61.3 Mbits/sec [ 3] 12.0-13.0 sec 7.01 MBytes 58.8 Mbits/sec We're still not at 100%, but the exhorbitant timeouts are gone, and we're back to bandwidth we can live with for the time being. Thanks! The oddity is the patch you shared is one that I actually suggested to myself in my code comments from nearly a year ago. I guess I needed someone to remind me of my own notes! :-P See the comment in that line from http://article.gmane.org/gmane.linux.ports.arm.omap/79787 ??? Since that fix appears to help, please review the other contents of that draft patch I posted back then. Perhaps there are a few other good things that can be applied from there to the driver today? The biggest change I proposed was removing the redundant emac_rx_alloc() function and replacing it with the standard netdev_alloc_skb_ip_align() instead. I also took a look at improving the detection and handling of some potential errors. To be honest, I never saw any of my dev_err() calls hit, but that's not to say that they could never do so. Thanks again! ----- Original Message ----- From: Mugunthan V N <mugunthanvnm@xxxxxx> To: CF Adad <cfadad@xxxxxxxxxxxxxx> Cc: "linux-omap@xxxxxxxxxxxxxxx" <linux-omap@xxxxxxxxxxxxxxx>; "davem@xxxxxxxxxxxxx" <davem@xxxxxxxxxxxxx> Sent: Thursday, April 4, 2013 4:32 AM Subject: Re: AM3517 DaVinci EMAC Ethernet performance issues On 4/4/2013 7:50 AM, CF Adad wrote: > We've done network captures on our link, and the problem is very strange. The iperf client transmits data quickly and steadily for a while, but then all the sudden just stops. In the captures you can see an ACK come back from the server for the frame that was just sent, but then instead of immediately sending the next one it just sits there for sometimes several seconds. Then, it suddenly picks back up and starts running again. It's as though it just paused due to lack of data. The same kind of issue was observed in different SoC with Davinci EMAC and resolved by the patch below. Can you make sure the patch is applied in your kernel and take the performance again. https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=7e51cde276ca820d526c6c21cf8147df595a36bf Regards Mugunthan V N -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
