[dpdk-dev] memory barriers in rte_ring

[Venkatesan, Venky]

One caveat - a compiler_barrier should be enough when both sides are using strongly-ordered memory operations (as in the case of the rings). Weakly ordered operations will still need fencing.

-Venky

-----Original Message-----
From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Stephen Hemminger
Sent: Thursday, March 27, 2014 1:20 PM
To: Olivier MATZ
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] memory barriers in rte_ring

On Thu, 27 Mar 2014 20:47:37 +0100
Olivier MATZ <olivier.matz at 6wind.com> wrote:

> Hi Stephen,
> 
> On 03/27/2014 08:06 PM, Stephen Hemminger wrote:
> > Long answer: for the multple CPU access ring, it is equivalent to smp_wmb and smp_rmb
> >   in Linux kernel. For x86 where DPDK is used, this can normally be replaced by simpler
> >   compiler barrier. In kernel there is a special flage X86_OOSTORE which is only enabled
> >   for a few special cases, for most cases it is not. When cpu doesnt do out of order
> >   stores, there are no cases where other cpu will see wrong state.
> 
> Thank you for this clarification.
> 
> So, if I understand properly, all usages of rte_*mb() sequencing 
> memory operations between CPUs could be replaced by a compiler 
> barrier. On the other hand, if the memory is also accessed by a 
> device, a memory barrier has to be used.
> 
> Olivier
> 

I think so for the current architecture that DPDK runs on. It might be good to abstract this in some way for eventual users in other environments.