Hi Cristian, > -----Original Message----- > From: Dumitrescu, Cristian <cristian.dumitre...@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?
