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.
