[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201114105423.07c2ce67@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date: Sat, 14 Nov 2020 10:54:23 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Huazhong Tan <tanhuazhong@...wei.com>,
Michal Kubecek <mkubecek@...e.cz>,
Andrew Lunn <andrew@...n.ch>, Jiri Pirko <jiri@...nulli.us>
Cc: <davem@...emloft.net>, <netdev@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <salil.mehta@...wei.com>,
<yisen.zhuang@...wei.com>, <linuxarm@...wei.com>
Subject: Re: [PATCH V3 net-next 06/10] net: hns3: add ethtool priv-flag for
DIM
On Thu, 12 Nov 2020 11:33:14 +0800 Huazhong Tan wrote:
> Add a control private flag in ethtool for enable/disable
> DIM feature.
>
> Signed-off-by: Huazhong Tan <tanhuazhong@...wei.com>
Please work on a common ethtool API for the configuration instead of
using private flags.
Private flags were overused because the old IOCTL-based ethtool was
hard to extend, but we have a netlink API now.
For example here you're making a choice between device and DIM
implementation of IRQ coalescing. You can add a new netlink attribute
to the ETHTOOL_MSG_COALESCE_GET/ETHTOOL_MSG_COALESCE_SET commands which
controls the type of adaptive coalescing (if enabled).
One question I don't think we have a strong answer for is how to handle
this extension from ethtool_ops point of view. Should we add a new
"extended" op which drivers may start implementing? Or separate the
structure passed in to the ops from the one used as uAPI?
Thoughts anyone?
Huazhong Tan, since the DIM and EQ/CQ patches may require more
infrastructure work feel free to repost the first 4 patches separately,
I can apply those as is.
Powered by blists - more mailing lists