[RFC] ethdev: introduce entropy calculation

[Ori Kam]

Hi

> -----Original Message-----
> From: Thomas Monjalon <thomas at monjalon.net>
> Sent: Thursday, January 4, 2024 8:19 PM
> 
> 04/01/2024 15:33, Ori Kam:
> > Hi Cristian,
> >
> > > From: Dumitrescu, Cristian <cristian.dumitrescu at intel.com>
> > > Sent: Thursday, January 4, 2024 2:57 PM
> > > > > >>
> > > > > >> 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.
> >
> > Unfortunately, this is not a general-purpose hash.  HW may implement a
> different hash for each use case.
> > also, the hash result is length differs depending on the feature and even the
> target field.
> >
> > We can take your naming idea and change the parameters a bit:
> > rte_flow_calc_hash(port, feature, *attribute, pattern, hash_len, *hash)
> >
> > For the feature we will have at this point:
> > NVGRE_HASH,
> > SPORT_HASH
> >
> > The attribute parameter will be empty for now, but it may be used later to
> add extra information
> > for the hash if more information is required, for example, some key.
> > In addition, we will also be able to merge the current function
> rte_flow_calc_table_hash,
> > if we pass the missing parameters (table id, template id) in the attribute field.
> >
> > What do you think?
> 
> I like the idea of having a single function for HW hashes.
> Is there an impact on performance? How much is it sensitive?
> 
> 
It is sensitive since we expect this function to be called for each packet.
This may not be such a great idea.
So, back to square one and keep the rte_flow_calc_encap_hash