From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id DAA827E87 for ; Thu, 16 Oct 2014 12:56:46 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 16 Oct 2014 04:04:39 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.04,731,1406617200"; d="scan'208";a="615459941" Received: from irsmsx102.ger.corp.intel.com ([163.33.3.155]) by fmsmga002.fm.intel.com with ESMTP; 16 Oct 2014 04:04:37 -0700 Received: from irsmsx108.ger.corp.intel.com (163.33.3.3) by IRSMSX102.ger.corp.intel.com (163.33.3.155) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 16 Oct 2014 12:04:37 +0100 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.174]) by IRSMSX108.ger.corp.intel.com ([169.254.11.21]) with mapi id 14.03.0195.001; Thu, 16 Oct 2014 12:04:37 +0100 From: "Ananyev, Konstantin" To: "Richardson, Bruce" , Chao CH Zhu Thread-Topic: [dpdk-dev] [PATCH 02/12] Add atomic operations for IBM Power architecture Thread-Index: AQHP6SWKyZOeGhgsRUmFcSmCVnEeFJwyjqkA Date: Thu, 16 Oct 2014 11:04:35 +0000 Message-ID: <2601191342CEEE43887BDE71AB97725821393F9E@IRSMSX105.ger.corp.intel.com> References: <1411724186-8036-1-git-send-email-bjzhuc@cn.ibm.com> <1411724186-8036-3-git-send-email-bjzhuc@cn.ibm.com> <2601191342CEEE43887BDE71AB97725821393C8F@IRSMSX105.ger.corp.intel.com> <59AF69C657FD0841A61C55336867B5B03441F561@IRSMSX103.ger.corp.intel.com> In-Reply-To: <59AF69C657FD0841A61C55336867B5B03441F561@IRSMSX103.ger.corp.intel.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH 02/12] Add atomic operations for IBM Power architecture 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: Thu, 16 Oct 2014 10:56:47 -0000 > -----Original Message----- > From: Richardson, Bruce > Sent: Thursday, October 16, 2014 10:43 AM > To: Chao CH Zhu; Ananyev, Konstantin > Cc: dev@dpdk.org > Subject: RE: [dpdk-dev] [PATCH 02/12] Add atomic operations for IBM Power= architecture >=20 > > -----Original Message----- > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Chao CH Zhu > > 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 Pow= er > > architecture > > > > Konstantin, > > > > In my understanding, compiler barrier is a kind of software barrier whi= ch > > prevents the compiler from moving memory accesses across the barrier. T= his > > 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 primiti= ves for the different barrier types defined correctly for > each platform - with the compiler barrier being, presumably, common acros= s 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 P= PC. Got through all references of rte_compiler_barrier() inside DPDK and replac= e it with rte_barrier(). BTW, for my own curiosity: Is there any good use for compiler_barrier() on systems with weakly ordered= memory model?=20 >=20 > 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? >=20 > /Bruce