From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id EB53F43062; Mon, 14 Aug 2023 15:46:27 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 819F640A7F; Mon, 14 Aug 2023 15:46:27 +0200 (CEST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by mails.dpdk.org (Postfix) with ESMTP id 933474021F; Mon, 14 Aug 2023 15:46:25 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 11FCA5C0161; Mon, 14 Aug 2023 09:46:23 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Mon, 14 Aug 2023 09:46:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm1; t= 1692020783; x=1692107183; bh=q/Ill8JnRwVE5qpKYy5lBpKg0X8U5dbjmGJ lh5MwwJE=; b=CyWZHiDepi8okKU1jKYGWLe2OX36Zz00C5Um+NBCAiR6FAP0XUA PvNcneKi5n1DrDGReZARpUOKoWF4KvXVYjtTeWgBU8LbIRYEMZmmQ6dzahwadJxA I8wZQHEG0hmGyBaQzlKzR1iiT63cDl01XiLUMZb5gFVSAi5UL9a9ot20BT46+DfM 0fsCYQmvYahfuo69OaDxxIhKaZHiLBcZj4J5+xOeSP95VmMtl889Gv4BtI8/6HsH Oly9XX/jmgO0Wp5CyM0op/C9D0Jhr1gM3dCy1fJlq9b5UdlDCnuualM9hE2wmhwC +z9mQhecpt5Xx7pJHxsfiKKvsLH4sF4cmIA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1692020783; x=1692107183; bh=q/Ill8JnRwVE5qpKYy5lBpKg0X8U5dbjmGJ lh5MwwJE=; b=UhhNe8jA5DvNgqMOfvEqS1ExTpXZkZy0wQZ9sxiUlKO64HI650e Yw9NT4dnffT9LFgtbUT8U50awWJ+XG84UCCnFI9jh7G5P2hdJucDE3nVo3k1FdWZ eoi8PboqegcStTha6ziFOLnWQxV/zPmHFFT6lbOx+DtHzBAWZ3+3VB/bPGFOpIH7 UD74zigJUaw04FkeRIGywiYOkymF4BehbdUFKGudTh9dbBULSFW+3+hT2JNFOfXe Uu9CcfOtZXrP+Ja1XnvvQD0M+5e1RAIT1pwZbWWE3bmsu+FW0j5K7u1LRVEUVHkR ybmpgu1jOPLLClbiRDKLbYIlkvnovu/7Q3w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedruddtgedgieekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthhqredttddtjeenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedtlefgjeevvedutefhudegteeffeekueefhfeifffhveetjeek veejkeevheegteenucffohhmrghinhepghhnuhdrohhrghenucevlhhushhtvghrufhiii gvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhn rdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 14 Aug 2023 09:46:21 -0400 (EDT) From: Thomas Monjalon To: Tyler Retzlaff , Morten =?ISO-8859-1?Q?Br=F8rup?= Cc: Bruce Richardson , dev@dpdk.org, techboard@dpdk.org, david.marchand@redhat.com, Honnappa.Nagarahalli@arm.com Subject: Re: C11 atomics adoption blocked Date: Mon, 14 Aug 2023 15:46:18 +0200 Message-ID: <3629940.iIbC2pHGDl@thomas> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D87AD8@smartserver.smartshare.dk> References: <20230808175303.GA11006@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <20230808204944.GA3335@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <98CBD80474FA8B44BF855DF32C47DC35D87AD8@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org mercredi 9 ao=C3=BBt 2023, Morten Br=C3=B8rup: > > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com] > > Sent: Tuesday, 8 August 2023 22.50 > >=20 > > On Tue, Aug 08, 2023 at 10:22:09PM +0200, Morten Br=C3=B8rup wrote: > > > > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com] > > > > Sent: Tuesday, 8 August 2023 21.20 > > > > > > > > On Tue, Aug 08, 2023 at 07:23:41PM +0100, Bruce Richardson wrote: > > > > > On Tue, Aug 08, 2023 at 10:53:03AM -0700, Tyler Retzlaff wrote: > > > > > > Hi folks, > > > > > > > > > > > > Moving this discussion to the dev mailing list for broader > > comment. > > > > > > > > > > > > Unfortunately, we've hit a roadblock with integrating C11 > > atomics > > > > > > for DPDK. The main issue is that GNU C++ prior to -std=3Dc++23 > > > > explicitly > > > > > > cannot be integrated with C11 stdatomic.h. Basically, you can't > > > > include > > > > > > the header and you can't use `_Atomic' type specifier to declare > > > > atomic > > > > > > types. This is not a problem with LLVM or MSVC as they both > > allow > > > > > > integration with C11 stdatomic.h, but going forward with C11 > > atomics > > > > > > would break using DPDK in C++ programs when building with GNU > > g++. > > > > > > > > > > > > Essentially you cannot compile the following with g++. > > > > > > > > > > > > #include > > > > > > > > > > > > int main(int argc, char *argv[]) { return 0; } > > > > > > > > > > > > In file included from atomic.cpp:1: > > > > > > /usr/lib/gcc/x86_64-pc-cygwin/11/include/stdatomic.h:40:9: > > error: > > > > > > =E2=80=98_Atomic=E2=80=99 does not name a type > > > > > > 40 | typedef _Atomic _Bool atomic_bool; > > > > > > > > > > > > ... more errors of same ... > > > > > > > > > > > > It's also acknowledged as something known and won't fix by GNU > > g++ > > > > > > maintainers. > > > > > > > > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D60932 > > > > > > > > > > > > Given the timeframe I would like to propose the minimally > > invasive, > > > > > > lowest risk solution as follows. > > > > > > > > > > > > 1. Adopt stdatomic.h for all Windows targets, leave all > > Linux/BSD > > > > targets > > > > > > using GCC builtin C++11 memory model atomics. > > > > > > 2. Introduce a macro that allows _Atomic type specifier to be > > > > applied to > > > > > > function parameter, structure field types and variable > > > > declarations. > > > > > > > > > > > > * The macro would expand empty for Linux/BSD targets. > > > > > > * The macro would expand to C11 _Atomic keyword for Windows > > > > targets. > > > > > > > > > > > > 3. Introduce basic macro that allows __atomic_xxx for > > normalized > > > > use > > > > > > internal to DPDK. > > > > > > > > > > > > * The macro would not be defined for Linux/BSD targets. > > > > > > * The macro would expand __atomic_xxx to corresponding > > > > stdatomic.h > > > > > > atomic_xxx operations for Windows targets. > > > > > > > > > > > > Regarding naming of these macros (suggested in 2. and 3.), they should > > probably bear the rte_ prefix instead of overlapping existing names, so > > applications can also use them directly. > > > > > > E.g.: > > > #define rte_atomic for _Atomic or nothing, > > > #define rte_atomic_fetch_add() for atomic_fetch_add() or > > __atomic_fetch_add(), and > > > #define RTE_MEMORY_ORDER_SEQ_CST for memory_order_seq_cst or > > __ATOMIC_SEQ_CST. > > > > > > Maybe that is what you meant already. I'm not sure of the scope and > > details of your suggestion here. > >=20 > > I'm shy to do anything in the rte_ namespace because I don't want to > > formalize it as an API. > >=20 > > I was envisioning the following. > >=20 > > Internally DPDK code just uses __atomic_fetch_add directly, the macros > > are provided for Windows targets to expand to __atomic_fetch_add. > >=20 > > Externally DPDK applications that don't care about being portable may > > use __atomic_fetch_add (BSD/Linux) or atomic_fetch_add (Windows) > > directly. > >=20 > > Externally DPDK applications that care to be portable may do what is > > done Internally and <> the __atomic_fetch_add directly. By > > including say rte_stdatomic.h indirectly (Windows) gets the macros > > expanded to atomic_fetch_add and for BSD/Linux it's a noop include. > >=20 > > Basically I'm placing a little ugly into Windows built code and in trade > > we don't end up with a bunch of rte_ APIs that were strongly objected to > > previously. > >=20 > > It's a compromise. >=20 > OK, we probably need to offer a public header file to wrap the atomics, u= sing either names prefixed with rte_ or names similar to the gcc builtin at= omics. >=20 > I guess the objections were based on the assumption that we were switchin= g to C11 atomics with DPDK 23.11, so the rte_ prefixed atomic APIs would be= very short lived (DPDK 23.07 to 23.11 only). But with this new information= about GNU C++ incompatibility, that seems not to be the case, so the namin= g discussion can be reopened. >=20 > If we don't introduce such a wrapper header, all portable code needs to s= urround the use of atomics with #ifdef USE_STDATOMIC_H. >=20 > BTW: Can the compilers that understand both builtin atomics and C11 stdat= omics.h handle code with #define __atomic_fetch_add atomic_fetch_add and #d= efine __ATOMIC_SEQ_CST memory_order_seq_cst? If not, then we need to use rt= e_ prefixed atomics. >=20 > And what about C++ atomics... Do we want (or need?) a third variant using= C++ atomics, e.g. "atomic x;" instead of "_Atomic int x;"? (I hope no= t!) For reference, the "atomic_int" type is "_Atomic int" in C, but "std::a= tomic" in C++. >=20 > C++23 provides the C11 compatibility macro "_Atomic(T)", which means "_At= omic T" in C and "std::atomic" in C++. Perhaps we can somewhat rely on t= his, and update our coding standards to require using e.g. "_Atomic(int)" f= or atomic types, and disallow using "_Atomic int". You mean the syntax _Atomic(T) is working well in both C and C++?