[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220315184013.0b5970c1@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date: Tue, 15 Mar 2022 18:40:13 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Roopa Prabhu <roopa@...dia.com>
Cc: Jie Wang <wangjie125@...wei.com>, 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 13:03:00 -0700 Roopa Prabhu wrote:
> > 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)
The slight wrinkle on the usual feature API is that it's out of bits
and the work on moving it to bitmap has stalled :S
Powered by blists - more mailing lists