From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 66850E82 for ; Fri, 3 Oct 2014 15:22:48 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga103.jf.intel.com with ESMTP; 03 Oct 2014 06:27:18 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.04,647,1406617200"; d="scan'208";a="612684256" Received: from bricha3-mobl.ger.corp.intel.com (HELO bricha3-mobl.ir.intel.com) ([10.243.20.24]) by orsmga002.jf.intel.com with SMTP; 03 Oct 2014 06:29:18 -0700 Received: by bricha3-mobl.ir.intel.com (sSMTP sendmail emulation); Fri, 03 Oct 2014 14:29:17 +0001 Date: Fri, 3 Oct 2014 14:29:17 +0100 From: Bruce Richardson To: David Marchand Message-ID: <20141003132917.GA10112@BRICHA3-MOBL> References: <1411724018-7738-1-git-send-email-bjzhuc@cn.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Shannon Ltd. User-Agent: Mutt/1.5.22 (2013-10-16) Cc: "dev@dpdk.org" , Chao Zhu Subject: Re: [dpdk-dev] [PATCH 0/7] Patches to split architecture specific operations from DPDK 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: Fri, 03 Oct 2014 13:22:49 -0000 On Fri, Oct 03, 2014 at 03:21:53PM +0200, David Marchand wrote: > Hello Chao, > > On Fri, Sep 26, 2014 at 11:33 AM, Chao Zhu wrote: > > > The set of patches split x86 architecture specific operations from DPDK > > and put them to the > > arch directories of i686 and x86_64 architecture. This will make the > > adpotion of DPDK much easier > > on other computer architecture. For a new architecture, just add an > > architecture specific > > directory and necessary building configuration files, then DPDK can > > support it. > > > > > Here is a different approach for the headers splitting. > > If we are going to support multiple architectures, the best would be to > have a specific header for each arch which implements a common API (no need > for any _arch suffix). > These headers would be located in lib/librte_eal/common/include/arch/$arch/ > rather than lib/librte_eal/common/include/$arch/arch/ (which looks odd to > me). > Makefiles can add some -I for dpdk to build itself (and we can remove those > symlinks from the makefiles). > Makefiles only install the specific headers in RTE_SDK/include for use by > applications. > > For common code and documentation, we can add a "generic" directory in > lib/librte_eal/common/include (or "arch-generic", or "shared" ... any > better idea ?). > DPDK makefiles installs the generic headers in RTE_SDK/include/generic. > arch headers (like rte_atomic.h) include the generic one > (). > > These generic headers can be implemented using compiler intrinsics when > possible. > They also include the doxygen stuff in a single place. > > > This would look like something like this, for rte_atomic.h : > - in DPDK sources > $ ls lib/librte_eal/common/include/*/rte_atomic.h > lib/librte_eal/common/include/i686/rte_atomic.h > lib/librte_eal/common/include/x86_64/rte_atomic.h > lib/librte_eal/common/include/generic/rte_atomic.h > > - in installed RTE_SDK > $ ls RTE_SDK/include/{,*/}rte_atomic.h > RTE_SDK/include/rte_atomic.h > RTE_SDK/include/generic/rte_atomic.h > > Comments ? > > > I am only focusing on the first patchset at the moment, but if we can find > consensus here, a respin of the two patchsets would be great. > > Thanks. > > -- > David Marchand I would have no objection to such a scheme. However, I'm not seeing much advantage over the existing way of doing things. I think I'd rather see the proposed patch sets merged first and then any additional cleanup done, rather than holding up a worthwhile submission for a bit of tidy-up. /Bruce