[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c935cb595ad8a036a277a279e9ba34c9f194a491.camel@linux.intel.com>
Date: Thu, 05 Mar 2020 08:24:07 -0800
From: Alexander Duyck <alexander.h.duyck@...ux.intel.com>
To: Jakub Kicinski <kuba@...nel.org>, davem@...emloft.net
Cc: andrew@...n.ch, ecree@...arflare.com, mkubecek@...e.cz,
thomas.lendacky@....com, benve@...co.com, _govind@....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 v3 01/12] ethtool: add infrastructure for
centralized checking of coalescing parameters
On Wed, 2020-03-04 at 21:15 -0800, Jakub Kicinski wrote:
> Linux supports 22 different interrupt coalescing parameters.
> No driver implements them all. Some drivers just ignore the
> ones they don't support, while others have to carry a long
> list of checks to reject unsupported settings.
>
> To simplify the drivers add the ability to specify inside
> ethtool_ops which parameters are supported and let the core
> reject attempts to set any other one.
>
> This commit makes the mechanism an opt-in, only drivers which
> set ethtool_opts->coalesce_types to a non-zero value will have
> the checks enforced.
>
> The same mask is used for global and per queue settings.
>
> v3: - move the (temporary) check if driver defines types
> earlier (Michal)
> - rename used_types -> nonzero_params, and
> coalesce_types -> supported_coalesce_params (Alex)
> - use EOPNOTSUPP instead of EINVAL (Andrew, Michal)
>
> Leaving the long series of ifs for now, it seems nice to
> be able to grep for the field and flag names. This will
> probably have to be revisited once netlink support lands.
>
> Signed-off-by: Jakub Kicinski <kuba@...nel.org>
> Reviewed-by: Jacob Keller <jacob.e.keller@...el.com>
> ---
Reviewed-by: Alexander Duyck <alexander.h.duyck@...ux.intel.com>
Powered by blists - more mailing lists