<snip> > >> > >> Subject: Re: [PATCH v4 4/4] eal/atomic: add wrapper for c11 atomics > >> > >> On Tue, May 12, 2020 at 4:03 pm, Phil Yang <mailto:phil.y...@arm.com> > >> wrote: > >> > >> parameter. Signed-off-by: Phil Yang <mailto:phil.y...@arm.com> > >> > >> > >> What is the purpose of having rte_atomic at all? > >> Is this level of indirection really helping? > >> [HONNAPPA] (not sure why this email has html format, converted to > >> text > >> format) > >> I believe you meant, why not use the __atomic_xxx built-ins directly? > >> The only reason for now is handling of > >> __atomic_thread_fence(__ATOMIC_SEQ_CST) for x86. This is equivalent > >> to rte_smp_mb which has an optimized implementation for x86. > >> According to Konstantin, the compiler does not generate optimal code. > >> Wrapping that built-in alone is going to be confusing. > >> > >> The wrappers also allow us to have our own implementation using > >> inline assembly for compilers versions that do not support C11 atomic > >> built- ins. But, I do not know if there is a need to support those > >> versions. > > If I recall correctly, someone mentioned that one (or more) of the aging > enterprise Linux distributions don't include a compiler with C11 atomics. > > > > I think Stephen is onto something here... > > > > It is silly to add wrappers like this, if the only purpose is to support > compilers and distributions that don't properly support an official C standard > which is nearly a decade old. The quality and quantity of the DPDK > documentation for these functions (including examples, discussions on Stack > Overflow, etc.) will be inferior to the documentation of the standard C11 > atomics, which increases the probability of incorrect use. > > > What's being used in DPDK today, and what's being wrapped here, is not > standard C11 atomics - it's a bunch of GCC built-ins. Nothing in the __ > namespace is in the standard. It's reserved for the implementation (e.g. > compiler). I have tried to understand what it mean by 'built-ins', but I have not got a good answer. So, does it mean that the built-in function (same symbol and API interface) may not be available in another C compiler? IMO, this is what matters for DPDK. Currently, the same built-in functions are available in GCC and Clang.
> > > > And if some compiler generates code that is suboptimal for a user, then it > should be the choice of the user to either accept it or use a better compiler. > Using a suboptimal compiler will not only affect the user's DPDK applications, > but all applications developed by the user. And if he accepts it for his other > applications, he will also accept it for his DPDK applications. > > > > We could introduce some sort of marker or standardized comment to > indicate when functions only exist for backwards compatibility with ancient > compilers and similar, with a reference to documentation describing why. And > when the documented preconditions are no longer relevant, e.g. when those > particular enterprise Linux distributions become obsolete, these functions > become obsolete too, and should be removed. However, getting rid of > obsolete cruft will break the ABI. In other words: Added cruft will never be > removed again, so think twice before adding. > > > > > > Med venlig hilsen / kind regards > > - Morten Brørup > > > > > >
