[PATCH v2 19/19] ring: use rte optional stdatomic API

Morten Brørup mb at smartsharesystems.com
Tue Oct 24 11:56:11 CEST 2023


> From: Konstantin Ananyev [mailto:konstantin.v.ananyev at yandex.ru]
> Sent: Tuesday, 24 October 2023 10.43
> 
> 17.10.2023 21:31, Tyler Retzlaff пишет:
> > Replace the use of gcc builtin __atomic_xxx intrinsics with
> > corresponding rte_atomic_xxx optional stdatomic API
> >
> > Signed-off-by: Tyler Retzlaff <roretzla at linux.microsoft.com>
> > ---

[...]

> >   	if (!single)
> > -		rte_wait_until_equal_32(&ht->tail, old_val, __ATOMIC_RELAXED);
> > +		rte_wait_until_equal_32((volatile uint32_t *)(uintptr_t)&ht-
> >tail, old_val,
> 
> I suppose we do need that double type conversion only for atomic types
> right?
> 
> > +			rte_memory_order_relaxed);
> >
> >   	ht->tail = new_val;
> >   }

This got me thinking...

Do we want to cast away the value's atomic attribute like this, or should we introduce new rte_atomic_wait_XX() functions with the parameters being pointers to atomic values, instead of pointers to simple values?

Just a thought.

The initial rte_atomic_wait_XX() implementations could simply cast a away the atomic attribute like here.



More information about the dev mailing list