Re: [dpdk-dev] [PATCH v2 08/11] hash: add new functionality to store data in hash table

[Bruce Richardson <bruce.richardson@intel.com>]

On Sun, Jun 28, 2015 at 10:23:28PM +0000, De Lara Guarch, Pablo wrote:
> Hi Stephen,
> 
> > -----Original Message-----
> > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > Sent: Friday, June 26, 2015 5:50 PM
> > To: De Lara Guarch, Pablo
> > Cc: dev@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@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