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

[Ananyev, Konstantin]

> -----Original Message-----
> From: Richardson, Bruce
> Sent: Thursday, October 16, 2014 10:43 AM
> To: Chao CH Zhu; Ananyev, Konstantin
> Cc: dev at dpdk.org
> Subject: RE: [dpdk-dev] [PATCH 02/12] Add atomic operations for IBM Power architecture
> 
> > -----Original Message-----
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Chao CH Zhu
> > 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. This
> > should be architecture-independent. And the "sync" instruction is a
> > hardware barrier which depends on PowerPC architecture. So I think the
> > compiler barrier should be the same on x86 and PowerPC. Any comments?
> > Please correct me if I was wrong.
> >
> I would agree with that assessment, as far as it goes, in that a compiler barrier is going to be the same on both architectures. However,
> we also need to start thinking about actual use cases - how to we specify the barriers in a piece of code where we need a full memory
> barrier on PPC and only a compiler barrier on IA?
> My suggestion would be to do first as you propose and have proper primitives for the different barrier types defined correctly for
> each platform - with the compiler barrier being, presumably, common across each one. Then, as a second step, we probably need to
> look at defining "logical" barrier types (for want of a better term) that can then be used in the code and which would be different
> across platforms.

Yeh, as I said in other mail, what we 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().

BTW, for my own curiosity:
Is there any good use for compiler_barrier() on systems with weakly ordered memory model? 

> 
> Does this make sense to do this way? Is it the best solution? Do we want to define the basic primitives or are we only ever likely to
> need the logical barrier types?
> 
> /Bruce