From mboxrd@z Thu Jan 1 00:00:00 1970 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) 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=TDJwhA2RHUmCOyt+0D8QPGvT+SBCgjz675ibEtc6G/I=; b=MlxsuQ24XR28B/F1Yn0Ol1c+UuAcaOpj959wDcZWCOhK0c4jdm/944Y97dO5KcGYEz 40MrD2Uny2coFSzsJbs9/Mu69WGgzApIl33bi3MnNd6vHcP2wixmSQdGAohI4GVYvb+M hfLv+ewO3k6YGcfTo1a9Ma/Qsk5Wi6dT9+TN0/B/xNomOlOq7q6MOx4+27tKL2MNKrWs 89mIZutoG+4osDPpjt82ugs/O3A2lxFAnfVjJ9pKLAR/unXyx/yYyvlp2Hfy18f9yRWt SWxxdpDbsNQcSY2MrK7HM4Vrk0UZKqzJPtzAGfgQAkJ2zA1QM5ioIwKbVL5ThYTjk9FC 9h5g== 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=TDJwhA2RHUmCOyt+0D8QPGvT+SBCgjz675ibEtc6G/I=; b=Z51al3QD1peWOLXRHikKjC5T7Mr9JN7mgzU2OnRWXmCCqVMmSqt5CSKOJn+ahlP0w0 tIhrvei77Mn40eIeGf1nxQ6oMHITOxaU0PavcWsTklRHpytb2BjqgDj44r6t30ZVd4Us 1Poge29VHqU/AN/arFhoxULJpQEILet80yZtZS89RDtwNu20HZDMLc0tgscFegwwoAWg a/OLswQkvaOYRCeMyZQ9Q7IgNfx40jGEgabtjPbdXEpK3hCFa47VJ2d7O/wvusbC9Hsf vXzOE7QXuMgu4Hk6GQCnWo2ChW+RPnA7BSPZKlABPLyeo9NlN2woYZ2C2ClrZLAuOEDg sghg== X-Gm-Message-State: ALQs6tDfzIUcTaBrdZFr2XYyPd1IWaI1/qE63tF+fkB+K2H4IxBvLp5+ zJPPHHpX8d9Manu5AZr/+VQzsA== X-Google-Smtp-Source: AIpwx48hyPKUSjhkj86ya+pRocsgYfC3eVj+oDrjQPTUv1nGP6/HqAGOkxexD8Ie1pyeIzNml9AW2g== X-Received: by 10.167.130.76 with SMTP id e12mr21807440pfn.192.1524529837233; Mon, 23 Apr 2018 17:30:37 -0700 (PDT) Received: from xeon-e3 (204-195-71-95.wavecable.com. [204.195.71.95]) by smtp.gmail.com with ESMTPSA id z16sm1787639pgv.59.2018.04.23.17.30.36 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 23 Apr 2018 17:30:37 -0700 (PDT) Date: Mon, 23 Apr 2018 17:30:34 -0700 From: Stephen Hemminger To: Jim Murphy Cc: Brijesh Singh , dev@dpdk.org Message-ID: <20180423173034.7086b772@xeon-e3> In-Reply-To: References: <20180423165039.51393aad@xeon-e3> 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: Tue, 24 Apr 2018 00:30:38 -0000 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.