[dpdk-dev] [PATCH 1/7] Split atomic operations to architecture specific

Neil Horman nhorman at tuxdriver.com
Mon Sep 29 17:24:09 CEST 2014


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 at 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
> 
> 


More information about the dev mailing list