From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f196.google.com (mail-wr0-f196.google.com [209.85.128.196]) by dpdk.org (Postfix) with ESMTP id 33D20CF3 for ; Tue, 24 Apr 2018 02:48:51 +0200 (CEST) Received: by mail-wr0-f196.google.com with SMTP id s18-v6so45920984wrg.9 for ; Mon, 23 Apr 2018 17:48:51 -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=pRMbtvfvNye97ZbVzsK1yvSg8wl43nhBz5CtFWbG3tU=; b=WVWWOK5aGtC7dutNAJ0rP3sf14tDfCqsE3No8P7Wau4+1XQPpi0I+1i9Omc9aSI5Xr Y8ckLJ0KFjzqoZeQNwFQnF9k4XiOEHWLfTNcw79OzKAu71R0Mm8dzi6AxQd61R/ntVbt bRCScxNkLngQ91fhwh8hPiTUUhSU2MWTQ9RBp2WBB1bT7w3xxMt8/kPgTJoSKBRkRu/d GbhDrQ+AJ3Fcl3NkmuiZmsMwtF4vod9LbugiZDswvxld5fb2zyjCuKsJxqII0n+9qR0F Bmavzvdb0YPq/d0qC5KzTLivEaQIF9PbTIrNIpZPZWlbRRCna9fqwe846z++b3abUHKe pcyg== 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=pRMbtvfvNye97ZbVzsK1yvSg8wl43nhBz5CtFWbG3tU=; b=nbPaL3taa8feiwaE4pdqQgk7+jGha15aV4CxJT3hg+EFInwW2DtofLWEnB7ubD5xeD Rf/+yJxZPopeZaxHbWFZW9lwgW3RFMdnVHiMGR0s6ZeYHuuhAZ6CWyrsgy7fc9HWaqm8 GasSoYxE4qA2HLrRqiUBsovnudLH9rFFNXe3ECMx4saDNuQPw6phS1wNXHTQEMTNhHcR ViaiR3kLVdYZLeWVjxr5/eC+R8g8MNCgmz9vlQev+Ctf+qh+1G4vbLy4ImStvk2Xf6QE bFPjUmLZH+KHVWY9iJqHtam6sNOeT1J8IcEzI05LBx+8Q0MLK1AQqXjar0+JjkBONHu0 qIWw== X-Gm-Message-State: ALQs6tAMvk5ji+OZwGeO4lwoRmTFSZlRy42umNW4HfBoeRLLWY7AiUiQ BaJ6nZShGhpNOCn7o551Vx005lVOFyflz1qNtKawMw== X-Google-Smtp-Source: AIpwx4/cd+3tH+YMurl9pvDb9HeXGqmReywXUtMsNdFtuN53Zdt0KRL578N1P7PSlSk9J33KaNAks3xpEpQe0K2FKxQ= X-Received: by 2002:adf:e5c6:: with SMTP id a6-v6mr16121243wrn.229.1524530931081; Mon, 23 Apr 2018 17:48:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.172.245 with HTTP; Mon, 23 Apr 2018 17:48:50 -0700 (PDT) In-Reply-To: <20180423173034.7086b772@xeon-e3> References: <20180423165039.51393aad@xeon-e3> <20180423173034.7086b772@xeon-e3> From: Jim Murphy Date: Mon, 23 Apr 2018 17:48:50 -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:48:52 -0000 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? On Mon, Apr 23, 2018 at 5:30 PM, Stephen Hemminger < stephen@networkplumber.org> wrote: > 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? > > > > > > 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 t= he > > > > 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= . > 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 > > > > > > 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 require= s > > > 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 R= CU > talks and papers. >