Johan, Thanks for the report. We test with small packets all the time but I'm not sure what you mean by "overload" tests. What is the point of the test? To see how many packets the HW/driver/system will drop? What are you expecting to see? In the data you state below why is the packet size changing? You generate 64byte packets but the 22k...@210bytes looks to be at 210 byte packets. What would be changing the packet size? Also, does another test like netperf or iperf show different results?
Some other questions, what version of SLES10 are you using? Does the same thing happen on a recent upstream kernel? Has there been a version of the driver that did what you want it to? If you go to our Sourceforge site (http://e1000.sf.net) and look at the release notes for the different driver versions posted there, you'll be able to see what changed in each version. Cheers, John ----------------------------------------------------------- "...that your people will judge you on what you can build, not what you destroy.", B. Obama, 2009 >-----Original Message----- >From: Johan Kuijpers [mailto:[email protected]] >Sent: Wednesday, August 19, 2009 12:16 AM >To: [email protected] >Subject: [E1000-devel] Igb driver overload tests > >Good Morning, > >We are using the igb 1.2.45 as part of a SUSE 10 distribution on a quad >core main board and made the following observation during >overload tests >with traffic consisting of small packets (64 bytes). > >After overloading the board by generating traffic of 550 k...@64byte it >seems that the ethernet traffic is limited to relatively low throughput >(22 k...@210byte) and is unable to recover from the overload situation. >Previous tests with arp flooding showed similar results. > >Question 1: Has anyone observed similar behaviour or performed overload >tests with small packet sizes earlier. >Question 2: Where can I find a list of changes/improvements made to the >igb driver between 1.2.45 and 1.3.28.4. I couldn't find this >info in the >release notes and diffs of igb_main.c are a bit tricky to >judge in which >area improvements have been made. > >Any input is much appreciated, > >Johan Kuijpers > > ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ E1000-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/e1000-devel
