[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <191d5c1c-7a86-4309-9e74-0bc275c01e45@nvidia.com>
Date: Sun, 9 Feb 2025 09:59:22 +0200
From: Gal Pressman <gal@...dia.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
Simon Horman <horms@...nel.org>, Jonathan Corbet <corbet@....net>,
Tony Nguyen <anthony.l.nguyen@...el.com>,
Przemek Kitszel <przemyslaw.kitszel@...el.com>,
Andrew Lunn <andrew+netdev@...n.ch>, Tariq Toukan <tariqt@...dia.com>,
Edward Cree <ecree.xilinx@...il.com>, Ahmed Zaki <ahmed.zaki@...el.com>,
linux-doc@...r.kernel.org
Subject: Re: [PATCH net-next v2 0/2] Symmetric OR-XOR RSS hash
On 07/02/2025 3:32, Jakub Kicinski wrote:
> On Wed, 5 Feb 2025 15:53:39 +0200 Gal Pressman wrote:
>> Add support for a new type of input_xfrm: Symmetric OR-XOR.
>> Symmetric OR-XOR performs hash as follows:
>> (SRC_IP | DST_IP, SRC_IP ^ DST_IP, SRC_PORT | DST_PORT, SRC_PORT ^ DST_PORT)
>>
>> Configuration is done through ethtool -x/X command.
>> For mlx5, the default is already symmetric hash, this patch now exposes
>> this to userspace and allows enabling/disabling of the feature.
>
> Please add a selftest (hw-only is fine, netdevsim can't do flow
> hashing).
I don't understand the rationale, the new input_xfrm field didn't
deserve a selftest, why does a new value to the field does?
Testing this would require new userspace ethtool (which has not been
submitted yet), I don't think it's wise to implement a test before the
user interface/output is merged.
I assume you want an additional case in rss_ctx.py?
Powered by blists - more mailing lists