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

[Jakub Kicinski <kubakici@wp.pl>]

On Tue, 12 Dec 2017 07:32:44 -0800, Roopa Prabhu wrote:
> Thanks for working on this!. Agree with most comments already
> discussed on this thread.
> I would prefer if we fold ethtool netlink into devlink since there is
> already an overlap.
> many reasons:
> - have just one driver api for device global and per port config
> (devlink already provides that)
> - some of the devlink commands like port split/unsplit can already be
> applied per netdev (and since you bring up network interface managers,
> we are looking at getting these in network managers for switch ports)
> - if we keep them separate, we will soon see that drivers will need
> handlers for both devlink and ethtool
> - and the overlap is going to be confusing for both drivers and user-space

+1

FWIW my gut feeling is that extending devlink-port makes more sense
than creating another command.  Although things like RSS tables don't
feel very natural in port context.

The other issue that springs to mind is that ethtool ops take RTNL lock
today, and devlink doesn't.  It would be cool if we could make ethtool
not require RTNL lock (and drivers didn't have to drop locks half way
through the .flash_device callback, sigh...) but OTOH that would make
the driver conversion more brittle and potentially block the much
needed netlink conversion...

That's my $0.02 ;)