> > > From: Chao CH Zhu [mailto:bjzhuc at cn.ibm.com] > Sent: Thursday, October 16, 2014 4:14 AM > To: Ananyev, Konstantin > Cc: dev at dpdk.org > Subject: RE: [dpdk-dev] [PATCH 02/12] Add atomic operations for IBM Power > architecture > > Konstantin, > > In my understanding, compiler barrier is a kind of software barrier which > prevents the compiler from moving memory accesses across > the barrier.
Yes, compiler_barrier() right now only guarantees that the compiler wouldn't reorder instructions across it while emitting the code. > This should be architecture-independent. And the "sync" instruction is a > hardware barrier which depends on PowerPC > architecture. I understand what "sync" does. >So I think the compiler barrier should be the same on x86 and PowerPC. Any >comments? Please correct me if I was > wrong. The thing is that current DPDK code will not work correctly on system with weak memory ordering - IA has quite strict memory ordering model and there is a code inside DPDK that relies on the fact that CPU would follow that model. For such places in the code - compiler barrier is enough for IA, but is not enough for PPC. Do you worry about the names here- compiler barrier will become a HW one? :)? In that case what you probably can do: Create a new architecture dependent macro: rte_barrier(). That would expand into rte_compiler_barrier() for IA and to rte_mb() for PPC. Got through all references of rte_compiler_barrier() inside DPDK and replace it with rte_barrier(). Konstantin > > Thanks a lot! > > Best Regards! > ------------------------------ > Chao Zhu > > > > > From: ? ? ? ?"Ananyev, Konstantin" <konstantin.ananyev at intel.com> > To: ? ? ? ?Chao CH Zhu/China/IBM at IBMCN, "dev at dpdk.org" <dev at dpdk.org> > Date: ? ? ? ?2014/10/16 08:38 > Subject: ? ? ? ?RE: [dpdk-dev] [PATCH 02/12] Add atomic operations for IBM > Power ? ? ? ?architecture > ________________________________________ > > > > > Hi, > > > -----Original Message----- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Chao Zhu > > Sent: Friday, September 26, 2014 10:36 AM > > To: dev at dpdk.org > > Subject: [dpdk-dev] [PATCH 02/12] Add atomic operations for IBM Power > > architecture > > > > The atomic operations implemented with assembly code in DPDK only > > support x86. This patch add architecture specific atomic operations for > > IBM Power architecture. > > > > Signed-off-by: Chao Zhu <bjzhuc at cn.ibm.com> > > --- > > ?.../common/include/powerpc/arch/rte_atomic.h ? ? ? | ?387 > > ++++++++++++++++++++ > > ?.../common/include/powerpc/arch/rte_atomic_arch.h ?| ?318 ++++++++++++++++ > > ?2 files changed, 705 insertions(+), 0 deletions(-) > > ?create mode 100644 lib/librte_eal/common/include/powerpc/arch/rte_atomic.h > > ?create mode 100644 > > lib/librte_eal/common/include/powerpc/arch/rte_atomic_arch.h > > > ... > > + > > diff --git a/lib/librte_eal/common/include/powerpc/arch/rte_atomic_arch.h > > b/lib/librte_eal/common/include/powerpc/arch/rte_atomic_arch.h > > new file mode 100644 > > index 0000000..fe5666e > > --- /dev/null > > + > ... > >+#define ? ? ? ? ? ? ? ? rte_arch_rmb() asm volatile("sync" : : : "memory") > >+ > > +#define ? ? ? ? ? ? ? ? rte_arch_compiler_barrier() do { ? ? ? ? ? ? ? ? ? > > ? ? ? ? ? ? ? ?\ > > + ? ? ? ? ? ? ? ? asm volatile ("" : : : "memory"); ? ? ? ? ? ? ? ? \ > > +} while(0) > > I don't know much about PPC architecture, but as I remember it uses a > ?weakly-ordering memory model. > Is that correct? > If so, then you probably need rte_arch_compiler_barrier() to be "sync" > instruction (like mb()s above) . > The reason is that IA has much stronger memory ordering model and there are a > lot of places in the code where it implies > that ?ordering. > For example - ring enqueue/dequeue functions. > > Konstantin
