Date: Mon, 3 Aug 2009 12:26:55 +0200 From: Invernizzi Fabrizio <fabrizio.invernizzi@telecomitalia.it> To: Stefan Lambrev <stefan.lambrev@moneybookers.com> Cc: "freebsd-performance@freebsd.org" <freebsd-performance@freebsd.org> Subject: RE: Test on 10GBE Intel based network card Message-ID: <36A93B31228D3B49B691AD31652BCAE9A4560DF96A@GRFMBX702BA020.griffon.local> In-Reply-To: <18AAC16B-3CC0-4C70-A009-00A325AB5932@moneybookers.com> References: <36A93B31228D3B49B691AD31652BCAE9A4560DF911@GRFMBX702BA020.griffon.local> <0E567C7E-4EAA-4B89-9A8D-FD0450D32ED7@moneybookers.com> <36A93B31228D3B49B691AD31652BCAE9A4560DF947@GRFMBX702BA020.griffon.local> <18AAC16B-3CC0-4C70-A009-00A325AB5932@moneybookers.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > If you are meaning in term of Packet per second, you are right. > > These are the packet per second measured during tests: > > > > 64 byte: 610119 Pps > > 512 byte: 516917 Pps > > 1492 byte: 464962 Pps > > > > > >> Am I correct that the maximum you can reach is around 639,000 packets > >> per second? > > > > Yes, as you can see the maximum is 610119 Pps. > > Where does this limit come from? > > I duno - the tests I did before were with SYN packets (random source) > which was my worst scenario, > and the server CPU were busy generating MD5 check sums for > "syncache" (around 35% of the time). > > If I have to compare my results with your, you beat me with factor > 2.5, may be because you use ICMP for the test > and your processor is better then my test stations :) > Also my experience is only with gigabit cards (em driver) and FreeBSD > 7.something_before_1 where the em thread was eating 100% cpu. > If you are lucky LOCK_PROFILING(9) will help you to see where the CPUs > spend their time, if not you will see kernel panic :) I will check, thanks for the hint. > Once problematic locks identified they can be reworked, but I think > the first part is already done > and work on the second already started. > > In my experience increasing hw.em.rxd and hw.em.txd yelled better > results, but I think ixgb already comes tuned by default > as it still doesn't have to support such a large number of different > cards. I did some tuning in the code of the driver e recompiled the kernel in orde= r to reduce context switching (interrupt mitigation) since the driver does = not support POLLING. > Also at the time of my tests there were not support for multi queues > in the OS even if they were supported by the HW, which is changed in > 7.2 (?) It looks like multi queue is working since I can see the load distributed o= ver the 4 cores. Fabrizio Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?36A93B31228D3B49B691AD31652BCAE9A4560DF96A>