Re: [RFC PATCH 0/9] ethtool netlink interface (WiP)

Mon, Dec 11, 2017 at 02:53:11PM CET, mkubecek@suse.cz wrote:

This is still work in progress and only a very small part of the ioctl
interface is reimplemented but I would like to get some comments before
the patchset becomes too big and changing things becomes too tedious.

The interface used for communication between ethtool and kernel is based on
ioctl() and suffers from many problems. The most pressing seems the be the
lack of extensibility. While some of the newer commands use structures
designed to allow future extensions (e.g. GFEATURES or TEST), most either
allow no extension at all (GPAUSEPARAM, GCOALESCE) or only limited set of
reserved fields (GDRVINFO, GEEE). Even most of those which support future
extensions limit the data types that can be used.

This series aims to provide an alternative interface based on netlink which
is what other network configuration utilities use. In particular, it uses
generic netlink (family "ethtool"). The goal is to provide an interface
which would be extensible, flexible and practical both for ethtool and for
other network configuration tools (e.g. wicked or systemd-networkd).

The interface is documented in Documentation/networking/ethtool-netlink.txt

I'll post RFC patch series for ethtool in a few days, it still needs some
more polishing.

First of all, thank you Michale for taking a stab at this!

I think that it does not make sense to convert ethtool->netlink_ethtool
1:1 feature wise. Now we have devlink, ritch switch representation
model, tc offload and many others. Lot of things that are in
ethtool, should be done in devlink. Also, there are couple of things
that should just die - nice example is ethtool --config-ntuple - we
should use tc for that.

So I believe that it would be better to introduce new iterface called
differently, to avoid confusion, like "ethlink" and start to migrate
things there, without existing baggage. In kernel the existing ethtool
would just call compat layer inside ethlink code. Similarly with devlink.
ethtool api would freeze. Similar scenario to rtnetlink and legacy ioctl.

Also, this new netlink iface should have userspace notification
support from day 1.