DPDK patches and discussions
 help / color / mirror / Atom feed
From: Chao CH Zhu <bjzhuc@cn.ibm.com>
To: David Marchand <david.marchand@6wind.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH 0/7] Patches to split architecture specific operations from DPDK
Date: Mon, 13 Oct 2014 10:36:41 +0800	[thread overview]
Message-ID: <OF3B41D047.186FED13-ON48257D70.000E42BD-48257D70.000E795F@cn.ibm.com> (raw)
In-Reply-To: <CALwxeUtKuc-rN_BmuxEtOWB6E=3EryG45GPgXnRgh4X+Ci_fPw@mail.gmail.com>

David,

I'll update the patches acccording to your comments. 
Thanks!

Best Regards!
------------------------------
Chao Zhu 



From:   David Marchand <david.marchand@6wind.com>
To:     Chao CH Zhu/China/IBM@IBMCN
Cc:     "dev@dpdk.org" <dev@dpdk.org>
Date:   2014/10/03 21:21
Subject:        Re: [dpdk-dev] [PATCH 0/7] Patches to split architecture 
specific operations from DPDK



Hello Chao, 

On Fri, Sep 26, 2014 at 11:33 AM, Chao Zhu <bjzhuc@cn.ibm.com> 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 
(<generic/rte_atomic.h>).

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

  parent reply	other threads:[~2014-10-13  2:30 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-26  9:33 Chao Zhu
2014-09-26  9:33 ` [dpdk-dev] [PATCH 1/7] Split atomic operations to architecture specific Chao Zhu
2014-09-29 11:05   ` Bruce Richardson
2014-09-29 15:24     ` Neil Horman
2014-09-30  2:18       ` Chao CH Zhu
2014-09-26  9:33 ` [dpdk-dev] [PATCH 2/7] Split byte order " Chao Zhu
2014-09-26  9:33 ` [dpdk-dev] [PATCH 3/7] Split CPU cycle operation " Chao Zhu
2014-09-26  9:33 ` [dpdk-dev] [PATCH 4/7] Split prefetch operations " Chao Zhu
2014-09-26  9:33 ` [dpdk-dev] [PATCH 5/7] Split spinlock " Chao Zhu
2014-09-26  9:33 ` [dpdk-dev] [PATCH 6/7] Split memcpy operation " Chao Zhu
2014-09-26  9:33 ` [dpdk-dev] [PATCH 7/7] Split CPU flags operations " Chao Zhu
2014-10-03 13:21 ` [dpdk-dev] [PATCH 0/7] Patches to split architecture specific operations from DPDK David Marchand
2014-10-03 13:29   ` Bruce Richardson
2014-10-13  2:36   ` Chao CH Zhu [this message]
2014-10-06 21:46 ` Cyril Chemparathy
2014-10-12  9:14   ` Chao CH Zhu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=OF3B41D047.186FED13-ON48257D70.000E42BD-48257D70.000E795F@cn.ibm.com \
    --to=bjzhuc@cn.ibm.com \
    --cc=david.marchand@6wind.com \
    --cc=dev@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).