On 2023-10-07 03:01, Willem de Bruijn wrote:
On Fri, Oct 6, 2023 at 7:22 PM Jakub Kicinski <kuba@xxxxxxxxxx> wrote:
On Fri, 6 Oct 2023 16:47:21 -0600 Ahmed Zaki wrote:
Symmetric RSS hash functions are beneficial in applications that monitor
both Tx and Rx packets of the same flow (IDS, software firewalls, ..etc).
Getting all traffic of the same flow on the same RX queue results in
higher CPU cache efficiency.
Only fields that has counterparts in the other direction can be
accepted; IP src/dst and L4 src/dst ports.
The user may request RSS hash symmetry for a specific flow type, via:
# ethtool -N|-U eth0 rx-flow-hash <flow_type> s|d|f|n symmetric
or turn symmetry off (asymmetric) by:
# ethtool -N|-U eth0 rx-flow-hash <flow_type> s|d|f|n
Thanks for the changes, code looks good!
The question left unanswered is whether we should care about the exact
implementation of the symmetry (xor, xor duplicate, sort fields).
Toeplitz-based RSS is very precisely specified, so we may want to carry
that precision into the symmetric behavior. I have a weak preference
to do so... but no willingness to argue with you, so let me put Willem
on the spot and have him make a decision :)
I do have a stronger willingness to argue, thanks ;-)
Can we give a more precise name, such as symmetric-xor? In case
another device would implement another mode, such as the symmetric
toeplitz of __flow_hash_consistentify, it would be good to be able to
discern the modes.
I agree that implementation matters. I changed "symmetric" to
"symmetric-xor" in v3.
Thanks for the review.
