<snip>

quoted

quoted

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

quoted

quoted

[1] http://www.open-

std.org/jtc1/sc22/wg14/www/standards.html#9899

quoted

quoted

quoted

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.

quoted

There is some history [1] behind why we are doing this. I guess new

compiler support needs to be discussed in the future.

quoted

[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!