> From: Bruce Richardson [mailto:bruce.richard...@intel.com] > Sent: Friday, 3 February 2023 14.57 > > Having read through the whole thread a second time, I am starting to > realise how complex a problem this could be. From what I read, I would > tend > towards the opinion that we shouldn't provide any atomics in DPDK at > all, > and just rely on the C standard ones.
Yes, but atomics were only standardized for C with C11. So that is the problem - and a good reason for pushing for C11. Before C11, there were only compiler specific intrinsics. > The main complication in any > solution > I suspect is going to be the use of atomics in static inline functions > we > have in our header files. Not only that. If we consider atomic variables (and the type of such variables) private to DPDK, we would need to provide public functions to manipulate those atomic variables. If not, the application will be unable to interact with them. And if we expose such functions, why not also make the DPDK atomic type itself public? In other words, expose a DPDK API for atomics, such as Tyler's. (And as I mentioned on the techboard meeting, I think atomic operations should be available in inline code, for performance reasons.) -Morten
