RFC: ethctl

[Luigi Rizzo]

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 at 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 at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"



-- 
-----------------------------------------+-------------------------------
 Prof. Luigi RIZZO, rizzo at 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)
-----------------------------------------+-------------------------------