[RFC] ethdev: introduce entropy calculation

[Dumitrescu, Cristian]

> -----Original Message-----
> From: Ori Kam <orika at nvidia.com>
> Sent: Wednesday, December 27, 2023 3:20 PM
> To: Andrew Rybchenko <andrew.rybchenko at oktetlabs.ru>; NBU-Contact-
> Thomas Monjalon (EXTERNAL) <thomas at monjalon.net>; Stephen Hemminger
> <stephen at networkplumber.org>; Ferruh Yigit <ferruh.yigit at amd.com>
> Cc: Dumitrescu, Cristian <cristian.dumitrescu at intel.com>; Dariusz Sosnowski
> <dsosnowski at nvidia.com>; dev at dpdk.org; Raslan Darawsheh
> <rasland at nvidia.com>
> Subject: RE: [RFC] ethdev: introduce entropy calculation
> 
> Hi Andrew, Stephen, Ferruh and Thomas,
> 
> > -----Original Message-----
> > From: Andrew Rybchenko <andrew.rybchenko at oktetlabs.ru>
> > Sent: Saturday, December 16, 2023 11:04 AM
> >
> > 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 <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.
> > >
> > > 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.
> 
> What about rte_flow_calc_encap_hash?
> 
> 
How about simply rte_flow_calc_hash? My understanding is this is a general-purpose hash that is not limited to encapsulation work.