Re: [dpdk-dev] [PATCH 02/12] Add atomic operations for IBM Power architecture

["Ananyev, Konstantin" <konstantin.ananyev@intel.com>]

> 
> 
> From: Chao CH Zhu [mailto:bjzhuc@cn.ibm.com]
> Sent: Thursday, October 16, 2014 4:14 AM
> To: Ananyev, Konstantin
> Cc: dev@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@intel.com>
> To:        Chao CH Zhu/China/IBM@IBMCN, "dev@dpdk.org" <dev@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@dpdk.org] On Behalf Of Chao Zhu
> > Sent: Friday, September 26, 2014 10:36 AM
> > To: dev@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@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