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 B58B441C8A; Mon, 13 Feb 2023 16:29:10 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id AFA2C42D20; Mon, 13 Feb 2023 16:28:57 +0100 (CET) Received: from mail-yw1-f173.google.com (mail-yw1-f173.google.com [209.85.128.173]) by mails.dpdk.org (Postfix) with ESMTP id 2F48342D0B; Mon, 13 Feb 2023 16:28:53 +0100 (CET) Received: by mail-yw1-f173.google.com with SMTP id 00721157ae682-52ee632329dso93839937b3.6; Mon, 13 Feb 2023 07:28:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=/26z3Fagdx6siUGXRtl7LnY2qvacWWYNgWEowz78A1o=; b=h+eaI+rPaFEvdwMTtd/QRV5V9WFiKMAgbI/JK8pBqTKfhQJUaHpvQuTWCoq0rYrlIx GihMOHI92n9DFgrEbMAIBo80lrnqtXJpMjWT5xrSEhZaBs4I0AjRjcGNw0lDmD+qRzZB CzyOc1sRlxVt3N92JEg/84MDMhVU6dQqIz7s/LhVEAtZrXgfPUZo73hGUCRAOHhzwO4g 2N+QR4iHbCrsp51+a2vhen6Y5SLVLqCv3Ch1HSewMj2e5OwKdBq18kqy1eLHil3/Vyd3 o/bKkDx1ywpIwi6mBvDWOmfDBEezey4UOli+Nn4Xhox7mObuoyTe7ynybWkZUZW3cAtS 2uKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/26z3Fagdx6siUGXRtl7LnY2qvacWWYNgWEowz78A1o=; b=TaNGTsTZUKhvJq+Zf7KuwlfO0bFJyazY0/aRwLlPUx9q62SMlXd8/P44vn9TkVQhM6 BvDJut5n/fby8suwF3d4LgMAptGs2ztRx9EWRY6024oBR5j6qZf+CbsrQ3aU1adCa2ED BOI0ndy/g/rSWcIgJGPmOLg+9UtBZ7DJ2+S0/GJIwhqcbMaUVdZxKunnuhxC++M0oYtr qsZUZzjqqKveaC4f67+0BezlMz+s/rl5jFQwa1LgpVzBnUwA/Hsh65hXUo0t5A9kd2I9 Ej8vqMeQQYb1XU+Rsec/DLADv82jsxwpR6saGg+TazHJ4W5Ox4f6kSPJogJWVstgynWX 18cg== X-Gm-Message-State: AO0yUKWZbVc9yAngY3HjFDRmnp8bStbFGMUhVG8osZ17IuvToBkhV0eB 1iiHvmqQFOjvp9uEnwEcZKPU49Yq0qRx4rzJe+g= X-Google-Smtp-Source: AK7set8kkLtLJ8uFhBOLTL7cXGm/Q+2g2CJUTg/v2WHVPTEZHAlgBm603CohsunAkMJvich2RzCjYCGg5euGmpl21YY= X-Received: by 2002:a81:6a0b:0:b0:52e:ec16:6f19 with SMTP id f11-20020a816a0b000000b0052eec166f19mr1189425ywc.33.1676302132459; Mon, 13 Feb 2023 07:28:52 -0800 (PST) MIME-Version: 1.0 References: <1844463.CQOukoFCf9@thomas> <20230201214111.GA30564@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <20230208012040.GA22219@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <98CBD80474FA8B44BF855DF32C47DC35D8770D@smartserver.smartshare.dk> <20230208163521.GB5117@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <20230209173017.GA21854@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <20230210203013.GB25500@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> In-Reply-To: From: Ben Magistro Date: Mon, 13 Feb 2023 10:28:40 -0500 Message-ID: Subject: Re: [PATCH] eal: introduce atomics abstraction To: Honnappa Nagarahalli Cc: Tyler Retzlaff , =?UTF-8?Q?Morten_Br=C3=B8rup?= , "thomas@monjalon.net" , "dev@dpdk.org" , "bruce.richardson@intel.com" , "david.marchand@redhat.com" , "jerinj@marvell.com" , "konstantin.ananyev@huawei.com" , "ferruh.yigit@amd.com" , nd , "techboard@dpdk.org" Content-Type: multipart/alternative; boundary="000000000000243f6e05f49681e1" 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 --000000000000243f6e05f49681e1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There is a thread discussing a change to the standard [1] but I have not seen anything explicit yet about moving to C11. I am personally in favor of making the jump to C11 now as part of the 23.x branch and provided my thoughts in the linked thread (what other projects using DPDK have as minimum compiler requirements, CentOS 7 EOL dates). Is the long term plan to backport this change set to the existing LTS release or is this meant to be something introduced for use in 23.x and going forward? I think I was (probably naively) assuming this would be a new feature in the 23.x going forward only. [1] http://mails.dpdk.org/archives/dev/2023-February/262188.html On Mon, Feb 13, 2023 at 12:05 AM Honnappa Nagarahalli < Honnappa.Nagarahalli@arm.com> wrote: > Hi Tyler, > Few more comments inline. Let us continue to make progress, I wil= l > add this topic for Techboard discussion for 22nd Feb. > > > -----Original Message----- > > From: Tyler Retzlaff > > Sent: Friday, February 10, 2023 2:30 PM > > To: Honnappa Nagarahalli > > Cc: Morten Br=C3=B8rup ; thomas@monjalon.net; > > dev@dpdk.org; bruce.richardson@intel.com; david.marchand@redhat.com; > > jerinj@marvell.com; konstantin.ananyev@huawei.com; > > ferruh.yigit@amd.com; nd ; techboard@dpdk.org > > Subject: Re: [PATCH] eal: introduce atomics abstraction > > > > On Fri, Feb 10, 2023 at 05:30:00AM +0000, Honnappa Nagarahalli wrote: > > > > > > > > > > On Thu, Feb 09, 2023 at 12:16:38AM +0000, Honnappa Nagarahalli wrot= e: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > > > 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/Rese= r > > > > > > > > > > ved- > > > > > > > > > > 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 > > > > > > > > > Wouldn't this apply only after the particular APIs were > > introduced? > > > > > > > > i.e. it should not apply if the compiler does not support > stdatomics. > > > > > > > > > > > > > > > > yeah, i agree they're being a bit wishy washy in the > > > > > > > > wording, but i'm not convinced glibc folks are documenting > > > > > > > > this as permissive guidance against. > > > > > > > > > > > > > > > > > > > > > > > > > > > manual that explain the justification for these > > > > > > > > > > reservations and if > > > > > > > > if we think > > > > > > > > > > about ODR and ABI compatibility we can conceive of > others. > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > These should be exposed as EAL APIs only when compiled > > > > > > > > > with a > > > > > > > > compiler that does not support stdatomics. > > > > > > > > > > > > > > > > you don't necessarily compile dpdk, the application or its > > > > > > > > other dynamically linked dependencies with the same compile= r > > > > > > > > at the same time. > > > > > > > > i.e. basically the model of any dpdk-dev package on any > > > > > > > > linux distribution. > > > > > > > > > > > > > > > > if dpdk is built without real stdatomic types but the > > > > > > > > application has to interoperate with a different kit or > > > > > > > > library that does they would be forced to dance around dpdk > > > > > > > > with their own version of a shim to hide our faked up > stdatomics. > > > > > > > > > > > > > > > > > > > > > > So basically, if we want a binary DPDK distribution to be > > > > > > > compatible with a > > > > > > separate application build environment, they both have to > > > > > > implement atomics the same way, i.e. agree on the ABI for > atomics. > > > > > > > > > > > > > > Summing up, this leaves us with only two realistic options: > > > > > > > > > > > > > > 1. Go all in on C11 stdatomics, also requiring the applicatio= n > > > > > > > build > > > > > > environment to support C11 stdatomics. > > > > > > > 2. Provide our own DPDK atomics library. > > > > > > > > > > > > > > (As mentioned by Tyler, the third option - using C11 > > > > > > > stdatomics inside DPDK, and requiring a build environment > > > > > > > without C11 stdatomics to implement a shim - is not > > > > > > > realistic!) > > > > > > > > > > > > > > I strongly want atomics to be available for use across inline > > > > > > > and compiled > > > > > > code; i.e. it must be possible for both compiled DPDK functions > > > > > > and inline functions to perform atomic transactions on the same > > atomic variable. > > > > > > > > > > > > i consider it a mandatory requirement. i don't see practically > > > > > > how we could withdraw existing use and even if we had clean way > > > > > > i don't see why we would want to. so this item is defintely > > > > > > settled if you were > > > > concerned. > > > > > I think I agree here. > > > > > > > > > > > > > > > > > > > > > > > > > So either we upgrade the DPDK build requirements to support > > > > > > > C11 (including > > > > > > the optional stdatomics), or we provide our own DPDK atomics. > > > > > > > > > > > > i think the issue of requiring a toolchain conformant to a > > > > > > specific standard is a separate matter because any adoption of > > > > > > C11 standard atomics is a potential abi break from the current > use of > > intrinsics. > > > > > I am not sure why you are calling it as ABI break. Referring to > > > > > [1], I just see > > > > wrappers around intrinsics (though [2] does not use the intrinsics)= . > > > > > > > > > > [1] > > > > > https://github.com/gcc-mirror/gcc/blob/master/gcc/ginclude/stdato= m > > > > > ic.h > > > > > [2] > > > > > https://github.com/llvm-mirror/clang/blob/master/lib/Headers/stda= t > > > > > omic > > > > > .h > > > > > > > > it's a potential abi break because atomic types are not the same > > > > types as their corresponding integer types etc.. (or at least are > > > > not guaranteed to be by all implementations of c as an abstract > language). > > > > > > > > ISO/IEC 9899:2011 > > > > > > > > 6.2.5 (27) > > > > Further, there is the _Atomic qualifier. The presence of the > _Atomic > > > > qualifier designates an atomic type. The size, representation, > and > > alignment > > > > of an atomic type need not be the same as those of the > corresponding > > > > unqualified type. > > > > > > > > 7.17.6 (3) > > > > NOTE The representation of atomic integer types need not have t= he > > same size > > > > as their corresponding regular types. They should have the same > > > > size whenever > > > > possible, as it eases effort required to port existing code. > > > > > > > > i use the term `potential abi break' with intent because for me to > > > > assert in absolute terms i would have to evaluate the implementatio= n > > > > of every current and potential future compilers atomic vs non-atomi= c > > > > types. this as i'm sure you understand is not practical, it would > > > > also defeat the purpose of moving to a standard. therefore i rely o= n > > > > the specification prescribed by the standard not the detail of a > specific > > implementation. > > > Can we say that the platforms 'supported' by DPDK today do not have > this > > problem? Any future platforms that will come to DPDK have to evaluate > this. > > > > sadly i don't think we can. i believe in an earlier post i linked a bug > filed on > > gcc that shows that clang / gcc were producing different layout than th= e > > equivalent non-atomic type. > I looked at that bug again, it is to do with structure. > > > > > > > > > > > > > > > > > > > > the abstraction (whatever namespace it resides) allows the > > > > > > existing toolchain/platform combinations to maintain > > > > > > compatibility by defaulting to current non-standard intrinsics. > > > > > How about using the intrinsics (__atomic_xxx) name space for > > abstraction? > > > > This covers the GCC and Clang compilers. > > > > i haven't investigated fully but there are usages of these intrinsics > that > > indicate there may be undesirable difference between clang and gcc > versions. > > the hint is there seems to be conditionally compiled code under __clang= __ > > when using some __atomic's. > I sent an RFC to address this [1]. I think the size specific intrinsics > are not necessary. > > [1] > http://patches.dpdk.org/project/dpdk/patch/20230211015622.408487-1-honnap= pa.nagarahalli@arm.com/ > > > > > for the purpose of this discussion clang just tries to look like gcc so > i don't > > regard them as being different compilers for the purpose of this > discussion. > > > > > > > > > > the namespace starting with `__` is also reserved for the > implementation. > > > > this is why compilers gcc/clang/msvc place name their intrinsic and > > > > builtin functions starting with __ to explicitly avoid collision > > > > with the application namespace. > > > > > Agreed. But, here we are considering '__atomic_' specifically (i.e. > > > not just '__') > > > > i don't understand the confusion __atomic is within the __ namespace > that is > > reserved. > What I mean is, we are not formulating a policy/rule to allow for any nam= e > space that starts with '__'. > > > > > let me ask this another way, what benefit do you see to trying to > overlap with > > the standard namespace? the only benefit i can see is that at some poin= t > in > > the future it avoids having to perform a mechanical change to eventuall= y > > retire the abstraction once all platform/toolchains support standard > atomics. > > i.e. basically s/rte_atomic/atomic/g > > > > is there another benefit i'm missing? > The abstraction you have proposed solves the problem for the long term. > The proposed abstraction stops us from thinking about moving to stdatomic= s. > IMO, the problem is short term. Using the __atomic_ name space does not > have any practical issues with the platforms DPDK supports (unless msvc h= as > a problem with this, more questions below). > > > > > > > > > > > > > > ISO/IEC 9899:2011 > > > > > > > > 7.1.3 (1) > > > > All identifiers that begin with an underscore and either an > uppercase > > > > letter or another underscore are always reserved for any use. > > > > > > > > ... > > > > > > > > > If there is another platform that uses the same name space for > > > > > something > > > > else, I think DPDK should not be supporting that platform. > > > > > > > > that's effectively a statement excluding windows platform and all > > > > non-gcc compilers from ever supporting dpdk. > > > Apologies, I did not understand your comment on windows platform. Do > > you mean to say a compiler for windows platform uses '__atomic_xxx' nam= e > > space to provide some other functionality (and hence it would get > excluded)? > > > > i mean dpdk can never fully be supported without msvc except for > statically > > linked builds which are niche and limit it too severely for many > consumers to > > practically use dpdk. there are also many application developers who > would > > like to integrate dpdk but can't and telling them their only choice is > to re-port > > their entire application to clang isn't feasible. > > > > i can see no technical reason why we should be excluding a major > compiler in > > broad use if it is capable of building dpdk. msvc arguably has some of > the > > most sophisticated security features in the industry and the use of tho= se > > features is mandated by many of the customers who might deploy dpdk > > applications on windows. > I did not mean DPDK should not support msvc (may be my sentence below was > misunderstood). > Does msvc provide '__atomic_xxx' intrinsics? > > > > > > Clang supports these intrinsics. I am not sure about the merit of > supporting > > other non-gcc compilers. May be a topic Techboard discussion. > > > > > > > > > > > > What problems do you see? > > > > > > > > i'm fairly certain at least one other compiler uses the __atomic > > > > namespace but > > > Do you mean __atomic namespace is used for some other purpose? > > > > > > > it would take me time to check, the most notable potential issue > > > > that comes to mind is if such an intrinsic with the same name is > > > > provided in a different implementation and has either regressive > > > > code generation or different semantics it would be bad because it i= s > > > > intrinsic you can't just hack around it with #undef __atomic to shi= m > in a > > semantically correct version. > > > I do not think we should worry about regressive code generation > problem. It > > should be fixed by that compiler. > > > Different semantics is something we need to worry about. It would be > good > > to find out more about a compiler that does this. > > > > again, this is about portability it's about potential not that we can > find an > > example. > > > > > > > > > > > > > how about this, is there another possible namespace you might > > > > suggest that conforms or doesn't conflict with the the rules define= d > > > > in ISO/IEC 9899:2011 > > > > 7.1.3 i think if there were that would satisfy all of my concerns > > > > related to namespaces. > > > > > > > > keep in mind the point of moving to a standard is to achieve > > > > portability so if we do things that will regress us back to being > > > > dependent on an implementation we haven't succeeded. that's all i'm > > trying to guarantee here. > > > Agree. We are trying to solve a problem that is temporary. I am tryin= g > to > > keep the problem scope narrow which might help us push to adopt the > > standard sooner. > > > > i do wish we could just target the standard but unless we are willing t= o > draw a > > line and say no more non std=3Dc11 and also we potentially break the ab= i we > > are talking years. i don't think it is reasonable to block progress for > years, so > > i'm offering a transitional path. it's an evolution over time that we > have to > > manage. > Apologies if I am sounding like I am blocking progress. Rest assured, we > will find a way. It is just about which solution we are going to pick. > Also, is there are any information on how long before we move to C11? > > > > > > > > > > > > > > i feel like we are really close on this discussion, if we can just > > > > iron this issue out we can probably get going on the actual changes= . > > > > > > > > thanks for the consideration. > > > > > > > > > > > > > > > > > > > > > once in place it provides an opportunity to introduce new > > > > > > toolchain/platform combinations and enables an opt-in capabilit= y > > > > > > to use stdatomics on existing toolchain/platform combinations > > > > > > subject to community discussion on how/if/when. > > > > > > > > > > > > it would be good to get more participants into the discussion s= o > > > > > > i'll cc techboard for some attention. i feel like the only area > > > > > > that isn't decided is to do or not do this in rte_ namespace. > > > > > > > > > > > > i'm strongly in favor of rte_ namespace after discussion, mainl= y > > > > > > due to to disadvantages of trying to overlap with the standard > > > > > > namespace while not providing a compatible api/abi and because > > > > > > it provides clear disambiguation of that difference in semantic= s > > > > > > and compatibility with > > > > the standard api. > > > > > > > > > > > > so far i've noted the following > > > > > > > > > > > > * we will not provide the non-explicit apis. > > > > > +1 > > > > > > > > > > > * we will make no attempt to support operate on struct/union > atomics > > > > > > with our apis. > > > > > +1 > > > > > > > > > > > * we will mirror the standard api potentially in the rte_ > namespace to > > > > > > - reference the standard api documentation. > > > > > > - assume compatible semantics (sans exceptions from first 2 > points). > > > > > > > > > > > > my vote is to remove 'potentially' from the last point above fo= r > > > > > > reasons previously discussed in postings to the mail thread. > > > > > > > > > > > > thanks all for the discussion, i'll send up a patch removing > > > > > > non-explicit apis for viewing. > > > > > > > > > > > > ty > --000000000000243f6e05f49681e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There is a thread discussing a change to the standard [1] = but I have not seen anything explicit yet about moving to C11.=C2=A0 I am p= ersonally=C2=A0in favor of making the jump to C11 now as part of the 23.x b= ranch and provided my thoughts in the linked thread (what other projects us= ing DPDK have as minimum compiler requirements, CentOS 7 EOL dates).
Is the long term plan to backport this change set to the exist= ing LTS release or is this meant to be something introduced for use in 23.x= and going forward?=C2=A0 I think I was (probably naively) assuming this wo= uld be a new feature in the 23.x going forward only.

