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 D9369436C8;
Mon, 11 Dec 2023 19:53:28 +0100 (CET)
Received: from mails.dpdk.org (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id 963CA410F6;
Mon, 11 Dec 2023 19:53:28 +0100 (CET)
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
by mails.dpdk.org (Postfix) with ESMTP id ED242402EF
for <dev@dpdk.org>; Mon, 11 Dec 2023 19:53:27 +0100 (CET)
Received: by linux.microsoft.com (Postfix, from userid 1086)
id 2149920B74C0; Mon, 11 Dec 2023 10:53:27 -0800 (PST)
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 2149920B74C0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
s=default; t=1702320807;
bh=Q2HODCVEBDhfr5At/xwlqOc/YRA2NIFHtqoBtXRNTRw=;
h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
b=F4fvDo13somf4TmWwvr8O1ZfksOhjlezVkoUP1VTnUgA+HFl66O2hBN4EGOUY+s/c
VlReLnlWtqyJ4EhgWMwcCF7M28pK172fh+r0iKuBdC2MviVomCh6TMZNOngsujfla1
cIz7v12Ccpg10tkP2uqTBdkJg4247V3zyC+budsA=
Date: Mon, 11 Dec 2023 10:53:27 -0800
From: Tyler Retzlaff <roretzla@linux.microsoft.com>
To: Jie Hai <haijie1@huawei.com>
Cc: dev@dpdk.org, Morten =?iso-8859-1?Q?Br=F8rup?= <mb@smartsharesystems.com>,
Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>,
lihuisong@huawei.com, fengchengwen@huawei.com, liudongdong3@huawei.com
Subject: Re: [PATCH 1/2] eal: fix constraints on stdatomic API
Message-ID: <20231211185327.GA16826@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
References: <20231211073904.811243-1-haijie1@huawei.com>
<20231211073904.811243-2-haijie1@huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20231211073904.811243-2-haijie1@huawei.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
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 Mon, Dec 11, 2023 at 03:39:03PM +0800, Jie Hai wrote:
> The first parameter of rte_atomic_exchange_explicit() must be a
> pointer to _Atomic type. If run command "meson setup --werror
> -Denable_stdatomic=true build && ninja -C build", error will occur.
> Thia patch fixes it.
>
> Fixes: 1ec6a845b5cb ("eal: use stdatomic API in public headers")
> Cc: stable@dpdk.org
>
> Signed-off-by: Jie Hai <haijie1@huawei.com>
> ---
> app/test/test_atomic.c | 6 +++---
> lib/eal/include/generic/rte_atomic.h | 12 ++++++------
> 2 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/app/test/test_atomic.c b/app/test/test_atomic.c
> index db07159e81ab..c3cb3ae0ea57 100644
> --- a/app/test/test_atomic.c
> +++ b/app/test/test_atomic.c
> @@ -347,9 +347,9 @@ typedef union {
> const uint8_t CRC8_POLY = 0x91;
> uint8_t crc8_table[256];
>
> -volatile uint16_t token16;
> -volatile uint32_t token32;
> -volatile uint64_t token64;
> +volatile RTE_ATOMIC(uint16_t) token16;
> +volatile RTE_ATOMIC(uint32_t) token32;
> +volatile RTE_ATOMIC(uint64_t) token64;
subject to my comment below, volatile qualification can be removed.
>
> static void
> build_crc8_table(void)
> diff --git a/lib/eal/include/generic/rte_atomic.h b/lib/eal/include/generic/rte_atomic.h
> index 0e639dad76a4..38c3b41f9c68 100644
> --- a/lib/eal/include/generic/rte_atomic.h
> +++ b/lib/eal/include/generic/rte_atomic.h
> @@ -207,11 +207,11 @@ rte_atomic16_cmpset(volatile uint16_t *dst, uint16_t exp, uint16_t src)
> * The original value at that location
> */
> static inline uint16_t
> -rte_atomic16_exchange(volatile uint16_t *dst, uint16_t val);
> +rte_atomic16_exchange(volatile RTE_ATOMIC(uint16_t) *dst, uint16_t val);
the existing rte_atomicNN (the old non-standard ones) are deprecated and will
be eventually removed so there isn't a lot of value in churning their
signatures to wrap the rte_stdatomic macros.
the right thing to do here to just change the calling code to use the generic
rte_stdatomic macros directly so we can eventually remove
rte_atomicNN_xxx.
ty