From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f181.google.com (mail-pf0-f181.google.com [209.85.192.181]) by dpdk.org (Postfix) with ESMTP id 3E4B723D for ; Tue, 24 Apr 2018 01:50:43 +0200 (CEST) Received: by mail-pf0-f181.google.com with SMTP id f15so10642187pfn.0 for ; Mon, 23 Apr 2018 16:50:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=EhKa/YTgMctdhLuVwU7C2doqZq+aouPCNWbJweHEwoY=; b=zHNY7WZuYvfubUqclzg0aGFXP8iKsHTuOtFUeXZ20kYRgtUX35lu1HwqdTaan02cft jZyO+4uBh+vWoiDwb0maMx6M9wIe7gJQxKfAD9QcEKRwXCObni6VUsVIP8GF8kWrzwQ8 PzvjWIfdocJQe7t2TzOHwf3sHzvDXtGKYAZJBF8naVHHRQjwVnk+Rye9n20iQa9AX8yR A/ZHLHc7KPQWTGyWJB8u2u2LwMHeZlT1dbv1ykHVcGfGuGgDGeqn3IgoToqNiW6Z/w5W S5O1geG0J+ROwIMq7OB3WRc+kWTmjix555pFev2iXGp0jNEYzxIp3CJ6I4kBFxPPXE4Z YUeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=EhKa/YTgMctdhLuVwU7C2doqZq+aouPCNWbJweHEwoY=; b=DaBQGsV8z9HLexR62Qw3JUxfHHlpPln2BrHhSS3m69WdEyePkErqrp1FyWgRTYMQm0 rTxTpRV7KmajTxAsKAEw409cAZjvdWGqbBQ9AFr+C+KgUO6Gcl+eduP581PXngDChaL1 dRQT4qpag92GAYtWZClaBqccHV7cwUNC/H2pm4Dbq+8/oIwb5qItsSnB8Z7Yek9DNw62 +H46RTnF2Bd77Qx+fBs3r0goW5km1MbuYR3AyDmrpMOjE+r/HmuqCclNshGVctarnNFS KkS822QOthFzebOSQ4vADaJLEKDsS5HfJzeHevELRBRkBuCcPGt9jJwU5KPRh3tMLWBN 1Haw== X-Gm-Message-State: ALQs6tAplhxHtweisn0EJ0KbZD9ATNuc1Zk3Do9X52M1a0Qd1kdsO6Bt I/skDpJMlVuNQ5ecbEFc2exf+w== X-Google-Smtp-Source: AB8JxZqOuIhddKQgIzsKtPVjrUIQBj6j3PFztikJvrfoiUDpDmObx2ZDliY3YMEMfPCW7Rmr3mmdFw== X-Received: by 2002:a17:902:ab83:: with SMTP id f3-v6mr1715263plr.344.1524527442313; Mon, 23 Apr 2018 16:50:42 -0700 (PDT) Received: from xeon-e3 (204-195-71-95.wavecable.com. [204.195.71.95]) by smtp.gmail.com with ESMTPSA id s189sm18364623pgc.39.2018.04.23.16.50.42 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 23 Apr 2018 16:50:42 -0700 (PDT) Date: Mon, 23 Apr 2018 16:50:39 -0700 From: Stephen Hemminger To: Brijesh Singh Cc: dev@dpdk.org Message-ID: <20180423165039.51393aad@xeon-e3> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] rte_hash thread safe X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 23:50:43 -0000 On Mon, 23 Apr 2018 12:40:41 -0700 Brijesh Singh wrote: > A gentle reminder, >=20 > 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: >=20 > _rte_hash_lookup_with_hash(const struct rte_hash *h, const void *key, >=20 > hash_sig_t sig, void **data) >=20 > { >=20 >=20 >=20 > =E2=80=A6 >=20 > if (rte_hash_cmp_eq(key, k->key, h) =3D=3D 0) { >=20 > if (data !=3D NULL) >=20 > *data =3D k->pdata; >=20 > } >=20 > 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. >=20 >=20 > Regards, > Brijesh >=20 > On Wed, Apr 11, 2018 at 9:12 PM, Brijesh Singh > 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) > > > > { > > > > > > > > =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.