Re: rte_atomic API compatibility & standard atomics

[Tyler Retzlaff <roretzla@linux.microsoft.com>]

On Mon, Mar 27, 2023 at 10:08:10PM +0200, Morten Brørup wrote:
> > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> > Sent: Monday, 27 March 2023 21.39
> > 
> > Hi folks,
> > 
> > I don't think we discussed it specifically but what is the expectation
> > in relation to converting to standard atomics and compatibility of the
> > legacy rte_atomic APIs?
> > 
> > We can't really convert the inline function implementations of the
> > rte_atomic APIs because doing so would break compatibility. This is
> > because if the implementation uses standard atomics APIs then we are
> > required to pass _Atomic types to the generic atomic intrinsics.
> > 
> > We can choose to just leave the rte_atomic API implementations as they
> > are using the GCC builtins and i'm fine with that, but I do need some
> > help with what to do with msvc then since it doesn't have those
> > builtins.
> > 
> > The options seem to be as follows.
> > 
> > 1.
> > Just cast the non-atomic types in the rte_atomic APIs implementation
> > to _Atomic which may work but i'm pretty sure is undefined behavior
> > since
> > you can't qualify a non _Atomic type to suddenly be _Atomic.
> > 
> > 2.
> > We could conditionally compile (hide) the legacy rte_atomic APIs when
> > msvc is in use, this seems not bad since there technically aren't any
> > Windows/MSVC consumers, but if someone wanted to port an existing
> > application they would have to adapt the code to avoid use of
> > rte_atomic.
> > 
> > For now I think the safest option is to go with 2 since it doesn't
> > impose any compatibility risk and conditional compilation only exists
> > until we deprecate and remove the old rte_atomic APIs.
> > 
> > Are there any other options i'm missing here?
> > 
> > Thanks
> 
> As a variant of your second option, you could make most of the legacy rte_atomic APIs available to MSVC by changing the atomic counter types from volatile to _Atomic. Then only the atomic cmpset() and exchange() functions are unavailable for the application. E.g. for the 32 bit atomic counter type:
> 
> typedef struct {
> -	volatile int32_t cnt; /**< An internal counter value. */
> +	_Atomic int32_t cnt; /**< An internal counter value. */
> } rte_atomic32_t;
> 

it's a good suggestion. but i'm not sure i want to get bogged down
making an old api available that hopefully we will remove soon.

though i'm still torn because i would really like the path to use msvc
for any application to be lower burden.

unless there are objections i think i'll do 2 as is. if good progress is
made we can re-evaluate doing the extra work to make available the old apis
as you suggest or potentially leave them unavailable forever subject to
any plans to deprecate and remove them.

thanks!