04/01/2024 15:33, Ori Kam: > Hi Cristian, > > > 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?
I like the idea of having a single function for HW hashes. Is there an impact on performance? How much is it sensitive?
