Re: [PATCH] eal: introduce atomics abstraction

[Tyler Retzlaff <roretzla@linux.microsoft.com>]

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ørup 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 <thomas@monjalon.net>
> > > > > > 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=c11, though.

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.

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).

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.

> 
> /Bruce