Re: [RFC] ethdev: introduce entropy calculation

[Ferruh Yigit <ferruh.yigit@amd.com>]

On 12/14/2023 5:26 PM, Stephen Hemminger wrote:
> On Thu, 14 Dec 2023 17:18:25 +0000
> Ori Kam <orika@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.