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