HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

[Harry Schmalzbauer]

 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