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 6191041C30; Tue, 7 Feb 2023 16:17:01 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5020F42B8E; Tue, 7 Feb 2023 16:17:01 +0100 (CET) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id 305CA40F18 for ; Tue, 7 Feb 2023 16:17:00 +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: Tue, 7 Feb 2023 16:16:58 +0100 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D8770C@smartserver.smartshare.dk> In-Reply-To: <20230203204912.GA4631@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] eal: introduce atomics abstraction Thread-Index: Adk4EPx3DbIrZ/o5TLS5KK3mPTLqfQC8yiHw 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> <98CBD80474FA8B44BF855DF32C47DC35D876EE@smartserver.smartshare.dk> <20230202190023.GA32597@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <20230203204912.GA4631@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Tyler Retzlaff" , "Bruce Richardson" Cc: "Honnappa Nagarahalli" , , , , , , , "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: Friday, 3 February 2023 21.49 >=20 > On Fri, Feb 03, 2023 at 12:19:13PM +0000, Bruce Richardson wrote: > > On Thu, Feb 02, 2023 at 11:00:23AM -0800, Tyler Retzlaff wrote: > > > On Thu, Feb 02, 2023 at 09:43:58AM +0100, Morten Br=F8rup wrote: > > > > > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com] > > > > > Sent: Wednesday, 1 February 2023 22.41 > > > > > > > > > > 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. > > > > > > > > > > i agree that whatever atomics APIs we advocate for should = align > with > > > > > the > > > > > standard C atomics for the reasons you state including implied > > > > > semantics. > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > 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. > > > > > > > > > > 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 > > > > > > > > > > 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. > > > > > > I think it's reasonable to assume that we are talking years here. > > > > > > We've had a few discussions about minimum C standard. I think my > first > > > mailing list exchanges about C99 was almost 2 years ago. Given = that > we > > > still aren't on C99 now (though i know Bruce has a series up) > indicates > > > that progression to C11 isn't going to happen any time soon and > even if > > > it was the baseline we still can't just use it (reasons described > > > later). > > > > > > Also, i'll point out that we seem to have accepted moving to C99 > with > > > one of the holdback compilers technically being non-conformant but > it > > > isn't blocking us because it provides the subset of C99 features > without > > > being conforming that we happen to be using. > > > > > What compiler is this? As far as I know, all our currently support > > compilers claim to support C99 fully. All should support C11 also, > > except for GCC 4.8 on RHEL/CentOS 7. Once we drop support for Centos > 7, I > > think we can require at minimum a c11 compiler for building DPDK > itself. > > I'm still a little uncertain about requiring that users build their > own > > code with -std=3Dc11, though. >=20 > perhaps i'm mistaken but it was my understanding that the gcc version > on > RHEL 7 did not fully conform to C99? maybe i read C99 when it was > actually > C11. RHEL does supports C99, it's C11 that it doesn't support [1]. [1]: = http://inbox.dpdk.org/dev/98CBD80474FA8B44BF855DF32C47DC35D8762F@smartser= ver.smartshare.dk/ >=20 > regardless, even if every supported compiler for dpdk was C11 > conformant > including stdatomics which are optional we can't just move from > intrinsic/builtins to standard C atomics (because of the compatibility > and performance issues mentioned previously). For example, with C11, you can make structures atomic. And an atomic = instance of a type can have a different size than the non-atomic type. If do we make a shim, it will have some limitations compared to C11 = atomics, e.g. it cannot handle atomic structures. Either we accept these limitations of the shim, or we use our own = namespace. If we accept the limitations, we risk that someone with a C11 = build environment uses them anyway, and it will not work in non-C11 = build environments. So a shim is not a rose without thorns. >=20 > so just re-orienting this discussion, the purpose of this abstraction > is > to allow the optional use of standard C atomics when a conformant > compiler > is available and satisfactory code is generated for the desired = target. I think it is more important getting this feature into DPDK than using = the C11 stdatomic.h API for atomics in DPDK. I don't feel strongly about this API, and will accept either the = proposed patch series (with the C11-like API, but rte_ prefixed = namespace), or a C11 stdatomic.h API shim.