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]

Date:   Tue, 15 Mar 2022 13:03:00 -0700
From:   Roopa Prabhu <roopa@...dia.com>
To:     Jakub Kicinski <kuba@...nel.org>, Jie Wang <wangjie125@...wei.com>
Cc:     mkubecek@...e.cz, 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 3/15/22 12:15, 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.
>
> 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.

+1,  it would have been nice if we did not have to expose the change in 
api for features via  a new option.

harder for user to track which features need new option.

ie, if possible, it would be better to internally transition new 
features to new api.

(i have not looked yet if moving to netlink will make the above point moot)