netdev - Re: [RFC net-next 1/2] net: ethtool: add ethtool ability to set/get fresh device features

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]

Message-ID: <20220315195606.ggc3eea6itdiu6y7@lion.mk-sys.cz>
Date:   Tue, 15 Mar 2022 20:56:06 +0100
From:   Michal Kubecek <mkubecek@...e.cz>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Jie Wang <wangjie125@...wei.com>, davem@...emloft.net,
        netdev@...r.kernel.org, huangguangbin2@...wei.com,
        lipeng321@...wei.com, shenjian15@...wei.com, moyufeng@...wei.com,
        linyunsheng@...wei.com, tanhuazhong@...wei.com,
        salil.mehta@...wei.com, chenhao288@...ilicon.com
Subject: Re: [RFC net-next 1/2] net: ethtool: add ethtool ability to set/get
 fresh device features

On Tue, Mar 15, 2022 at 12:15:29PM -0700, Jakub Kicinski wrote:
> On Tue, 15 Mar 2022 11:21:07 +0800 Jie Wang wrote:
> > As tx push is a standard feature for NICs, but netdev_feature which is
> > controlled by ethtool -K has reached the maximum specification.
> > 
> > so this patch adds a pair of new ethtool messages：'ETHTOOL_GDEVFEAT' and
> > 'ETHTOOL_SDEVFEAT' to be used to set/get features contained entirely to
> > drivers. The message processing functions and function hooks in struct
> > ethtool_ops are also added.
> > 
> > set-devfeatures/show-devfeatures option(s) are designed to provide set
> > and get function.
> > set cmd:
> > root@wj: ethtool --set-devfeatures eth4 tx-push [on | off]
> > get cmd:
> > root@wj: ethtool --show-devfeatures eth4
> 
> I'd be curious to hear more opinions on whether we want to create a new
> command or use another method for setting this bit, and on the concept
> of "devfeatures" in general.

IMHO it depends a lot on what exactly "belong entirely to the driver"
means. If it means driver specific features, using a private flag would
seem more appropriate for this particular feature and then we can
discuss if we want some generalization of private flags for other types
of driver/device specific parameters (integers etc.). Personally, I'm
afraid that it would encourage driver developers to go this easier way
instead of trying to come with universal and future proof interfaces.

If this is supposed to gather universal features supported by multiple
drivers and devices, I suggest grouping it with existing parameters
handled as tunables in ioctl API. Or perhaps we could keep using the
name "tunables" and just handle them like any other command parameters
encoded as netlink attributes in the API.

Michal

> 
> One immediate feedback is that we're not adding any more commands to
> the ioctl API. You'll need to implement it in the netlink version of
> the ethtool API.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)