Re: [PATCH net-next 3/5] net: ethtool: add KUnit tests for the generated RSS key

[Jakub Kicinski <kuba@kernel.org>]

On Mon, 21 Sep 2026 18:37:56 +0000 Eric Dumazet wrote:
> Check the property from the definition of the Toeplitz hash, independently
> of the way netdev_rss_key_init() achieves it: an aligned block of 2^q
> consecutive values of one field has to land on the 2^q queues exactly once
> each.
> 
> Four checks and a control. rss_key_property_test() does the algebra for
> the named fields of the usual hash inputs, rss_key_grid_test() sweeps every
> 16-bit aligned position of the key, since the generator does not get to
> know the layout the hardware uses, and rss_key_spread_test() hashes the
> inputs of an actual burst and looks at where they land. The control,
> rss_key_checker_test(), feeds degenerate keys to the rank check so that a
> check accepting everything cannot make the others pass.
> 
> rss_key_alias_test() covers the other half of what the generator promises,
> that no two input bits read the same 32-bit key window and are therefore
> indistinguishable to the hash. It sorts the windows instead of comparing
> them pairwise, so unlike netdev_rss_key_init() it looks at every distance
> rather than at the multiples of 16 alone.
> 
> The field table includes a PSP over UDP over IPv6 layout, whose inner TCP
> ports sit far past the plain 4-tuple, because that is the case the offsets
> of the standard layouts do not cover.
> 
> Commenting out the fixup makes three of the five cases fail and leaves the
> control passing. Keeping the fixup but skipping the redraw fails
> rss_key_alias_test alone.

Is this AI generated or do you think there's some genuine value here?
I don't want kunits which can be trivially re-generated during
development to be merged. But perhaps there's some genuine value in
this one?