> -----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
