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
next prev 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).