[RFC] ethdev: introduce entropy calculation

[Thomas Monjalon]

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?