[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200304102840.3fb9eef2@kicinski-fedora-PC1C0HJN>
Date: Wed, 4 Mar 2020 10:28:40 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Edward Cree <ecree@...arflare.com>
Cc: Alexander Duyck <alexander.h.duyck@...ux.intel.com>,
Michal Kubecek <mkubecek@...e.cz>, <davem@...emloft.net>,
<thomas.lendacky@....com>, <benve@...co.com>, <_govind@....com>,
<pkaustub@...co.com>, <peppe.cavallaro@...com>,
<alexandre.torgue@...com>, <joabreu@...opsys.com>,
<snelson@...sando.io>, <yisen.zhuang@...wei.com>,
<salil.mehta@...wei.com>, <jeffrey.t.kirsher@...el.com>,
<jacob.e.keller@...el.com>, <michael.chan@...adcom.com>,
<saeedm@...lanox.com>, <leon@...nel.org>, <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next v2 01/12] ethtool: add infrastructure for
centralized checking of coalescing parameters
On Wed, 4 Mar 2020 18:16:13 +0000 Edward Cree wrote:
> On 04/03/2020 18:12, Alexander Duyck wrote:
> > So one thing I just wanted to point out. The used_types won't necessarily
> > be correct because it is only actually checking for non-zero types. There
> > are some of these values where a zero is a valid input
> Presumably in the netlink ethtool world we'll want to instead check if
> the attribute was passed? Not sure but that might affect what semantics
> we want to imply now.
I mean... it's just a local variable in a helper... :)
I think netlink will need its own helper based on attribute presence,
as you said.
Powered by blists - more mailing lists