Date: Tue, 20 Dec 2011 18:52:38 -0700 From: Clint <clint@servedomains.com> To: <freebsd-net@freebsd.org> Subject: Re: igb performance/load udp issue Message-ID: <5b246a7cf0bceedf39ff5718336b0753@servedomains.com> In-Reply-To: <20111220224814.GA7715@michelle.cdnetworks.com> References: <2f23773b5165887ac51d19a612bf4c93@servedomains.com> <20111220224814.GA7715@michelle.cdnetworks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 20 Dec 2011 14:48:14 -0800, YongHyeon PYUN wrote: > I also see similar excessive system load with em(4) on latest HEAD. > Self-clocking protocols like TCP does not seem to suffer from the > issue but UDP clearly shows the issue. A single bulk UDP transmit > test session completely halts the box while the test is in > progress. I have a patch that addresses it but it needs more clean > ups and Jack's review. I'm not sure whether the patch could be > accepted since it completely removes taskqueue based approach in > TX/RX path. > Also note, multi-queue option of igb(4) can re-order UDP packets in > TX path such that it can result in poor NFS over UDP performance. > It seems TCP is more resilient on packet reodering though. > > Because igb(4) shares implementation idea with em(4), it's possible > igb(4) also have the similar issue. I have to find some spare time > to try this with igb(4) but I'm somewhat overloaded to address poor > em(4) performance on 82574 with MSI-X. > I decided to try the updated igb driver, v2.2.5, in FreeBSD 9.0RC3. I can no longer duplicate the excessive load issue as it now performs so poorly that I can't even stream a 38Mbit/s file via either NFS/UDP or Samba/TCP, so things went from bad to worse. I'm guessing it has something to do with flow control as that's appears to be different with this driver, back to v2.2.3 for now. Thanks, Clint
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5b246a7cf0bceedf39ff5718336b0753>