[1]=C2=A0http://mails.dpdk.org/archives/dev/2023-February/262188.html<= /div>

On Mon, Feb 13, 2023 at 12:05 AM Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> wr= ote:
Hi Tyler, =C2=A0 =C2=A0 =C2=A0 =C2=A0 Few more comments inline. Let us continue to ma= ke progress, I will add this topic for Techboard discussion for 22nd Feb.
> -----Original Message-----
> From: Tyler Retzlaff <roretzla@linux.microsoft.com>
> Sent: Friday, February 10, 2023 2:30 PM
> To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> Cc: Morten Br=C3=B8rup <mb@smartsharesystems.com>; thomas@monjalon.net;
> dev@dpdk.org; bruce.richard= son@intel.com; david.marchand@redhat.com;
> jerinj@marvell= .com; konstantin.ananyev@huawei.com;
> ferruh.yigit= @amd.com; nd <nd@arm= .com>; techb= oard@dpdk.org
> Subject: Re: [PATCH] eal: introduce atomics abstraction
>
> On Fri, Feb 10, 2023 at 05:30:00AM +0000, Honnappa Nagarahalli wrote:<= br> > > <snip>
> >
> > > On Thu, Feb 09, 2023 at 12:16:38AM +0000, Honnappa Nagarahal= li wrote:
> > > > <snip>
> > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > For environments where st= datomics are not supported,
> > > > > > > > > > we could
> > > > > > > have a
> > > > > > > > > stdatomic.h in DPDK implementi= ng the same APIs (we have
> > > > > > > > > to support
> > > > > > > only
> > > > > > > > > _explicit APIs). This allows t= he 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.
> > > > > > > > >
> > > > > > > > > my concern with this is that i= f we provide a stdatomic.h
> > > > > > > > > or
> > > > > > > introduce names
> > > > > > > > > from stdatomic.h it's a vi= olation of the C standard.
> > > > > > > > >
> > > > > > > > > references:
> > > > > > > > >=C2=A0 * ISO/IEC 9899:2011 sect= ions 7.1.2, 7.1.3.
> > > > > > > > >=C2=A0 * GNU libc manual
> > > > > > > > >
> > > > > > > > > https://www.gnu.org/software/libc/manual/html_node/Reser
> > > > > > > > > ved-
> > > > > > > > > Names.html
> > > > > > > > >
> > > > > > > > > in effect the header, the name= s and in some instances
> > > > > > > > > namespaces
> > > > > > > introduced
> > > > > > > > > are reserved by the implementa= tion. there are several
> > > > > > > > > reasons in
> > > > > > > the GNU libc
> > > > > > > > Wouldn't this apply only after = the particular APIs were
> introduced?
> > > > > > > i.e. it should not apply if the compiler= does not support stdatomics.
> > > > > > >
> > > > > > > yeah, i agree they're being a bit wi= shy washy in the
> > > > > > > wording, but i'm not convinced glibc= folks are documenting
> > > > > > > this as permissive guidance against.
> > > > > > >
> > > > > > > >
> > > > > > > > > manual that explain the justif= ication for these
> > > > > > > > > reservations and if
> > > > > > > if we think
> > > > > > > > > about ODR and ABI compatibilit= y we can conceive of others.
> > > > > > > > >
> > > > > > > > > i'll also remark that the = inter-mingling of names from
> > > > > > > > > the POSIX
> > > > > > > standard
> > > > > > > > > implicitly exposed as a part o= f the EAL public API has
> > > > > > > > > been
> > > > > > > problematic for
> > > > > > > > > portability.
> > > > > > > > These should be exposed as EAL APIs= only when compiled
> > > > > > > > with a
> > > > > > > compiler that does not support stdatomic= s.
> > > > > > >
> > > > > > > you don't necessarily compile dpdk, = the application or its
> > > > > > > other dynamically linked dependencies wi= th the same compiler
> > > > > > > at the same time.
> > > > > > > i.e. basically the model of any dpdk-dev= package on any
> > > > > > > linux distribution.
> > > > > > >
> > > > > > > if dpdk is built without real stdatomic = types but the
> > > > > > > application has to interoperate with a d= ifferent kit or
> > > > > > > library that does they would be forced t= o dance around dpdk
> > > > > > > with their own version of a shim to hide= our faked up stdatomics.
> > > > > > >
> > > > > >
> > > > > > So basically, if we want a binary DPDK distri= bution to be
> > > > > > compatible with a
> > > > > separate application build environment, they both = have to
> > > > > implement atomics the same way, i.e. agree on the = ABI for atomics.
> > > > > >
> > > > > > Summing up, this leaves us with only two real= istic options:
> > > > > >
> > > > > > 1. Go all in on C11 stdatomics, also requirin= g the application
> > > > > > build
> > > > > environment to support C11 stdatomics.
> > > > > > 2. Provide our own DPDK atomics library.
> > > > > >
> > > > > > (As mentioned by Tyler, the third option - us= ing C11
> > > > > > stdatomics inside DPDK, and requiring a build= environment
> > > > > > without C11 stdatomics to implement a shim - = is not
> > > > > > realistic!)
> > > > > >
> > > > > > I strongly want atomics to be available for u= se across inline
> > > > > > and compiled
> > > > > code; i.e. it must be possible for both compiled D= PDK functions
> > > > > and inline functions to perform atomic transaction= s on the same
> atomic variable.
> > > > >
> > > > > i consider it a mandatory requirement. i don't= see practically
> > > > > how we could withdraw existing use and even if we = had clean way
> > > > > i don't see why we would want to. so this item= is defintely
> > > > > settled if you were
> > > concerned.
> > > > I think I agree here.
> > > >
> > > > >
> > > > > >
> > > > > > So either we upgrade the DPDK build requireme= nts to support
> > > > > > C11 (including
> > > > > the optional stdatomics), or we provide our own DP= DK atomics.
> > > > >
> > > > > i think the issue of requiring a toolchain conform= ant to a
> > > > > specific standard is a separate matter because any= adoption of
> > > > > C11 standard atomics is a potential abi break from= the current use of
> intrinsics.
> > > > I am not sure why you are calling it as ABI break. Refe= rring to
> > > > [1], I just see
> > > wrappers around intrinsics (though [2] does not use the intr= insics).
> > > >
> > > > [1]
> > > > https://github= .com/gcc-mirror/gcc/blob/master/gcc/ginclude/stdatom
> > > > ic.h
> > > > [2]
> > > > https://github= .com/llvm-mirror/clang/blob/master/lib/Headers/stdat
> > > > omic
> > > > .h
> > >
> > > it's a potential abi break because atomic types are not = the same
> > > types as their corresponding integer types etc.. (or at leas= t are
> > > not guaranteed to be by all implementations of c as an abstr= act language).
> > >
> > >=C2=A0 =C2=A0 =C2=A0ISO/IEC 9899:2011
> > >
> > >=C2=A0 =C2=A0 =C2=A06.2.5 (27)
> > >=C2=A0 =C2=A0 =C2=A0Further, there is the _Atomic qualifier. = The presence of the _Atomic
> > >=C2=A0 =C2=A0 =C2=A0qualifier designates an atomic type. The = size, representation, and
> alignment
> > >=C2=A0 =C2=A0 =C2=A0of an atomic type need not be the same as= those of the corresponding
> > >=C2=A0 =C2=A0 =C2=A0unqualified type.
> > >
> > >=C2=A0 =C2=A0 =C2=A07.17.6 (3)
> > >=C2=A0 =C2=A0 =C2=A0NOTE The representation of atomic integer= types need not have the
> same size
> > >=C2=A0 =C2=A0 =C2=A0as their corresponding regular types. The= y should have the same
> > > size whenever
> > >=C2=A0 =C2=A0 =C2=A0possible, as it eases effort required to = port existing code.
> > >
> > > i use the term `potential abi break' with intent because= for me to
> > > assert in absolute terms i would have to evaluate the implem= entation
> > > of every current and potential future compilers atomic vs no= n-atomic
> > > types. this as i'm sure you understand is not practical,= it would
> > > also defeat the purpose of moving to a standard. therefore i= rely on
> > > the specification prescribed by the standard not the detail = of a specific
> implementation.
> > Can we say that the platforms 'supported' by DPDK today d= o not have this
> problem? Any future platforms that will come to DPDK have to evaluate = this.
>
> sadly i don't think we can. i believe in an earlier post i linked = a bug filed on
> gcc that shows that clang / gcc were producing different layout than t= he
> equivalent non-atomic type.
I looked at that bug again, it is to do with structure.

>
> >
> > >
> > >
> > > > > the abstraction (whatever namespace it resides) al= lows the
> > > > > existing toolchain/platform combinations to mainta= in
> > > > > compatibility by defaulting to current non-standar= d intrinsics.
> > > > How about using the intrinsics (__atomic_xxx) name spac= e for
> abstraction?
> > > This covers the GCC and Clang compilers.
>
> i haven't investigated fully but there are usages of these intrins= ics that
> indicate there may be undesirable difference between clang and gcc ver= sions.
> the hint is there seems to be conditionally compiled code under __clan= g__
> when using some __atomic's.
I sent an RFC to address this [1]. I think the size specific intrinsics are= not necessary.

[1] = http://patches.dpdk.org/project/dpdk/patch/20230211015622.408487-1-honnappa= .nagarahalli@arm.com/

>
> for the purpose of this discussion clang just tries to look like gcc s= o i don't
> regard them as being different compilers for the purpose of this discu= ssion.
>
> > >
> > > the namespace starting with `__` is also reserved for the im= plementation.
> > > this is why compilers gcc/clang/msvc place name their intrin= sic and
> > > builtin functions starting with __ to explicitly avoid colli= sion
> > > with the application namespace.
>
> > Agreed. But, here we are considering '__atomic_' specific= ally (i.e.
> > not just '__')
>
> i don't understand the confusion __atomic is within the __ namespa= ce that is
> reserved.
What I mean is, we are not formulating a policy/rule to allow for any name = space that starts with '__'.

>
> let me ask this another way, what benefit do you see to trying to over= lap with
> the standard namespace? the only benefit i can see is that at some poi= nt in
> the future it avoids having to perform a mechanical change to eventual= ly
> retire the abstraction once all platform/toolchains support standard a= tomics.
> i.e. basically s/rte_atomic/atomic/g
>
> is there another benefit i'm missing?
The abstraction you have proposed solves the problem for the long term. The= proposed abstraction stops us from thinking about moving to stdatomics. IMO, the problem is short term. Using the __atomic_ name space does not hav= e any practical issues with the platforms DPDK supports (unless msvc has a = problem with this, more questions below).

>
> >
> > >
> > >=C2=A0 =C2=A0 =C2=A0ISO/IEC 9899:2011
> > >
> > >=C2=A0 =C2=A0 =C2=A07.1.3 (1)
> > >=C2=A0 =C2=A0 =C2=A0All identifiers that begin with an unders= core and either an uppercase
> > >=C2=A0 =C2=A0 =C2=A0letter or another underscore are always r= eserved for any use.
> > >
> > >=C2=A0 =C2=A0 =C2=A0...
> > >
> > > > If there is another platform that uses the same name sp= ace for
> > > > something
> > > else, I think DPDK should not be supporting that platform. > > >
> > > that's effectively a statement excluding windows platfor= m and all
> > > non-gcc compilers from ever supporting dpdk.
> > Apologies, I did not understand your comment on windows platform.= Do
> you mean to say a compiler for windows platform uses '__atomic_xxx= ' name
> space to provide some other functionality (and hence it would get excl= uded)?
>
> i mean dpdk can never fully be supported without msvc except for stati= cally
> linked builds which are niche and limit it too severely for many consu= mers to
> practically use dpdk. there are also many application developers who w= ould
> like to integrate dpdk but can't and telling them their only choic= e is to re-port
> their entire application to clang isn't feasible.
>
> i can see no technical reason why we should be excluding a major compi= ler in
> broad use if it is capable of building dpdk. msvc arguably has some of= the
> most sophisticated security features in the industry and the use of th= ose
> features is mandated by many of the customers who might deploy dpdk > applications on windows.
I did not mean DPDK should not support msvc (may be my sentence below was m= isunderstood).
Does msvc provide '__atomic_xxx' intrinsics?

>
> > Clang supports these intrinsics. I am not sure about the merit of= supporting
> other non-gcc compilers. May be a topic Techboard discussion.
> >
> > >
> > > > What problems do you see?
> > >
> > > i'm fairly certain at least one other compiler uses the = __atomic
> > > namespace but
> > Do you mean __atomic namespace is used for some other purpose? > >
> > > it would take me time to check, the most notable potential i= ssue
> > > that comes to mind is if such an intrinsic with the same nam= e is
> > > provided in a different implementation and has either regres= sive
> > > code generation or different semantics it would be bad becau= se it is
> > > intrinsic you can't just hack around it with #undef __at= omic to shim in a
> semantically correct version.
> > I do not think we should worry about regressive code generation p= roblem. It
> should be fixed by that compiler.
> > Different semantics is something we need to worry about. It would= be good
> to find out more about a compiler that does this.
>
> again, this is about portability it's about potential not that we = can find an
> example.
>
> >
> > >
> > > how about this, is there another possible namespace you migh= t
> > > suggest that conforms or doesn't conflict with the the r= ules defined
> > > in ISO/IEC 9899:2011
> > > 7.1.3 i think if there were that would satisfy all of my con= cerns
> > > related to namespaces.
> > >
> > > keep in mind the point of moving to a standard is to achieve=
> > > portability so if we do things that will regress us back to = being
> > > dependent on an implementation we haven't succeeded. tha= t's all i'm
> trying to guarantee here.
> > Agree. We are trying to solve a problem that is temporary. I am t= rying to
> keep the problem scope narrow which might help us push to adopt the > standard sooner.
>
> i do wish we could just target the standard but unless we are willing = to draw a
> line and say no more non std=3Dc11 and also we potentially break the a= bi we
> are talking years. i don't think it is reasonable to block progres= s for years, so
> i'm offering a transitional path. it's an evolution over time = that we have to
> manage.
Apologies if I am sounding like I am blocking progress. Rest assured, we wi= ll find a way. It is just about which solution we are going to pick.
Also, is there are any information on how long before we move to C11?

>
> >
> > >
> > > i feel like we are really close on this discussion, if we ca= n just
> > > iron this issue out we can probably get going on the actual = changes.
> > >
> > > thanks for the consideration.
> > >
> > > >
> > > > >
> > > > > once in place it provides an opportunity to introd= uce new
> > > > > toolchain/platform combinations and enables an opt= -in capability
> > > > > to use stdatomics on existing toolchain/platform c= ombinations
> > > > > subject to community discussion on how/if/when. > > > > >
> > > > > it would be good to get more participants into the= discussion so
> > > > > i'll cc techboard for some attention. i feel l= ike the only area
> > > > > that isn't decided is to do or not do this in = rte_ namespace.
> > > > >
> > > > > i'm strongly in favor of rte_ namespace after = discussion, mainly
> > > > > due to to disadvantages of trying to overlap with = the standard
> > > > > namespace while not providing a compatible api/abi= and because
> > > > > it provides clear disambiguation of that differenc= e in semantics
> > > > > and compatibility with
> > > the standard api.
> > > > >
> > > > > so far i've noted the following
> > > > >
> > > > > * we will not provide the non-explicit apis.
> > > > +1
> > > >
> > > > > * we will make no attempt to support operate on st= ruct/union atomics
> > > > >=C2=A0 =C2=A0with our apis.
> > > > +1
> > > >
> > > > > * we will mirror the standard api potentially in t= he rte_ namespace to
> > > > >=C2=A0 =C2=A0- reference the standard api documenta= tion.
> > > > >=C2=A0 =C2=A0- assume compatible semantics (sans ex= ceptions from first 2 points).
> > > > >
> > > > > my vote is to remove 'potentially' from th= e last point above for
> > > > > reasons previously discussed in postings to the ma= il thread.
> > > > >
> > > > > thanks all for the discussion, i'll send up a = patch removing
> > > > > non-explicit apis for viewing.
> > > > >
> > > > > ty
--000000000000243f6e05f49681e1--