From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
by inbox.dpdk.org (Postfix) with ESMTP id 6FFFFA0540;
Wed, 6 Jul 2022 17:23:05 +0200 (CEST)
Received: from [217.70.189.124] (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id 1750340687;
Wed, 6 Jul 2022 17:23:05 +0200 (CEST)
Received: from mail-pj1-f53.google.com (mail-pj1-f53.google.com
[209.85.216.53]) by mails.dpdk.org (Postfix) with ESMTP id 7A9A740156
for <dev@dpdk.org>; Wed, 6 Jul 2022 17:23:03 +0200 (CEST)
Received: by mail-pj1-f53.google.com with SMTP id s21so10994342pjq.4
for <dev@dpdk.org>; Wed, 06 Jul 2022 08:23:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=networkplumber-org.20210112.gappssmtp.com; s=20210112;
h=date:from:to:cc:subject:message-id:in-reply-to:references
:mime-version:content-transfer-encoding;
bh=5KxF/gRFMralAx7IdGwLVe2/maflMLJ7+wYI7rX+bTU=;
b=q0p9yeMb3hiKdMwv6rOlsHvI9KKLjbJi7L90UAD0TSmRYSj6x1DiJTIVgUc5ARInHi
dXU8Ik7qPfPpFXYI13hVpDk8jhAq6rY+jT6YJqAdBlNpkbFPQb4aTK5ZoK1+zD2sTGrj
/S0/Rx7DoK5NS2h8t4cZKvIm7zr6/h5ZFDO5NevpUlVdrQWk73sn8mXSGjZ+I9fmhpiD
otpXHwCaQtsk9zX066i0kweXkEe0ZYt71ilAqTZU93ur2w5oFQtjYu5wZnVBqqp86/Zt
TRPiZmyb9SOvIZuZSg/LSJwuNTXaqoZDqw15bqZgI4nEZZwWmg81vfuFU5B5xH1zx+fE
lVCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to
:references:mime-version:content-transfer-encoding;
bh=5KxF/gRFMralAx7IdGwLVe2/maflMLJ7+wYI7rX+bTU=;
b=Y6+0L4cwamJL3mKFwjqIlXkWnYRiTEGlbA3HJTbDPI6wD9HGzo94PjbzecHgU0wjyb
qjVWhq6HDHMrwFZLOlpnYm8TxHshLucOyMxwFnf1tLZn0e/0GQ+WIheyls0eUy9JGBod
yWPBr5n+hzfepRoHrp+FNfXzADEjny2LcFH47QD/fp4E2ox5VCwxF1jesr6xioTF2z7D
V8L5sFTR65vNVeMlUEtVPbZ19gjziHjMKZ/dOukzP26cfwBn+1zRrRpZDdOccvCR+/wS
csCdcAxjSeBHqQCNCvOrGTf1vdgz9Dfkp8GWp0CpGp2ll1P+i6sE1Gj3//lLuxJGIEAD
U/gg==
X-Gm-Message-State: AJIora9jvqPtd1bcAoY8+FlEi4al4n7Bp/AKi4F+I0owOba4vVau90MX
Aw/Yqb32Ejv2XFkwEqj13ImcUg==
X-Google-Smtp-Source: AGRyM1vDLGJJhU6OO/wTaycoUub8j6zSzb0UYCHuugpZVQT8elMb6nviwq1iiv6oSTRF7jV669A08w==
X-Received: by 2002:a17:902:d4c3:b0:16a:7696:971a with SMTP id
o3-20020a170902d4c300b0016a7696971amr46787511plg.142.1657120982571;
Wed, 06 Jul 2022 08:23:02 -0700 (PDT)
Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199])
by smtp.gmail.com with ESMTPSA id
c6-20020a63ef46000000b0040ca00cd318sm24061859pgk.40.2022.07.06.08.23.01
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Wed, 06 Jul 2022 08:23:02 -0700 (PDT)
Date: Wed, 6 Jul 2022 08:22:56 -0700
From: Stephen Hemminger <stephen@networkplumber.org>
To: venkatesh bs <venki.bsv@gmail.com>
Cc: dev@dpdk.org
Subject: Re: clarification on RTE_HASH_EXTRA_FLAGS_RW_CONCURRENCY_LF flag
Message-ID: <20220706082256.562c1b69@hermes.local>
In-Reply-To: <CAM3UhOh04CFR16puEnQ0YVso8ucvanpJBsyW+-KxV0yJewXovg@mail.gmail.com>
References: <CAM3UhOgDzys5nAYWSmr7LqcV8EFufGNO35rfCaVtQdt1PfHWqg@mail.gmail.com>
<CAM3UhOh04CFR16puEnQ0YVso8ucvanpJBsyW+-KxV0yJewXovg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
On Wed, 6 Jul 2022 19:07:54 +0530
venkatesh bs <venki.bsv@gmail.com> wrote:
> Hi All,
>
> In multithreaded/Multicore environment can we use
> RTE_HASH_EXTRA_FLAGS_RW_CONCURRENCY_LF
> independently,
> or this flag should always be used with
> RTE_HASH_EXTRA_FLAGS_MULTI_WRITER_ADD.
>
> We are trying to create and access the hash table with
> RTE_HASH_EXTRA_FLAGS_RW_CONCURRENCY_LF
> only.
> We are getting crashes in multi core environments , we debugged nothing
> wrong in the application , everything looks good.
>
> We call rte_hash_del_key() first and from the returned position we are
> calling rte_hash_free_key_with_position().
>
> Please let me know if we missed something.
>
> Thanks,
> Venkatesh.
Repeating same question doesn't get answer faster.
Read the code, it is fairly straightforward.
The multi-writer add means that writers take a lock.
If doing lock free support then:
1. It is up to your application to use a single writer and/or
wrap writer calls in a lock.
2. You need to use RCU mechanism to guarantee that no reader
will access a deleted entry. Something like:
rte_hash_del_key()
synchronize_rcu()
rte_hash_free_key_with_position()
You can use either the DPDK RCU library or the userspace RCU library.
Read that documentation, RCU is non-trivial change.