Re: [dpdk-dev] [PATCH v1] test/ticketlock: use C11 atomic builtins for lcores sync

[Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>]

<snip>

> > >
> > > your subject line indicates the use of C11 which is a standard [1].
> > >
> > > the patch itself uses gcc atomics builtins which are not part of C11
> > > standard so the subject line is incorrect and misleading.
> > Ok, understood. How about the following?
> > "use gcc's C11 atomic built-ins for lcore synchronization"
> 
> drop 'C11' from it and it describes the actual change
> 
> >
> > >
> > > [1] http://www.open-
> std.org/jtc1/sc22/wg14/www/standards.html#9899
> > >
> > > >
> > > > Not sure if these compilers are supported in DPDK. DPDK officially
> > > > supports
> > > gcc, clang (not sure on icc).
> > >
> > > dpdk may incorporate support for other compilers in the future so
> > > unless there is substantive justification for moving to
> > > non-standard/non-portable code i'm asking that this change not be made
> as it will complicate those future efforts.
> > There is some history [1] behind why we are doing this. I guess new
> compiler support needs to be discussed in the future.
> >
> > [1]
> > https://www.dpdk.org/blog/2021/03/26/dpdk-adopts-the-c11-memory-
> model/
> 
> thanks for the reference. it seems this documents explicitly states the choice
> to not use C11 stdatomic.h and the basis of that choice appears to be to
> support old versions of gcc.
> 
> it doesn't seem particularly forward looking to reduce future compiler
> portability to support old versions of gcc thereby excluding standards
> compliant compilers.
> 
> i would like to hear from the tech board that it is the best trade-off for the
> project to reduce compiler portability for older versions of gcc instead of
> adopting standard C11 atomics which locks out the use of other compilers.
> 
> if this change does go forward could i at least ask that the builtins used are
> abstracted behind either macros or inline functions so that if alternate
> implementations appear for the builtins we don't have to perform shotgun
> surgery on the broader codebase when it arrives?
There is already code using the built-ins in the repo. I do not see why this is any different.
How difficult it is for the compiler to support these built-ins?
If DPDK supports another compiler in the future that do not have these built-ins, the shotgun approach should be straight forward as there is a 1:1 mapping between the built-ins and the C11 atomic APIs from stdatomic.h.

> 
> thanks!