On 12/15/23 19:21, Thomas Monjalon wrote:
15/12/2023 14:44, Ferruh Yigit:
On 12/14/2023 5:26 PM, Stephen Hemminger wrote:
On Thu, 14 Dec 2023 17:18:25 +0000
Ori Kam <or...@nvidia.com> wrote:
Since encap groups number of different 5 tuples together, if HW doesn’t know
how to RSS
based on the inner application will not be able to get any distribution of
packets.
This value is used to reflect the inner packet on the outer header, so
distribution
will be possible.
The main use case is, if application does full offload and implements the encap
on
the RX.
For example:
Ingress/FDB match on 5 tuple encap send to hairpin / different port in case of
switch.
Smart idea! So basically the user is able to get an idea on how good the RSS
distribution is, correct?
Not exactly, this simply allows the distribution.
Maybe entropy is a bad name, this is the name they use in the protocol, but in
reality
this is some hash calculated on the packet header before the encap and set in
the encap header.
Using this hash results in entropy for the packets. Which can be used for load
balancing.
Maybe better name would be:
Rte_flow_calc_entropy_hash?
or maybe rte_flow_calc_encap_hash (I like it less since it looks like we
calculate the hash on the encap data and not the inner part)
what do you think?
Entropy has meaning in crypto and random numbers generators that is different
from
this usage. So entropy is bad name to use. Maybe rte_flow_hash_distribution?
Hi Ori,
Thank you for the description, it is more clear now.
And unless this is specifically defined as 'entropy' in spec, I am too
for rename.
At least in VXLAN spec, it is mentioned that this field is to "enable a
level of entropy", but not exactly names it as entropy.
Exactly my thought about the naming.
Good to see I am not alone thinking this naming is disturbing :)
I'd avoid usage of term "entropy" in this patch. It is very confusing.
