> -----Original Message----- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jerin Jacob > Sent: Tuesday, November 3, 2015 4:19 PM > To: Ananyev, Konstantin <konstantin.ananyev at intel.com> > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [RFC ][PATCH] Introduce > RTE_ARCH_STRONGLY_ORDERED_MEM_OPS configuration parameter > > On Tue, Nov 03, 2015 at 03:57:24PM +0000, Ananyev, Konstantin wrote: > > > > > > > -----Original Message----- > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jerin Jacob > > > Sent: Tuesday, November 03, 2015 3:52 PM > > > To: dev at dpdk.org > > > Subject: [dpdk-dev] [RFC ][PATCH] Introduce > > > RTE_ARCH_STRONGLY_ORDERED_MEM_OPS configuration parameter > > > > > > rte_ring implementation needs explicit memory barrier in weakly > > > ordered architecture like ARM unlike strongly ordered architecture > > > like X86 > > > > > > Introducing RTE_ARCH_STRONGLY_ORDERED_MEM_OPS configuration to > > > abstract such dependency so that other weakly ordered architectures > > > can reuse this infrastructure. > > > > Looks a bit clumsy. > > Please try to follow this suggestion instead: > > http://dpdk.org/ml/archives/dev/2015-October/025505.html > > Make sense. Do we agree on a macro that is defined based upon > RTE_ARCH_STRONGLY_ORDERED_MEM_OP to remove clumsy #ifdef every where ? > > Jerin
Yes to the single-defined barrier macro. However, for what controls it, is it really worthwhile defining a new RTE_ variable for it? Can we not base it on RTE_ARCH directly? /Bruce