[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <34b00cfb-d1d7-4468-948b-a44591dc5923@intel.com>
Date: Wed, 3 Jan 2024 08:40:47 -0700
From: Ahmed Zaki <ahmed.zaki@...el.com>
To: Jakub Kicinski <kuba@...nel.org>
CC: <netdev@...r.kernel.org>, <corbet@....net>, <jesse.brandeburg@...el.com>,
<anthony.l.nguyen@...el.com>, <davem@...emloft.net>, <edumazet@...gle.com>,
<pabeni@...hat.com>, <vladimir.oltean@....com>, <andrew@...n.ch>,
<horms@...nel.org>, <mkubecek@...e.cz>, <willemdebruijn.kernel@...il.com>,
<gal@...dia.com>, <alexander.duyck@...il.com>, <ecree.xilinx@...il.com>,
Jacob Keller <jacob.e.keller@...el.com>
Subject: Re: [PATCH net-next 2/2] net: ethtool: add a NO_CHANGE uAPI for new
RXFH's input_xfrm
On 2024-01-02 17:05, Jakub Kicinski wrote:
> On Thu, 21 Dec 2023 11:42:35 -0700 Ahmed Zaki wrote:
>> + rxfh.key_size == 0 && rxfh.hfunc == ETH_RSS_HASH_NO_CHANGE &&
>> + rxfh.input_xfrm == RXH_XFRM_NO_CHANGE))
>
> This looks fine, but we also need a check to make sure input_xfrm
> doesn't have bits other than RXH_XFRM_SYM_XOR set, right?
I wrote the xfrm as a bitmap/flags assuming we can have multiple
transformations set. Not sure what future transformations will look like
(other than RSS-sort,... and discussed before).
Else, we can do the check you mentioned or may be better to have it as
enum (which would give us 256, not 8, allowable transformations).
Powered by blists - more mailing lists