From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from e23smtp01.au.ibm.com (e23smtp01.au.ibm.com [202.81.31.143]) by dpdk.org (Postfix) with ESMTP id B24887E72 for ; Thu, 16 Oct 2014 05:07:28 +0200 (CEST) Received: from /spool/local by e23smtp01.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 16 Oct 2014 13:15:18 +1000 Received: from d23dlp03.au.ibm.com (202.81.31.214) by e23smtp01.au.ibm.com (202.81.31.207) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 16 Oct 2014 13:15:16 +1000 Received: from d23relay06.au.ibm.com (d23relay06.au.ibm.com [9.185.63.219]) by d23dlp03.au.ibm.com (Postfix) with ESMTP id 516143578047 for ; Thu, 16 Oct 2014 14:15:16 +1100 (EST) Received: from d23av05.au.ibm.com (d23av05.au.ibm.com [9.190.234.119]) by d23relay06.au.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id s9G3FDs434996342 for ; Thu, 16 Oct 2014 14:15:13 +1100 Received: from d23av05.au.ibm.com (localhost [127.0.0.1]) by d23av05.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s9G3FGSq008538 for ; Thu, 16 Oct 2014 14:15:16 +1100 Received: from d23ml028.cn.ibm.com (d23ml028.cn.ibm.com [9.119.32.184]) by d23av05.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id s9G3F9SU008426 for ; Thu, 16 Oct 2014 14:15:15 +1100 In-Reply-To: <2601191342CEEE43887BDE71AB97725821393C8F@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> To: "Ananyev, Konstantin" MIME-Version: 1.0 X-KeepSent: CD69120A:E4F3D7D4-48257D73:0011507B; type=4; name=$KeepSent X-Mailer: IBM Notes Release 9.0.1SHF211 December 19, 2013 Message-ID: From: Chao CH Zhu Date: Thu, 16 Oct 2014 11:14:02 +0800 X-MIMETrack: Serialize by Router on d23ml028/23/M/IBM(Release 8.5.3FP6HF882 | August 28, 2014) at 10/16/2014 11:14:09, Serialize complete at 10/16/2014 11:14:09 X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14101603-1618-0000-0000-0000010CB1E1 Content-Type: text/plain; charset="US-ASCII" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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 03:07:30 -0000 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. Thanks a lot! Best Regards! ------------------------------ Chao Zhu From: "Ananyev, Konstantin" To: Chao CH Zhu/China/IBM@IBMCN, "dev@dpdk.org" Date: 2014/10/16 08:38 Subject: RE: [dpdk-dev] [PATCH 02/12] Add atomic operations for IBM Power architecture Hi, > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Chao Zhu > Sent: Friday, September 26, 2014 10:36 AM > To: dev@dpdk.org > Subject: [dpdk-dev] [PATCH 02/12] Add atomic operations for IBM Power architecture > > The atomic operations implemented with assembly code in DPDK only > support x86. This patch add architecture specific atomic operations for > IBM Power architecture. > > Signed-off-by: Chao Zhu > --- > .../common/include/powerpc/arch/rte_atomic.h | 387 ++++++++++++++++++++ > .../common/include/powerpc/arch/rte_atomic_arch.h | 318 ++++++++++++++++ > 2 files changed, 705 insertions(+), 0 deletions(-) > create mode 100644 lib/librte_eal/common/include/powerpc/arch/rte_atomic.h > create mode 100644 lib/librte_eal/common/include/powerpc/arch/rte_atomic_arch.h > ... > + > diff --git a/lib/librte_eal/common/include/powerpc/arch/rte_atomic_arch.h > b/lib/librte_eal/common/include/powerpc/arch/rte_atomic_arch.h > new file mode 100644 > index 0000000..fe5666e > --- /dev/null > + ... >+#define rte_arch_rmb() asm volatile("sync" : : : "memory") >+ > +#define rte_arch_compiler_barrier() do { \ > + asm volatile ("" : : : "memory"); \ > +} while(0) I don't know much about PPC architecture, but as I remember it uses a weakly-ordering memory model. Is that correct? If so, then you probably need rte_arch_compiler_barrier() to be "sync" instruction (like mb()s above) . The reason is that IA has much stronger memory ordering model and there are a lot of places in the code where it implies that ordering. For example - ring enqueue/dequeue functions. Konstantin