From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f181.google.com (mail-wr0-f181.google.com [209.85.128.181]) by dpdk.org (Postfix) with ESMTP id 00B93A69 for ; Tue, 24 Apr 2018 02:21:15 +0200 (CEST) Received: by mail-wr0-f181.google.com with SMTP id q3-v6so35839634wrj.6 for ; Mon, 23 Apr 2018 17:21:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arista.com; s=googlenew; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1Dd/1gSJ34rVkPkzEeE1jR8JPjaz3aY6dAS0OXluhJU=; b=T5cmiRm4/KWNDfApjvZ8FHvHngCzCO6qlMV8SheVu5pK99aBP1eb9IaP+WXqXPf8lI DSPmyT2ihPukdj6ZLh/gLKzRh4XKbTIOToqw+afpDuaZwPF4hEzZyYQjpleGtvlOIOhD +pTPdihiFNphCpkjYmCMS4PgBV2qOlUlDrw2o6LVkxw1FJJVgg6JSxSKp8f3jPJjmEzO z54Jjl7b0Ayrb4ZUzVaNxUlyCuvzXXXyO3tvX76nhXw6HlnzUwToiunRPJ3IOXu9mSjA lEHo2aBH4VJ6d9H3RCTNgtIkswj3qRCAlbzKcbe03ViEBGZi1nicNlP0mP7n4/s3pM0c WPHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1Dd/1gSJ34rVkPkzEeE1jR8JPjaz3aY6dAS0OXluhJU=; b=Hi/25YQJ1NoMHl1FtV7HyB28X6KoEyjKMvnObVvvbN/YB8VXIgIVY1sd30pQDWCFMJ Q2o3DXSn3dGEW4kGau+tp9D7s4kuhl8TAhEAV3Ge2Sgc18lOVgAofWlsDZd1JcdsSumw 9WkE+QCB9pCNVG7o+YtMjiNycs56kjUDbftFasMnruf7bWwYNlD+GjhDkEslnZsAdNLE Mezn8REdx8BpshKLTFVRbbAPjLJEMMMSQP3bXGB1vEY6FhIb/hoYILaTuZJBGxrzLeS5 9Y3lZ/FvGIabJhLq7o0EGmaXcE/NyR/fLSQ4WFyTcvJxCXiFSj/8dYxdO3SVIGS29lre 4+dA== X-Gm-Message-State: ALQs6tDKma03kzp8j23/4FlcgT+SaKDrWOplVlKKiUSvioWIpOjTTfbE E1PehATikBd4mZZtznFfSXB0+8hwedgUjU/i1msjIIMK X-Google-Smtp-Source: AIpwx4/eG+FT2TL0s0bAJ2hG02JS5a+ijdu+jC6jhiJYdFRGZbwRIoKT9EMW3shXDsmDYEKUl4PnflaCBNjkR6xzjkY= X-Received: by 2002:adf:e642:: with SMTP id b2-v6mr13128875wrn.172.1524529275742; Mon, 23 Apr 2018 17:21:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.172.245 with HTTP; Mon, 23 Apr 2018 17:21:15 -0700 (PDT) In-Reply-To: <20180423165039.51393aad@xeon-e3> References: <20180423165039.51393aad@xeon-e3> From: Jim Murphy Date: Mon, 23 Apr 2018 17:21:15 -0700 Message-ID: To: Stephen Hemminger Cc: Brijesh Singh , dev@dpdk.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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:21:16 -0000 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@networkplumber.org> wrote: > On Mon, 23 Apr 2018 12:40:41 -0700 > Brijesh Singh 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) > > > > { > > > > > > > > =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: > > > Hello, > > > > > > I want to use DPDK's rte_hash library to keep track of tcp flows. Th= e > > > lookups will be done by multiple threads but inserts will be done onl= y > > > on one thread. > > > > > > As per the documentation rte_hash library has thread safe lookups. Ke= y > > > /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 > > 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. >