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

[Chao CH Zhu <bjzhuc@cn.ibm.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="GB2312", Size: 2289 bytes --]

Bruce and Neil,

Thanks for your comments! Actually, the compiler hides the difference with 
different architecture.
I'll submit another patch to correct this!


Best Regards!
------------------------------
Chao Zhu (×£³¬)
Research Staff Member
Cloud Infrastructure and Technology Group
IBM China Research Lab
Building 19 Zhongguancun Software Park
8 Dongbeiwang West Road, Haidian District,
Beijing, PRC. 100193
Tel: +86-10-58748711
Email: bjzhuc@cn.ibm.com




From:   Neil Horman <nhorman@tuxdriver.com>
To:     Bruce Richardson <bruce.richardson@intel.com>
Cc:     Chao CH Zhu/China/IBM@IBMCN, dev@dpdk.org
Date:   2014/09/29 23:23
Subject:        Re: [dpdk-dev] [PATCH 1/7] Split atomic operations to 
architecture specific



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



\x16º&†æ°z,bz)ízW(™;žIêwÓN7ãž6Ó^\x11zÛ«œö­†^[šÁ豉觵é\¢d^qè¯y×ë¢i kM¢ž×¥r‰¦­6Š{^•Ê&×~5ߍwëm^[ÉÚ]’Šà>‹-~,pŠØDHÄωÑvÛÎy÷MŸ¢·^½Ú]’ŠàNç·Ñ'©ÛMxӍøç\x7f´ÛM\x02\x11$ÑyÇ¢½ç_®‰šÎÉ kM5r\x18§µé\¢mtÛ^õõ¼¨®É k]5ø§µé\¢l"¶\x11\x1213öõ'©ÛMx×Þ5ß];ÓEÄÆÒ袝u\Šèœú+´\x05D