From owner-freebsd-current@freebsd.org Fri Jan 6 19:35:30 2017 Return-Path: Delivered-To: freebsd-current@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 A58BCCA242F for ; Fri, 6 Jan 2017 19:35:30 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 85A331C10; Fri, 6 Jan 2017 19:35:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id D669810B55F; Fri, 6 Jan 2017 14:35:22 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending Date: Fri, 06 Jan 2017 11:11:39 -0800 Message-ID: <12298639.7MUNlBUVpl@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.0-STABLE; KDE/4.14.10; amd64; ; ) In-Reply-To: <30f21c75-d3a2-edcd-1999-d5ed9f970c06@freebsd.org> References: <30f21c75-d3a2-edcd-1999-d5ed9f970c06@freebsd.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Fri, 06 Jan 2017 14:35:22 -0500 (EST) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 19:35:30 -0000 On Thursday, January 05, 2017 08:17:56 PM 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. > > A documentation and man page update will follow in the next few days > explaining how to work with the changed driver. This is a very invasive change, and seems unnecessary. The only thing you can't share between two drivers with different names is the probe routine (which you would want to be different since they would cover different PCI ID lists). That is, you only need: static int igb_probe(device_t dev) { /* check igb PCI ID list */ } static int em_probe(device_t dev) { /* check em PCI ID list */ } static int foo_attach(device_t dev) { ... } static int foo_detach(device_t dev) { ... } static device_method_t igb_methods[] = { DEVMETHOD(device_probe, igb_probe), DEVMETHOD(device_attach, foo_attach), /* Other methods all use foo_* */ }; static device_method_t em_methods[] = { DEVMETHOD(device_probe, em_probe), DEVMETHOD(device_attach, foo_attach), /* Other methods all use foo_* */ }; static driver_t igb_driver = { "igb", igb_methods, sizeof(struct foo_softc) }; static driver_t em_driver = { "em", em_methods, sizeof(struct foo_softc) }; DRIVER_MODULE(igb, pci, igb_driver, ...); DRIVER_MODULE(em, pci, em_driver, ...); This isn't a huge amount of code to carry around, and seems a very small price to pay compared to the cost of breaking existing machines (and existing documentation, so now things have to document <= 11 and >= 12 differently, etc.). (FWIW, this approach is what cxgbe uses to have the same driver code manage cxgbe/cxl/cc.) -- John Baldwin