We have not seen any OS kernel/driver/HW combination which does recover from overload. We generate raw IP packets with an agilent N2X feeding the board on the front port and terminating again with N2X on the backport (both igb's!) with either TCP or ARP as protocol identifier. We generate 32-42 streams ie ip src/dest combinations at the same time. We also observe that at very high packet rates after 30 seconds: throughput collapses if using short packets. It seems that packet discarding under load isn't 100% bullet-proof. Maybe page allocation problems is damaging the housekeeping in the driver.
Cheers John -----Original Message----- From: Ronciak, John [mailto:[email protected]] Sent: donderdag 20 augustus 2009 17:46 To: Johan Kuijpers; [email protected] Subject: RE: Igb driver overload tests Thanks for the information Johan. As for my other questions, what driver and OS on this HW does work? Have you ever seen this work on this exact HW setup? Another question is does this test use only ICMP packets for the flooding or are you using UDP or even TCP? Are connections established with the system or does your traffic generator just blast unicast packets at the end system? 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 11:58 PM >To: Ronciak, John; [email protected] >Subject: RE: Igb driver overload tests > >Thanks for your reply John. > >The overload tests we're performing are part of a suite of test cases >where robustness against IP flooding in general is verified. > >What we hope to see: A board handling IP traffic must be able to >survive peak stress tests during which obviously packets will be >dropped which is ok. But after the peak we generate again traffic with >more 'modest' >packet length distributions. We observe - also with 1.3.28.4 tested >yesterday - that the system is somehow throttled and not able to >provide higher throughputs after the peak load test which we *must* >resolve. We haven't used netperf but an agilent load tool instead. > >We are using kernel 2.6.27.23-5 64 bit linux. > >Cheers John. > >-----Original Message----- >From: Ronciak, John [mailto:[email protected]] >Sent: woensdag 19 augustus 2009 18:07 >To: Johan Kuijpers; [email protected] >Subject: RE: Igb driver overload tests > >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
