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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 12 Dec 2017 15:47:41 -0800
From:   Jakub Kicinski <kubakici@...pl>
To:     Roopa Prabhu <roopa@...ulusnetworks.com>
Cc:     Michal Kubecek <mkubecek@...e.cz>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, Jiri Pirko <jiri@...nulli.us>,
        David Miller <davem@...emloft.net>
Subject: Re: [RFC PATCH 0/9] ethtool netlink interface (WiP)

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 ;)