[RFC] ethdev: introduce entropy calculation
Ferruh Yigit
ferruh.yigit at amd.com
Fri Dec 15 14:44:02 CET 2023
On 12/14/2023 5:26 PM, Stephen Hemminger wrote:
> On Thu, 14 Dec 2023 17:18:25 +0000
> Ori Kam <orika at 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.
More information about the dev
mailing list