> From: Honnappa Nagarahalli [mailto:honnappa.nagaraha...@arm.com] > Sent: Wednesday, 1 February 2023 02.08 > > > From: Thomas Monjalon <tho...@monjalon.net> > > Sent: Tuesday, January 31, 2023 4:42 PM > > > > Honnappa, please could you give your view on the future of atomics in > DPDK? > Thanks Thomas, apologies it has taken me a while to get to this > discussion. > > IMO, we do not need DPDK's own abstractions. APIs from stdatomic.h > (stdatomics as is called here) already serve the purpose. These APIs > are well understood and documented. > > For environments where stdatomics are not supported, we could have a > stdatomic.h in DPDK implementing the same APIs (we have to support only > _explicit APIs). This allows the code to use stdatomics APIs and when > we move to minimum supported standard C11, we just need to get rid of > the file in DPDK repo.
I agree with Honnappa. DPDK should include a shim to expose the C11 stdatomic.h API for environments not already having the C11 stdatomic.h. With this, DPDK steps outside its native rte_ prefixed namespace, but it should not collide with anyone else's namespace. It could collide with someone else's namespace if the application implements a similar shim. We cannot prevent this from happening, but if it does, it should be fixed in the application. > > > > > > > 12/01/2023 22:26, Tyler Retzlaff: > > > Introduce atomics abstraction that permits optional use of standard > > > C11 atomics when meson is provided the new enable_stdatomics=true > > option. > > > > > > Signed-off-by: Tyler Retzlaff <roret...@linux.microsoft.com>
