RFC: ethctl

[Adrian Chadd]

On 19 January 2017 at 19:58, Kevin Bowling <kevin.bowling at kev009.com> 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

Hi,

ethtool isn't exactly complicated. It's just vaguely standardized.

When I was hoping (hah!) to do it, partly for wifi but partly for
ethernet, my goals were:

* generic interface for counter statistics, versus sysctl;
* "default" mib space for known counter statistics, versus the small
set we have now and then the very large vendor space that ethtool
(linux) and sysctl (freebsd) exposes;
* generic interface for configuring things like RSS mapping, L2/L3
rules for a NIC based on the NIC capability and what queue(s) they map
to, versus vendor tools;
* vendor specific extensions, which hopefully (!) are implemented as
generic-ish plugins where required, or just strings that can be passed
through to the driver and registered via a command hook;
* and importantly - some kind of optional debug control, because every
driver does something different for debugging / tracing, and boy it'd
be nice if it all was like wifi (wlandebug -i <interface>
+/-(feature))

A lot of what's in linux ethtool is in freebsd's ifconfig, albeit not
in a reusable/runtime-extensible fashion. It'd be nice to include say,
many more vendor counters in a somewhat generic fashion, versus how we
currently do things.

I think it'd be a good starting point to have an ethtool control iflib
drivers, so any driver using iflib can benefit from what's
implemented.

2c,

-adrian