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

On Thu, 5 Jan 2017 20:17:56 -0700
Sean Bruno <sbruno_at_freebsd.org> 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.
> 
> A documentation and man page update will follow in the next few days
> explaining how to work with the changed driver.
> 
> sean
> 
> bcc net_at_ current_at_ re_at_
> 
> 
> 
On a Fujitsu Celsius M740, the "em0" device gets stuck on heavy I/O. I can
still trigger this behaviour on recent CURRENT (12.0-CURRENT #17 r312369: Wed
Jan 18 06:18:45 CET 2017 amd64) by rsync'ing a large poudriere ports
repository onto a remote NFSv4 fileserver. The freeze always occur on large
tarballs.

Again, here is the pciconf output of the device: 

em0_at_pci0:0:25:0:        class=0x020000 card=0x11ed1734 chip=0x153a8086
rev=0x05 hdr=0x00 vendor     = 'Intel Corporation'
    device     = 'Ethernet Connection I217-LM'
    class      = network
    subclass   = ethernet
    bar   [10] = type Memory, range 32, base 0xfb300000, size 131072, enabled
    bar   [14] = type Memory, range 32, base 0xfb339000, size 4096, enabled
    bar   [18] = type I/O Port, range 32, base 0xf020, size 32, enabled

On another box. equipted with a dual-port Intel i350 NIC, the igb0 and igb1 do
have negotiation problems with several types of switches (in my SoHo
environment, I use a Netgear GS110TP, at work there are several types of Cisco
Catalyst 3XXX types). The igbX very often fall back to 100MBit/s.

Since yesterday, the igbX on that specific i350 basesd NIC (we have plentz of
them and they show similar phenomena with FreeBSD), although the switch reports
an uplink with 1 GBit, FreeBSD CURRENT shows this weird crap message:

> igb0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
> 1500
> options=653dbb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,LRO,WOL_UCAST,WOL_MCAST,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6>
> ether xx:xx:xx:xx:xx:xx inet 192.168.0.111 netmask 0xffffff00 broadcast
> 192.168.0.255 nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
>        media: Ethernet autoselect (100baseTX <full-duplex>)
>        status: active

I haven't checked whether FreeBSD lies or the switch lies about the linkspeed,
but will do next time I have access to the box.


regards,
Oliver