From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Hemminger Subject: Re: rte_hash thread safe Date: Mon, 23 Apr 2018 17:30:34 -0700 Message-ID: <20180423173034.7086b772@xeon-e3> References: <20180423165039.51393aad@xeon-e3> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Brijesh Singh , dev@dpdk.org To: Jim Murphy Return-path: Received: from mail-pg0-f68.google.com (mail-pg0-f68.google.com [74.125.83.68]) by dpdk.org (Postfix) with ESMTP id 7AB9FA69 for ; Tue, 24 Apr 2018 02:30:38 +0200 (CEST) Received: by mail-pg0-f68.google.com with SMTP id f132so9519338pgc.10 for ; Mon, 23 Apr 2018 17:30:38 -0700 (PDT) In-Reply-To: List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Mon, 23 Apr 2018 17:21:15 -0700 Jim Murphy wrote: > Has anyone seen performance data comparing rte_hash (perhaps with r/w > locks) versus URCU hash? >=20 >=20 > On Mon, Apr 23, 2018 at 4:50 PM, Stephen Hemminger < > stephen@networkplumber.org> wrote: =20 >=20 > > On Mon, 23 Apr 2018 12:40:41 -0700 > > Brijesh Singh wrote: > > =20 > > > 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) > > > > > > { > > > > > > > > > > > > =E2=80=A6 > > > > > > if (rte_hash_cmp_eq(key, k->key, h) =3D=3D 0)= { > > > > > > if (data !=3D NULL) > > > > > > *data =3D 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 > > > wrote: =20 > > > > 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 o= nly > > > > 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 operatio= ns > > > > 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 *ke= y, > > > > > > > > hash_sig_t sig, void **data) > > > > > > > > { > > > > > > > > > > > > > > > > =E2=80=A6 > > > > > > > > if (rte_hash_cmp_eq(key, k->key, h) =3D=3D = 0) { > > > > > > > > if (data !=3D NULL) > > > > > > > > *data =3D k->pdata; > > > > > > > > } > > > > > > > > Regards, > > > > Brijesh =20 > > > > 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. > > =20 No. But R/W locks are really slow. Look at one of Paul Mc Kenney's many RCU talks and papers.