[dpdk-dev] rte_hash thread safe

Jerin Jacob jerin.jacob at caviumnetworks.com
Tue Apr 24 05:48:54 CEST 2018


-----Original Message-----
> Date: Mon, 23 Apr 2018 17:48:50 -0700
> From: Jim Murphy <jmurphy at arista.com>
> To: Stephen Hemminger <stephen at networkplumber.org>
> Cc: Brijesh Singh <brijesh.s.singh at gmail.com>, dev at dpdk.org
> Subject: Re: [dpdk-dev] rte_hash thread safe
> 
> Anecdotally I've heard that the urcu hash implementation is slower than
> rte_hash based on pure lookup performance. Has anyone considered adding RCU
> hooks into rte_hash?


For one of our internal project on arm64, we did try rte_hash vs URCU hash.
Based on our results URCU lookup was much better. By default, URCU
library does not allocate the memory from huge page, But it has some
plugin based scheme to override the memory allocation scheme to choose
hugepage using DPDK backend.


> 
> 
> On Mon, Apr 23, 2018 at 5:30 PM, Stephen Hemminger <
> stephen at networkplumber.org> wrote:
> 
> > On Mon, 23 Apr 2018 17:21:15 -0700
> > Jim Murphy <jmurphy at arista.com> wrote:
> >
> > > Has anyone seen performance data comparing rte_hash (perhaps with r/w
> > > locks) versus URCU hash?
> > >
> > >
> > > On Mon, Apr 23, 2018 at 4:50 PM, Stephen Hemminger <
> > > stephen at networkplumber.org> wrote:
> > >
> > > > On Mon, 23 Apr 2018 12:40:41 -0700
> > > > Brijesh Singh <brijesh.s.singh at gmail.com> wrote:
> > > >
> > > > > A gentle reminder,
> > > > >
> > > > > I am curious to know if/how rte_hash is thread safe for lookups.It is
> > > > > not obvious to me how following code is thread safe:
> > > > >
> > > > > _rte_hash_lookup_with_hash(const struct rte_hash *h, const void
> > *key,
> > > > >
> > > > >                                         hash_sig_t sig, void **data)
> > > > >
> > > > > {
> > > > >
> > > > >
> > > > >
> > > > > …
> > > > >
> > > > >                         if (rte_hash_cmp_eq(key, k->key, h) == 0) {
> > > > >
> > > > >                                 if (data != NULL)
> > > > >
> > > > >                                         *data = k->pdata;
> > > > >
> > > > > }
> > > > >
> > > > > a key could be deleted and another key inserted in its slot while the
> > > > > lookup is happening. For example, in the following sequence of
> > events:
> > > > > The slot has Key1,V1
> > > > > Lookup Thread T1 compares the input key to Key1 and it matches. The
> > > > > thread gets context switched out
> > > > > Thread T2 deletes Key1.
> > > > > Thread T2 inserts Key2 with value V2.
> > > > > T1 reads the data from the slot and returns V2. This is incorrect.
> > > > >
> > > > >
> > > > > Regards,
> > > > > Brijesh
> > > > >
> > > > > On Wed, Apr 11, 2018 at 9:12 PM, Brijesh Singh
> > > > > <brijesh.s.singh at gmail.com> wrote:
> > > > > > Hello,
> > > > > >
> > > > > > I  want to use DPDK's rte_hash library to keep track of tcp flows.
> > The
> > > > > > lookups will be done by multiple threads but inserts will be done
> > only
> > > > > > on one thread.
> > > > > >
> > > > > > As per the documentation rte_hash library has thread safe lookups.
> > Key
> > > > > > /data inserts should be done on single thread, since those
> > operations
> > > > > > are not thread safe. Is this documentation still correct?
> > > > > >
> > > > > > The lookup code compares the key and returns the data if the key
> > > > > > matches, this doesn't look like thread safe. Am I missing
> > something?
> > > > > >
> > > > > > _rte_hash_lookup_with_hash(const struct rte_hash *h, const void
> > *key,
> > > > > >
> > > > > >                                         hash_sig_t sig, void
> > **data)
> > > > > >
> > > > > > {
> > > > > >
> > > > > >
> > > > > >
> > > > > > …
> > > > > >
> > > > > >                         if (rte_hash_cmp_eq(key, k->key, h) == 0) {
> > > > > >
> > > > > >                                 if (data != NULL)
> > > > > >
> > > > > >                                         *data = k->pdata;
> > > > > >
> > > > > > }
> > > > > >
> > > > > > Regards,
> > > > > > Brijesh
> > > >
> > > > The best way to handle this is to do some kind of Read Copy Update.
> > > > Unfortunately, this is not possible in scope of DPDK since it requires
> > > > cooperation from application threads.
> > > >
> > > > If you need thread safe hash table, my recommendation would be to
> > > > skip the DPDK hash library and use userspace RCU instead:
> > > >   http://liburcu.org/
> > > >
> > > > Note: URCU is LGPL versus BSD licensed. But then any non trivial
> > > > Linux application needs to use LGPL libraries already.
> > > >
> >
> > No. But R/W locks are really slow. Look at one of Paul Mc Kenney's many RCU
> > talks and papers.
> >


More information about the dev mailing list