On Thu, Sep 18, 2014 at 03:31:34PM +0000, De Lara Guarch, Pablo wrote: > Hi Neil, > > > -----Original Message----- > > From: Neil Horman [mailto:nhorman at tuxdriver.com] > > Sent: Thursday, September 18, 2014 1:21 PM > > To: De Lara Guarch, Pablo > > Cc: dev at dpdk.org > > Subject: Re: [dpdk-dev] [PATCH 0/3] New Thread Safe Hash Library > > > > On Thu, Sep 18, 2014 at 11:34:28AM +0100, Pablo de Lara wrote: > > > This is an alternative hash implementation to the existing hash library. > > > This patch set provides a thread safe hash implementation, it allows users > > > to use multiple readers/writers working on a same hash table. > > > Main differences between the previous and the new implementation are: > > > > > > - Multiple readers/writers can work on the same hash table, > > > whereas in the previous implementation writers could not work > > > on the table at the same time readers do. > > > - Previous implementation returned an index to a table after a lookup. > > > This implementation returns 8-byte integers or pointers to external > > > data. > > > - Maximum entries to be looked up in bursts is 64, instead of 16. > > > - Maximum key length has being increased to 128, instead of a maximum of > > 64. > > > > > > Basic implementation: > > > > > > - A sparse table containing buckets (64-byte long) with hashes, > > > most of which are empty, and indexes to the second table. > > > - A compact table containing keys for final matching, > > > plus data associated to them. > > > > > Thread safe hash tables seem to me like a configuration option rather than a > > new > > library. Instead of creating a whole new library (with a new API and ABI to > > maintain, why not just add thread safety as a configurable option to the > > existing hash library. That saves code space in the DPDK, and reduces > > application complexity (as the same api is useable for thread safe and > > unsafe > > hash tables) > > Makes sense, but implementation has changed so much to add it directly into > the existing library. > At first, this was designed to be a replacement of the existing library, > but since API is a bit different from the old one, it was thought to leave it > as an alternative, > so users are not forced to have to change their applications if they don't > want to use thread safe hash tables.
What are you talking about? The API calls between rte_hash and the new rte_tshash are identical. The only thing that differs are the names slightly (rte_hash vs rte_tshash), and some of the elements of the internal data structure, which really shouldn't be accessed by the application anyway (though that does play into some of the ABI work we've started looking at). It should be pretty easy to modify the rte_hash library to optionally include thread safety. A flag in the config structure, a spinlock in the internal representation, and you're home free. Neil
