[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