From owner-freebsd-net@freebsd.org Tue Jan 10 10:28:38 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AE7EACA95E7 for ; Tue, 10 Jan 2017 10:28:38 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 43F0C1C47; Tue, 10 Jan 2017 10:28:38 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id v0AASYve062105; Tue, 10 Jan 2017 11:28:34 +0100 (CET) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 88DD843; Tue, 10 Jan 2017 11:28:34 +0100 (CET) Message-ID: <5874B751.4000808@omnilan.de> Date: Tue, 10 Jan 2017 11:28:33 +0100 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Sean Bruno CC: freebsd-net@freebsd.org Subject: Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending References: <092ad9f7-b04c-292f-c626-6ce1956580a8@freebsd.org> In-Reply-To: <092ad9f7-b04c-292f-c626-6ce1956580a8@freebsd.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Tue, 10 Jan 2017 11:28:34 +0100 (CET) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 10:28:38 -0000 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