[dpdk-dev] memory barriers in rte_ring
venky.venkatesan at intel.com
Fri Mar 28 00:53:29 CET 2014
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.
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.
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.
More information about the dev