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 D35294300F; Tue, 8 Aug 2023 21:19:51 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A860042B71; Tue, 8 Aug 2023 21:19:51 +0200 (CEST) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id EAA5241148; Tue, 8 Aug 2023 21:19:49 +0200 (CEST) Received: by linux.microsoft.com (Postfix, from userid 1086) id 2CCFA20FC0C7; Tue, 8 Aug 2023 12:19:49 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 2CCFA20FC0C7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1691522389; bh=tYLnHv+ijrfcnRYGdF3Gvvb4bD7uX5kkhzEbxbcVY5k=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ossOJ2S/i61v+yt/N9Zvz23VBMXsOC2zE2bPrQ3EreCOLrXnEWPV9fwwQ3NMVdr7n n0cDl3ccLiuGzIU01MxqcnRrVc18mZ3r1UyBAoYcdAJ7FhnIGk0LOOxTSwBSysf4jA fuCKpZiDdrtFPZJvSWvUXeeeWLAzfCHvTaVltz1Y= Date: Tue, 8 Aug 2023 12:19:49 -0700 From: Tyler Retzlaff To: Bruce Richardson Cc: dev@dpdk.org, techboard@dpdk.org, thomas@monjalon.net, david.marchand@redhat.com, Honnappa.Nagarahalli@arm.com, mb@smartsharesystems.com Subject: Re: C11 atomics adoption blocked Message-ID: <20230808191949.GB18244@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <20230808175303.GA11006@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 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=c++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: > > ‘_Atomic’ 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=60932 > > > > 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. > > > > 4. We re-evaluate adoption of C11 atomics and corresponding requirement of > > -std=c++23 compliant compiler at the next long term ABI promise release. > > > > Q: Why not define macros that look like the standard and expand those > > names to builtins? > > A: Because introducing the names is a violation of the C standard, we > > can't / shouldn't define atomic_xxx names in the applications namespace > > as we are not ``the implementation''. > > A: Because the builtins offer a subset of stdatomic.h capability they > > can only operate on pointer and integer types. If we presented the > > stdatomic.h names there might be some confusion attempting to perform > > atomic operations on e.g. _Atomic specified struct would fail but only > > on BSD/Linux builds (with the proposed solution). > > > > Out of interest, rather than splitting on Windows vs *nix OS for the > atomics, what would it look like if we split behaviour based on C vs C++ > use? Would such a thing work? Unfortunately no. The reason is binary packages and we don't know which toolchain consumes them. For example. Assume we build libeal-dev package with gcc. We'll end up with headers that contain the _Atomic specifier. Now we write an application and build it with * gcc, sure works fine it knows about _Atomic * clang, same as gcc * clang++, works but is implementation detail that it works (it isn't standard) * g++, does not work So the LCD is build package without _Atomic i.e. what we already have today on BSD/Linux. > Also, just wondering about the scope of the changes here. How many header > files are affected where we publicly expose atomics? So what is impacted is roughly what is in my v4 series that raised my attention to the issue. https://patchwork.dpdk.org/project/dpdk/list/?series=29086 We really can't solve the problem by not talking about atomics in the API because of the performance requirements of the APIs in question. e.g. It is stuff like rte_rwlock, rte_spinlock, rte_pause all stuff that can't have additional levels of indirection because of the overhead involved. > > Thanks, > /Bruce