From: Chao CH Zhu <bjzhuc-vtt25B2cwJLQT0dZR+AlfA@public.gmane.org>
To: David Marchand <david.marchand-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
Cc: "dev-VfR2kkLFssw@public.gmane.org" <dev-VfR2kkLFssw@public.gmane.org>
Subject: Re: [PATCH 0/7] Patches to split architecture specific operations from DPDK
Date: Sun, 12 Oct 2014 17:39:52 +0800 [thread overview]
Message-ID: <OF57B67AA2.AC35A32C-ON48257D6F.0032FDC7-48257D6F.00353728@cn.ibm.com> (raw)
In-Reply-To: <20141003132917.GA10112@BRICHA3-MOBL>
David,
I agree that your idea may be better for the splitting. However, as Bruce
said, I think people would like to see the multi-architecture support
feature of DPDK first. We can improve it gradually. Do you have some
comments?
Best Regards!
------------------------------
Chao Zhu
From: Bruce Richardson <bruce.richardson-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
To: David Marchand <david.marchand-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
Cc: Chao CH Zhu/China/IBM@IBMCN, "dev-VfR2kkLFssw@public.gmane.org" <dev-VfR2kkLFssw@public.gmane.org>
Date: 2014/10/03 21:28
Subject: Re: [dpdk-dev] [PATCH 0/7] Patches to split architecture
specific operations from DPDK
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 <bjzhuc-vtt25B2cwJLQT0dZR+AlfA@public.gmane.org> 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
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
next prev parent reply other threads:[~2014-10-12 9:39 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-26 9:33 [PATCH 0/7] Patches to split architecture specific operations from DPDK Chao Zhu
[not found] ` <1411724018-7738-1-git-send-email-bjzhuc-vtt25B2cwJLQT0dZR+AlfA@public.gmane.org>
2014-09-26 9:33 ` [PATCH 1/7] Split atomic operations to architecture specific Chao Zhu
[not found] ` <1411724018-7738-2-git-send-email-bjzhuc-vtt25B2cwJLQT0dZR+AlfA@public.gmane.org>
2014-09-29 11:05 ` Bruce Richardson
2014-09-29 15:24 ` Neil Horman
[not found] ` <20140929152409.GF26483-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org>
2014-09-30 2:18 ` Chao CH Zhu
2014-09-26 9:33 ` [PATCH 2/7] Split byte order " Chao Zhu
2014-09-26 9:33 ` [PATCH 3/7] Split CPU cycle operation " Chao Zhu
2014-09-26 9:33 ` [PATCH 4/7] Split prefetch operations " Chao Zhu
2014-09-26 9:33 ` [PATCH 5/7] Split spinlock " Chao Zhu
2014-09-26 9:33 ` [PATCH 6/7] Split memcpy operation " Chao Zhu
2014-09-26 9:33 ` [PATCH 7/7] Split CPU flags operations " Chao Zhu
2014-10-03 13:21 ` [PATCH 0/7] Patches to split architecture specific operations from DPDK David Marchand
[not found] ` <CALwxeUtKuc-rN_BmuxEtOWB6E=3EryG45GPgXnRgh4X+Ci_fPw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-10-03 13:29 ` Bruce Richardson
2014-10-12 9:39 ` Chao CH Zhu [this message]
2014-10-13 2:36 ` Chao CH Zhu
2014-10-06 21:46 ` Cyril Chemparathy
[not found] ` <54330D9A.3080003-kv+TWInifGbQT0dZR+AlfA@public.gmane.org>
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=OF57B67AA2.AC35A32C-ON48257D6F.0032FDC7-48257D6F.00353728@cn.ibm.com \
--to=bjzhuc-vtt25b2cwjlqt0dzr+alfa@public.gmane.org \
--cc=david.marchand-pdR9zngts4EAvxtiuMwx3w@public.gmane.org \
--cc=dev-VfR2kkLFssw@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.