On 2020-05-13 10:57, Morten Brørup wrote: >> From: Honnappa Nagarahalli [mailto:honnappa.nagaraha...@arm.com] >> Sent: Tuesday, May 12, 2020 9:24 PM >> >> <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). > 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 > > >
