Date: Fri, 20 Jan 2017 11:42:04 -0500 From: Andrew Gallatin <gallatin@netflix.com> To: Kevin Bowling <kevin.bowling@kev009.com>, freebsd-net@freebsd.org Cc: Scott Long <scottl@netflix.com>, Navdeep Parhar <navdeep@chelsio.com>, Oded Shanoon <odeds@mellanox.com>, hps@freebsd.org, Matthew Macy <mmacy@nextbsd.org>, jeb.j.cramer@intel.com, eric.joyner@intel.com, arybchik@freebsd.org, shurd@freebsd.org, Sean Bruno <sbruno@freebsd.org>, George Neville-Neil <gnn@freebsd.org> Subject: Re: RFC: ethctl Message-ID: <c21ec3d9-a539-6c7d-4bd3-6413e7149b2b@netflix.com> In-Reply-To: <CAK7dMtCSRu6L67A46FU0eYqJ9=zGdyJPvBXLkL7gKbh=SbZ6cQ@mail.gmail.com> References: <CAK7dMtCSRu6L67A46FU0eYqJ9=zGdyJPvBXLkL7gKbh=SbZ6cQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 01/19/2017 22:58, Kevin Bowling wrote: > Greetings, > > I'm casting a wide net in cc, try to keep the noise minimal but we need > some input from a variety of HW vendors. > > I have heard from several vendors the need for a NIC configuration tool. > Chelsio ships a cxgb/cxgbetool in FreeBSD as one example. There is > precedence for some nod toward a basic unified tool in Linux ethtool. > > From your perspective, > 1) What are the common requirements? > 2) What are specialized requirements? For instance as a full TCP offload > card Chelsio needs things others wont > 3) What should it _not_ do? Several of you have experience doing > Ethernet driver dev on many platforms so we should attempt to avoid > repeating past design mistakes. > > I expect we can achieve some level of inversion so the device specific > code can live close to the driver and plug into the ethctl framework. > It should be general enough to add completely new top level commands, so > vendors can implement HW specific features. On the other hand, we > should attempt to hook into common core for features every NIC provides, > with a focus on iflib. > > I will fund Matt Macy to do the overall design and implementation. > > Regards, > Kevin Bowling, on behalf of Limelight Networks for this effort In a previous job, I was the author of a few Linux drivers (as well as FreeBSD, Solaris, OSX, ESX, etc) for Myricom NICs. IMHO, the "good" thing about ethtool was the standardized kernel API to do things like change tx/rx ring size, and enable/disable offloads. That was much nicer than having to parse ioctls and/or have custom sysctls. I think Gleb had started on this in his ifnet branch, and centralizing such features in iflib is a good carrot to encourage new drivers to use iflib. However, as a user/admin, I believed that a lot of the stuff that was in Linux's ethtool should really have been in ifconfig, and it was always a bit hard to remember which tool did which thing. I think I was spoiled by the rich configuration syntax available on FreeBSD's ifconfig. Eg, this seems more natural: ifconfig mxge0 -tso than this ethtool -K eth2 tso off Eg, I don't see why we need another tool for some of this missing "ethtool" functionality; it seems like most of it would naturally fit into ifconfig. As to other features, like writing firmware images and/or reading dumping eeprom -- these were never a natural fit for us. We already had our own tools that did just what we needed and worked across *all* OSes (even Windows!). I remember trying to figure out the ethtool way, but there was no substantial customer demand for using ethtool for this that I was aware of, and the time needed to adapt our firmware image, etc, to the ethtool format was just not possible to justify. So I think asking vendors to support a FreeBSD ethtool-ish interface for this is asking a lot. Drew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c21ec3d9-a539-6c7d-4bd3-6413e7149b2b>