On Sun, Jun 28, 2015 at 10:23:28PM +0000, De Lara Guarch, Pablo wrote: > Hi Stephen, > > > -----Original Message----- > > From: Stephen Hemminger [mailto:stephen at networkplumber.org] > > Sent: Friday, June 26, 2015 5:50 PM > > To: De Lara Guarch, Pablo > > Cc: dev at dpdk.org > > Subject: Re: [dpdk-dev] [PATCH v2 08/11] hash: add new functionality to > > store data in hash table > > > > We did same thing with a slightly different method. > > > > Subject: rte_hash: split key and bucket size > > > > It is useful to store more data in the has bucket than just the key size. > > For example, storing an addresss and additional data. > > > > Signed-off-by: Stephen Hemminger <stephen at networkplumber.org> > > Did you send this patch? I did not see it in the mailing list... > Anyway, I like the idea of allowing the user to store variable size data (I > was storing 8-byte data). > So I have sent a v3 with a more similar method, although I still use the new > functions, > and use the parameter data_len for knowing the amount of bytes of data, and I > keep constant the input key, > and return the data in another parameter. > > Thanks for it! > Pablo
Hi Pablo, Stephen, having looked at the V3, having an arbitrary length of data stored in the hash table doesn't seem right to me. Since the original versions of this we have support for storing an 8-byte pointer in the hash table to be returned to the user on lookup, and I believe this provides the best option from an implementation and usability perspective. For cases where the data to be stored is fairly large, for example, 16/32 bytes or more, storing that in the hash table is going to waste a lot of space, and having the data stored outside the table is probably a better option, with a table lookup returning a pointer. We can even have the table lookup prefetch the pointer. It also allows multiple hash table lookups to point to the same external piece of data. For storing integer values, e.g. indexes into an external table, those can be stored as uintptr_t types in place of the pointer itself. Regards, /Bruce
