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 7D9C141BAA; Thu, 2 Feb 2023 09:44:09 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 686DD42D2C; Thu, 2 Feb 2023 09:44:09 +0100 (CET) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id 25B1642D31 for ; Thu, 2 Feb 2023 09:44:07 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PATCH] eal: introduce atomics abstraction Date: Thu, 2 Feb 2023 09:43:58 +0100 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D876EE@smartserver.smartshare.dk> In-Reply-To: <20230201214111.GA30564@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] eal: introduce atomics abstraction Thread-Index: Adk2hev7bWKRcZJJTdmFZ/GvIynJTQAWRzoA References: <1673558785-24992-1-git-send-email-roretzla@linux.microsoft.com> <1673558785-24992-2-git-send-email-roretzla@linux.microsoft.com> <1844463.CQOukoFCf9@thomas> <20230201214111.GA30564@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Tyler Retzlaff" , "Honnappa Nagarahalli" Cc: , , , , , , , "nd" 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 > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com] > Sent: Wednesday, 1 February 2023 22.41 >=20 > On Wed, Feb 01, 2023 at 01:07:59AM +0000, Honnappa Nagarahalli wrote: > > > > > From: Thomas Monjalon > > > Sent: Tuesday, January 31, 2023 4:42 PM > > > > > > Honnappa, please could you give your view on the future of atomics > in DPDK? > > Thanks Thomas, apologies it has taken me a while to get to this > discussion. > > > > IMO, we do not need DPDK's own abstractions. APIs from stdatomic.h > (stdatomics as is called here) already serve the purpose. These APIs > are well understood and documented. >=20 > i agree that whatever atomics APIs we advocate for should align with > the > standard C atomics for the reasons you state including implied > semantics. >=20 > > > > For environments where stdatomics are not supported, we could have a > stdatomic.h in DPDK implementing the same APIs (we have to support = only > _explicit APIs). This allows the code to use stdatomics APIs and when > we move to minimum supported standard C11, we just need to get rid of > the file in DPDK repo. Perhaps we can use something already existing, such as this: https://android.googlesource.com/platform/bionic/+/lollipop-release/libc/= include/stdatomic.h >=20 > my concern with this is that if we provide a stdatomic.h or introduce > names > from stdatomic.h it's a violation of the C standard. >=20 > references: > * ISO/IEC 9899:2011 sections 7.1.2, 7.1.3. > * GNU libc manual > https://www.gnu.org/software/libc/manual/html_node/Reserved- > Names.html >=20 > in effect the header, the names and in some instances namespaces > introduced > are reserved by the implementation. there are several reasons in the > GNU libc > manual that explain the justification for these reservations and if > if we think about ODR and ABI compatibility we can conceive of others. I we are going to move to C11 soon, I consider the shim interim, and am = inclined to ignore these warning factors. If we are not moving to C11 soon, I would consider these disadvantages = more seriously. >=20 > i'll also remark that the inter-mingling of names from the POSIX > standard implicitly exposed as a part of the EAL public API has been > problematic for portability. This is a very important remark, which should be considered carefully! = Tyler has firsthand experience with DPDK portability. If he thinks = porting to Windows is going to be a headache if we expose the = stdatomic.h API, we must listen! So, what is your gut feeling here, = Tyler? >=20 > let's discuss this from here. if there's still overwhelming desire to > go > this route then we'll just do our best. >=20 > ty I have a preference for exposing the stdatomic.h API. Tyler listed the = disadvantages above. (I also have a preference for moving to C11 soon.) Exposing a 1:1 similar API with RTE prefixes would also be acceptable = for me. The disadvantage is that the names are different than the C11 = names, which might lead to some confusion. And from an ABI stability = perspective, such an important API should not be marked experimental. = This means that years will pass before we can get rid of it again, due = to ABI stability policies. -Morten