Re: [RFC] ethdev: introduce entropy calculation

[Stephen Hemminger <stephen@networkplumber.org>]

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?