On 2023-10-16 17:30, Jakub Kicinski wrote:
On Mon, 16 Oct 2023 15:55:21 -0700 Alexander Duyck wrote:
It would make more sense to just add it as a variant hash function of
toeplitz. If you did it right you could probably make the formatting
pretty, something like:
RSS hash function:
toeplitz: on
symmetric xor: on
xor: off
crc32: off
It doesn't make sense to place it in the input flags and will just
cause quick congestion as things get added there. This is an algorithm
change so it makes more sense to place it there.
Algo is also a bit confusing, it's more like key pre-processing?
There's nothing toeplitz about xoring input fields. Works as well
for CRC32.. or XOR.
We can use one of the reserved fields of struct ethtool_rxfh to carry
this extension. I think I asked for this at some point, but there's
only so much repeated feedback one can send in a day :(
Sorry you felt that. I took you comment [1]:
"Using hashing algo for configuring fields feels like a dirty hack".
To mean that the we should not use the hfunc API ("ethtool_rxfh"). This
is why in the new series I chose to configure the RSS fields. This also
provides the user with more control and better granularity on which
flow-types to be symmetric, and which protocols (L3 and/or L4) to use. I
have no idea how to do any of these via hfunc/ethtool_rxfh API so it
seemed a better approach.
I see you marked the series as "Changes Requested". I will send a new
version tomorrow and move the sanity checks inside ice_ethtool.
[1]: https://lore.kernel.org/netdev/20230824174336.6fb801d5@xxxxxxxxxx/
