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] [day] [month] [year] [list]
Date:   Mon, 16 Nov 2020 10:12:36 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     tanhuazhong <tanhuazhong@...wei.com>
Cc:     Michal Kubecek <mkubecek@...e.cz>, Andrew Lunn <andrew@...n.ch>,
        Jiri Pirko <jiri@...nulli.us>, <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 Mon, 16 Nov 2020 16:41:45 +0800 tanhuazhong wrote:
> On 2020/11/15 2:54, Jakub Kicinski wrote:
> > 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).
> 
> The device's implementation of IRQ coalescing will be removed, if DIM 
> works ok for a long time. So could this private flag for DIM be 
> uptreamed as a transition scheme? And adding a new netlink attrtibute to 
> controls the type of adaptive coalescing seems useless for other drivers.

The information whether the adaptive behavior is implemented by DIM,
device or custom driver implementation is useful regardless. Right now
users only see "adaptive" and don't know what implements it - device,
DIM or is it a custom implementation in the driver. So regardless if
you remove the priv flag, the "read"/"get" side of the information will
still be useful.

Besides you have another priv flag in this set that needs to be
converted to a generic attribute - the one for the timer reset
behavior.

Powered by blists - more mailing lists