From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 0A0812716 for ; Wed, 6 May 2015 00:46:33 +0200 (CEST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga103.jf.intel.com with ESMTP; 05 May 2015 15:46:34 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,375,1427785200"; d="scan'208";a="705788584" Received: from irsmsx102.ger.corp.intel.com ([163.33.3.155]) by fmsmga001.fm.intel.com with ESMTP; 05 May 2015 15:46:32 -0700 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.178]) by IRSMSX102.ger.corp.intel.com ([169.254.2.145]) with mapi id 14.03.0224.002; Tue, 5 May 2015 23:46:31 +0100 From: "Ananyev, Konstantin" To: WangDong , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH] librte_eal:Using compiler memory barrier for IA processor's rte_wmb/rte_rmb. Thread-Index: AQHQh0mlf9cWltXZ8kiIn30Bsn/4OJ1t+a6w Date: Tue, 5 May 2015 22:46:30 +0000 Message-ID: <2601191342CEEE43887BDE71AB97725821424E84@irsmsx105.ger.corp.intel.com> References: In-Reply-To: Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] librte_eal:Using compiler memory barrier for IA processor's rte_wmb/rte_rmb. X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 22:46:34 -0000 Hi Dong, > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of WangDong > Sent: Tuesday, May 05, 2015 4:38 PM > To: dev@dpdk.org > Subject: [dpdk-dev] [PATCH] librte_eal:Using compiler memory barrier for = IA processor's rte_wmb/rte_rmb. >=20 > The current implementation of rte_wmb/rte_rmb for x86 is using processor = memory barrier. It's unnessary for IA processor, compiler > memory barrier is enough.=20 I wouldn't say they are 'unnecessary'. There are situations, even on IA, when you need _fence_ isntructions. So, please leave rte_*mb() macros unmodified. I still think that we need to create a new set of architecture dependent ma= cros, as what discussed before. Probably by analogy with linux kernel rte_smp_*mb() is a good name for them= . =20 Though if you have some better name in mind, I am open to suggestions here. > But if dpdk runing on a AMD processor, maybe we should use processor memo= ry barrier. As far as I remember, amd has the same memory ordering model. So, I don't think we need #ifdef RTE_ARCH_X86_IA here. Konstantin > I add a macro to distinguish them, if we compile DPDK for IA processor, a= dd the macro (RTE_ARCH_X86_IA) can improve performance > with compiler memory barrier. Or we can add RTE_ARCH_X86_AMD for using pr= ocessor memory barrier, in this case, if didn't add the > macro, the memory ordering will not be guaranteed. Which macro is better? > If this patch applied, the PMD's old implementation of compiler memory ba= rrier (some volatile variable) can be fixed with rte_rmb() > and rte_wmb() for any architecture. >=20 > --- > lib/librte_eal/common/include/arch/x86/rte_atomic.h | 10 ++++++++++ > 1 file changed, 10 insertions(+) >=20 > diff --git a/lib/librte_eal/common/include/arch/x86/rte_atomic.h b/lib/li= brte_eal/common/include/arch/x86/rte_atomic.h > index e93e8ee..52b1e81 100644 > --- a/lib/librte_eal/common/include/arch/x86/rte_atomic.h > +++ b/lib/librte_eal/common/include/arch/x86/rte_atomic.h > @@ -49,10 +49,20 @@ extern "C" { >=20 > #define rte_mb() _mm_mfence() >=20 > +#ifdef RTE_ARCH_X86_IA > + > +#define rte_wmb() rte_compiler_barrier() > + > +#define rte_rmb() rte_compiler_barrier() > + > +#else > + > #define rte_wmb() _mm_sfence() >=20 > #define rte_rmb() _mm_lfence() >=20 > +#endif > + > /*------------------------- 16 bit atomic operations -------------------= ------*/ >=20 > #ifndef RTE_FORCE_INTRINSICS > -- > 1.9.1