[RFC 13/32] ring: replace SMP read barrier with C11 acquire fence

[Konstantin Ananyev]

> rte_smp_rmb() is deprecated. The acquire fence generates the same
> code everywhere the gcc implementation is used: a compiler barrier
> on x86 and dmb ishld on ThunderX.
> 
> The gcc implementation itself is kept: unlike the lock-free stack,
> the in-tree comment records a 10% x86 performance drop with the
> C11 version, which needs re-measuring with current compilers
> before RTE_USE_C11_MEM_MODEL can be removed.
> 
> Signed-off-by: Stephen Hemminger <stephen at networkplumber.org>
> ---
>  lib/ring/rte_ring_gcc_pvt.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/lib/ring/rte_ring_gcc_pvt.h b/lib/ring/rte_ring_gcc_pvt.h
> index 340ece28c7..9c2c58824d 100644
> --- a/lib/ring/rte_ring_gcc_pvt.h
> +++ b/lib/ring/rte_ring_gcc_pvt.h
> @@ -55,10 +55,10 @@ __rte_ring_headtail_move_head_st(struct
> rte_ring_headtail *d,
> 
>  	*old_head = d->head;
> 
> -	/* add rmb barrier to avoid load/load reorder in weak
> -	 * memory model. It is noop on x86
> +	/* Acquire fence to avoid load/load reorder in weak
> +	 * memory model. It is noop on x86.
>  	 */
> -	rte_smp_rmb();
> +	rte_atomic_thread_fence(rte_memory_order_acquire);
> 
>  	/*
>  	 *  The subtraction is done between two unsigned 32bits value
> --

Acked-by: Konstantin Ananyev <konstantin.ananyev at huawei.com>

As a side note - do we really need two versions of __rte_ring_headtail_move_head_st()?
Might be just keep 2 versions of _mt, while _st can be merged into one?

> 2.53.0