Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 18 Jan 2017 07:41:13 -0700
From:      Sean Bruno <sbruno@freebsd.org>
To:        "O. Hartmann" <o.hartmann@walstatt.org>
Cc:        freebsd-current <freebsd-current@freebsd.org>
Subject:   Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending
Message-ID:  <eba93bf8-2acf-d7bc-0192-10e75b7b993b@freebsd.org>
In-Reply-To: <20170118083400.11156f23@freyja.zeit4.iv.bundesimmobilien.de>
References:  <30f21c75-d3a2-edcd-1999-d5ed9f970c06@freebsd.org> <20170118083400.11156f23@freyja.zeit4.iv.bundesimmobilien.de>

next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--1NTqIJHqFeBDVEo51lHtKcvoMRmJL06S9
Content-Type: multipart/mixed; boundary="F4sxK3bvbcGWNS1p2TPNFum1iMO4dAPOL";
 protected-headers="v1"
From: Sean Bruno <sbruno@freebsd.org>
To: "O. Hartmann" <o.hartmann@walstatt.org>
Cc: freebsd-current <freebsd-current@freebsd.org>
Message-ID: <eba93bf8-2acf-d7bc-0192-10e75b7b993b@freebsd.org>
Subject: Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb
 pending
References: <30f21c75-d3a2-edcd-1999-d5ed9f970c06@freebsd.org>
 <20170118083400.11156f23@freyja.zeit4.iv.bundesimmobilien.de>
In-Reply-To: <20170118083400.11156f23@freyja.zeit4.iv.bundesimmobilien.de>

--F4sxK3bvbcGWNS1p2TPNFum1iMO4dAPOL
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable



On 01/18/17 00:34, O. Hartmann wrote:
> On Thu, 5 Jan 2017 20:17:56 -0700
> Sean Bruno <sbruno@freebsd.org> wrote:
>=20
>> tl;dr --> igbX devices will become emX devices
>>
>> We're about to commit an update to sys/dev/e1000 that will implement a=
nd
>> activate IFLIB for em(4), lem(4) & igb(4) and would appreciate all fol=
ks
>> who can test and poke at the drivers to do so this week.  This will ha=
ve
>> some really great changes for performance and standardization that hav=
e
>> 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 em=
X
>> 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 r31236=
9: 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 l=
arge
> tarballs.
>=20
> Again, here is the pciconf output of the device:=20
>=20
> em0@pci0:0:25:0:        class=3D0x020000 card=3D0x11ed1734 chip=3D0x153=
a8086
> rev=3D0x05 hdr=3D0x00 vendor     =3D 'Intel Corporation'
>     device     =3D 'Ethernet Connection I217-LM'
>     class      =3D network
>     subclass   =3D ethernet
>     bar   [10] =3D type Memory, range 32, base 0xfb300000, size 131072,=
 enabled
>     bar   [14] =3D type Memory, range 32, base 0xfb339000, size 4096, e=
nabled
>     bar   [18] =3D type I/O Port, range 32, base 0xf020, size 32, enabl=
ed
>=20
> 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 o=
f Cisco
> Catalyst 3XXX types). The igbX very often fall back to 100MBit/s.
>=20
> Since yesterday, the igbX on that specific i350 basesd NIC (we have ple=
ntz 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:
>=20
>> igb0: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mt=
u
>> 1500
>> options=3D653dbb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_=
HWCSUM,TSO4,LRO,WOL_UCAST,WOL_MCAST,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,RX=
CSUM_IPV6,TXCSUM_IPV6>
>> ether xx:xx:xx:xx:xx:xx inet 192.168.0.111 netmask 0xffffff00 broadcas=
t
>> 192.168.0.255 nd6 options=3D29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
>>        media: Ethernet autoselect (100baseTX <full-duplex>)
>>        status: active
>=20
> I haven't checked whether FreeBSD lies or the switch lies about the lin=
kspeed,
> but will do next time I have access to the box.
>=20
>=20
> regards,
> Oliver
>=20


Ugh.  Ok.  Investigating the link issue, that's gross.

sean


--F4sxK3bvbcGWNS1p2TPNFum1iMO4dAPOL--

--1NTqIJHqFeBDVEo51lHtKcvoMRmJL06S9
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQGTBAEBCgB9FiEEuq1GMucSHejSCZfdEgHvyh5yfmQFAlh/fopfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEJB
QUQ0NjMyRTcxMjFERThEMjA5OTdERDEyMDFFRkNBMUU3MjdFNjQACgkQEgHvyh5y
fmRNAAf9HJblQVCCzv1bYWGNIkO2XUfkDfGEgiGt51o4YAVEAqYqXiRt+IK2wzMZ
JaoITeAv3j6TOGdFUJClJTVDOkGGfGsK3/AVdGECws/LDPsEoQ7jZcIR0n1FErVe
3uF/p3epXmWN1b3AwCS3l+ZwuLtTUiB8ZLzVfVqXljXU0CBirn7c4RXUvflk+jgf
0p0+CnwrqQsqkNXAJYT4oAZnKtZlq88WgyDJcrHA/ChQCxTrinidI43MfwW0Cm67
bQc/+pmd0DOFKlE78I4JQ9GnTxj74huMKdNo5lu/o+K7kXQ9l2q5FyYmgEd+jxhw
BIZda5UFWW1x6hZnSvWtRAWJfqPjlw==
=rBvL
-----END PGP SIGNATURE-----

--1NTqIJHqFeBDVEo51lHtKcvoMRmJL06S9--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?eba93bf8-2acf-d7bc-0192-10e75b7b993b>