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.richard...@intel.com>
To: David Marchand <david.marchand at 6wind.com>
Cc: Chao CH Zhu/China/IBM at IBMCN, "dev at dpdk.org" <dev at dpdk.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 at 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
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
