<snip>

quoted

quoted

quoted

Simply replace the SMP barrier with atomic thread fence for i40e
hw ring

sacn,

quoted

quoted

if there is no synchronization point.

Signed-off-by: Joyce Kong <redacted>
Reviewed-by: Ruifeng Wang <redacted>
---
 drivers/net/i40e/i40e_rxtx.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/i40e/i40e_rxtx.c

b/drivers/net/i40e/i40e_rxtx.c index 9aaabfd92..86e2f083e 100644

--- a/drivers/net/i40e/i40e_rxtx.c
+++ b/drivers/net/i40e/i40e_rxtx.c

@@ -482,7 +482,8 @@ i40e_rx_scan_hw_ring(struct i40e_rx_queue

*rxq)

I40E_RXD_QW1_STATUS_SHIFT;

quoted

quoted

              }

-             rte_smp_rmb();
+             /* This barrier is to order loads of different words
+ in the

descriptor */

quoted

quoted

+             rte_atomic_thread_fence(__ATOMIC_ACQUIRE);

Now for x86, you actually replace a compiler barrier with a memory
fence,

this may have potential performance impact which need additional
resource to investigate

No memory fence instruction is generated for __ATOMIC_ACQUIRE on x86
for any version of gcc or clang that I've tried, based on experiments
here:

    https://godbolt.org/z/Yxr1vGhKP

Nice tool!
I try to write some dummy code combined with or without
__atomic_thread_fence(__ATOMIC_ACQUIRE)
but I didn't see any difference of the generated assembly code, does that means
__atomic_thread_fence(__ATOMIC_ACQUIRE) just does nothing on x86?

Yes, it should not have any barriers generated for x86. At the same time it also acts as a compiler barrier.