Date: Tue, 10 Jan 2017 11:28:33 +0100 From: Harry Schmalzbauer <freebsd@omnilan.de> To: Sean Bruno <sbruno@freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending Message-ID: <5874B751.4000808@omnilan.de> In-Reply-To: <092ad9f7-b04c-292f-c626-6ce1956580a8@freebsd.org> References: <d6627189-c9ce-fc91-d71a-111e127b0b64@freebsd.org> <092ad9f7-b04c-292f-c626-6ce1956580a8@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Bezüglich Sean Bruno's Nachricht vom 10.01.2017 04:32 (localtime): > tl;dir --> you get to keep your igbX devices(thanks jhb), no POLA > violations this week. > > I've updated sys/dev/e1000 at svn R311849 to match Matt Macy's work on > IFLIB in the kernel. > > At this point, the driver deviates from Intel's code dramatically and > you now get to yell directly into the freebsd-net@ megaphone for things > that I may have broken. > > man page updates are coming up next. Please let us know if this > revision has made things better, worse or none-of-the above on whatever > Intel Gigabit NIC you happen to have lying around. > > sean > > On 01/05/17 20:18, Sean Bruno wrote: >> tl;dr --> igbX devices will become emX devices >> >> We're about to commit an update to sys/dev/e1000 that will implement and >> activate IFLIB for em(4), lem(4) & igb(4) and would appreciate all folks >> who can test and poke at the drivers to do so this week. This will have >> some really great changes for performance and standardization that have >> been bouncing around inside of various FreeBSD shops that have been >> collaborating with Matt Macy over the last year. >> >> This will implement multiple queues for certain em(4) devices that are >> capable of such things and add some new sysctl's for you to poke at in >> your monitoring tools. >> >> Due to limitations of device registration, igbX devices will become emX >> devices. So, you'll need to make a minor update to your rc.conf and >> scripts that manipulate the network devices. >> >> UPDATING will be bumped to reflect these changes. >> >> MFC to stable/11 will have a legacy implementation that doesn't use >> IFLIB for compatibility reasons. Thank you very much for your work! I'm unsure if I got it right: stabe/11 won't benefit from IFLIB (not that I know waht IFLIB is all about, yet), but driver changes will be merged? I'm already using MULTIQUEUE support for em(4) (Hartwell, 82547) since 10.2-stable without problems on high saturated single links and noticable better performance. Currently I could test a pre-productive igb(4)/Kawela (82576) machine utilizing LACP+VLANs to chekck for regression (improvement regarding »igb stopped distributiong, possible flapping?«), but it's stable/11. Simply merging r311849 doesn't work, most likely due to the IFLIB compatibility reasons you mentioned. Have you already prepared a MFC verison? What should igb(4) users expect after MFC? (Christmas is over and I didn't get SR-IOV for igb(4)/82576, so this its still on my wish list ;-)) Thnaks, -harry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5874B751.4000808>