[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220315121529.45f0a9d1@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date: Tue, 15 Mar 2022 12:15:29 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: 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 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.
Powered by blists - more mailing lists