From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <nhorman@tuxdriver.com>
Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58])
 by dpdk.org (Postfix) with ESMTP id 5BC796A9B
 for <dev@dpdk.org>; Mon, 29 Sep 2014 17:17:41 +0200 (CEST)
Received: from hmsreliant.think-freely.org
 ([2001:470:8:a08:7aac:c0ff:fec2:933b] helo=localhost)
 by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63)
 (envelope-from <nhorman@tuxdriver.com>)
 id 1XYco6-0004aj-De; Mon, 29 Sep 2014 11:24:12 -0400
Date: Mon, 29 Sep 2014 11:24:09 -0400
From: Neil Horman <nhorman@tuxdriver.com>
To: Bruce Richardson <bruce.richardson@intel.com>
Message-ID: <20140929152409.GF26483@hmsreliant.think-freely.org>
References: <1411724018-7738-1-git-send-email-bjzhuc@cn.ibm.com>
 <1411724018-7738-2-git-send-email-bjzhuc@cn.ibm.com>
 <20140929110522.GF12072@BRICHA3-MOBL>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140929110522.GF12072@BRICHA3-MOBL>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Spam-Score: -2.9 (--)
X-Spam-Status: No
Cc: dev@dpdk.org, Chao Zhu <bjzhuc@cn.ibm.com>
Subject: Re: [dpdk-dev] [PATCH 1/7] Split atomic operations to architecture
 specific
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Sep 2014 15:17:41 -0000

On Mon, Sep 29, 2014 at 12:05:22PM +0100, Bruce Richardson wrote:
> On Fri, Sep 26, 2014 at 05:33:32AM -0400, Chao Zhu wrote:
> > This patch splits the atomic operations from DPDK and push them to
> > architecture specific arch directories, so that other processor
> > architecture to support DPDK can be easily adopted.
> > 
> > Signed-off-by: Chao Zhu <bjzhuc@cn.ibm.com>
> > ---
> >  lib/librte_eal/common/Makefile                     |    2 +-
> >  .../common/include/i686/arch/rte_atomic_arch.h     |  378 ++++++++++++++++++++
> >  lib/librte_eal/common/include/rte_atomic.h         |  172 +--------
> >  .../common/include/x86_64/arch/rte_atomic_arch.h   |  378 ++++++++++++++++++++
> >  4 files changed, 772 insertions(+), 158 deletions(-)
> >  create mode 100644 lib/librte_eal/common/include/i686/arch/rte_atomic_arch.h
> >  create mode 100644 lib/librte_eal/common/include/x86_64/arch/rte_atomic_arch.h
> > 
> <...snip...>
> > +#define	rte_compiler_barrier() rte_arch_compiler_barrier()
> 
> Small question: shouldn't the compiler barrier be independent of 
> architecture?
> 
Agreed, compiler intrinsics I thought were used to define barriers, regardless
of arch (__memory_barrier() is the gcc intrinsic IIRC)
Neil

> /Bruce
> 
>