[RFC] ethdev: introduce entropy calculation
Stephen Hemminger
stephen at networkplumber.org
Thu Dec 14 18:26:09 CET 2023
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?
More information about the dev
mailing list