HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending
O. Hartmann
o.hartmann at walstatt.org
Wed Jan 18 07:34:13 UTC 2017
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@ current@ re@
>
>
>
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
More information about the freebsd-current
mailing list