Date: Fri, 20 Jan 2017 09:56:29 -0800 From: Luigi Rizzo <rizzo@iet.unipi.it> To: Andrew Gallatin <gallatin@netflix.com> Cc: Kevin Bowling <kevin.bowling@kev009.com>, "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, Scott Long <scottl@netflix.com>, "Joyner, Eric" <eric.joyner@intel.com>, Oded Shanoon <odeds@mellanox.com>, Matthew Macy <mmacy@nextbsd.org>, hps@freebsd.org, "Cramer, Jeb J" <jeb.j.cramer@intel.com>, George Neville-Neil <gnn@freebsd.org>, arybchik@freebsd.org, shurd@freebsd.org, Navdeep Parhar <navdeep@chelsio.com> Subject: Re: RFC: ethctl Message-ID: <CA%2BhQ2%2BhyDSuGTNDsmayZiA1esRksESDoWz9nP30PA9Vdeg9a%2Bg@mail.gmail.com> In-Reply-To: <c21ec3d9-a539-6c7d-4bd3-6413e7149b2b@netflix.com> References: <CAK7dMtCSRu6L67A46FU0eYqJ9=zGdyJPvBXLkL7gKbh=SbZ6cQ@mail.gmail.com> <c21ec3d9-a539-6c7d-4bd3-6413e7149b2b@netflix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
To summarize Drew's comments, which I mostly agree with, and suggest
a possible strategy for deployment:
- Irrespective of the user-facing command (ifconfig vs ethtool),
a common kernel API for the most common features is very desirable.
- There are very good reasons to take inspiration from
include/linux/ethtool.h to decide on this set of features:
1. it is a valid starting point and as good as any other one;
2. ethtool functions are all optional so deciding what to put in
is not a hard decision
3. may possibly ease porting drivers across platforms
- I think the user interface bikeshed is not solvable other than eventually
implementing both "ifconfig" and "ethtool" style user commands.
This does not seem a major problem, because our ifconfig already implements
some of the ethtool's commands, and to tell the truth, as much as I am (was)
used to ifconfig, it is such a kitchen sink that it is sometimes
hard to figure out
how to use it (documentation and feature mismatch, ambiguity in the
syntax etc.)
- for some of the high level features (e.g. flashing a device) that may be more
complicated than calling an ioctl(), we could implement a fallback mechanism
where, say, the ioctl returns a special message that drives the
user-facing app to
call an external helper program (configured through /etc/rc.d/ or
whatever other
mechanism)
cheers
luigi
On Fri, Jan 20, 2017 at 8:42 AM, Andrew Gallatin via freebsd-net
<freebsd-net@freebsd.org> wrote:
> 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
>
> _______________________________________________
> freebsd-net@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
--
-----------------------------------------+-------------------------------
Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione
http://www.iet.unipi.it/~luigi/ . Universita` di Pisa
TEL +39-050-2217533 . via Diotisalvi 2
Mobile +39-338-6809875 . 56122 PISA (Italy)
-----------------------------------------+-------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2BhQ2%2BhyDSuGTNDsmayZiA1esRksESDoWz9nP30PA9Vdeg9a%2Bg>