From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 6F6BF593E for ; Thu, 16 Oct 2014 11:35:30 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 16 Oct 2014 02:36:56 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.04,731,1406617200"; d="scan'208";a="619761286" Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by orsmga002.jf.intel.com with ESMTP; 16 Oct 2014 02:43:21 -0700 Received: from irsmsx109.ger.corp.intel.com (163.33.3.23) by IRSMSX101.ger.corp.intel.com (163.33.3.153) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 16 Oct 2014 10:42:47 +0100 Received: from irsmsx103.ger.corp.intel.com ([169.254.3.175]) by IRSMSX109.ger.corp.intel.com ([169.254.13.253]) with mapi id 14.03.0195.001; Thu, 16 Oct 2014 10:42:47 +0100 From: "Richardson, Bruce" To: Chao CH Zhu , "Ananyev, Konstantin" Thread-Topic: [dpdk-dev] [PATCH 02/12] Add atomic operations for IBM Power architecture Thread-Index: AQHP6NnFnYBr4Dq34UaRJ6vZiHy30pwx/AEAgAB778A= Date: Thu, 16 Oct 2014 09:42:46 +0000 Message-ID: <59AF69C657FD0841A61C55336867B5B03441F561@IRSMSX103.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> In-Reply-To: Accept-Language: en-GB, 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 09:35:30 -0000 > -----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 Power > architecture >=20 > Konstantin, >=20 > In my understanding, compiler barrier is a kind of software barrier which > prevents the compiler from moving memory accesses across the barrier. Thi= s > 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. >=20 I would agree with that assessment, as far as it goes, in that a compiler b= arrier 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 co= mpiler barrier on IA?=20 My suggestion would be to do first as you propose and have proper primitive= s for the different barrier types defined correctly for each platform - wit= h 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 wo= uld be different across platforms. 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