[dpdk-dev] [PATCH] atomic: clarify use of memory barriers

[Olivier MATZ]

Hi Konstantin,

Thanks for these code examples and explanations.

On 05/20/2014 06:35 PM, Ananyev, Konstantin wrote:
 > So with the following fragment of code:
 > extern int *x;
 > extern  __128i a, *p;
 > L0:
 > _mm_stream_si128( p, a);
 > rte_compiler_barrier();
 > L1:
 > *x = 0;
 >
 > There is no guarantee that store at L0 will always be finished
 > before store at L1.

This code fragment looks very similar to what is done in
__rte_ring_sp_do_enqueue():

     [...]
     ENQUEUE_PTRS(); /* I expect it is converted to an SSE store */
     rte_compiler_barrier();
     [...]
     r->prod.tail = prod_next;

So, according to your previous explanation, I understand that
this code would require a write memory barrier in place of the
compiler barrier. Am I wrong?

If it's correct, we are back on the initial question: in this kind
of code, if the programmer wants that all stores are issued before
setting the value of r->prod.tail. This is the definition of the
write memory barrier. So wouldn't be better that he explicitelly
calls rte_smp_wmb() instead of adding a compiler barrier because
he knows that it is sufficient on all currently supported CPUs?
Can we be sure that next Intel CPU generations will behave that
way in the future?

Moreover, if I understand well, a real wmb() is needed only if
a SSE store is issued. But the programmer may not control that,
it's the job of the compiler.

 > But now, there seems a confusion: everyone has to remember that
 > smp_mb() and smp_wmb() are 'real' fences, while smp_rmb() is not.
 > That's why my suggestion was to simply keep using compiler_barrier()
 > for all cases, when we don't need real fence.

I'm not sure the programmer has to know which smp_*mb() is a real fence
or not. He just expects that it generates the proper CPU instructions
that guarantees the effectiveness of the memory barrier.

Regards,
Olivier