From: Neil Horman <nhorman@tuxdriver.com>
To: "Gonzalez Monroy, Sergio" <sergio.gonzalez.monroy@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH RFC 00/13] Update build system
Date: Mon, 12 Jan 2015 13:16:02 -0500 [thread overview]
Message-ID: <20150112181602.GD23467@hmsreliant.think-freely.org> (raw)
In-Reply-To: <91383E96CE459D47BCE92EFBF5CE73B004F26FD1@IRSMSX108.ger.corp.intel.com>
On Mon, Jan 12, 2015 at 05:21:48PM +0000, Gonzalez Monroy, Sergio wrote:
> Hi Thomas,
>
> > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > Sent: Monday, January 12, 2015 4:52 PM
> >
> > Hi Sergio,
> >
> > 2015-01-12 16:33, Sergio Gonzalez Monroy:
> > > This patch series updates the DPDK build system.
> >
> > Thanks for proposing such rework.
> > We need discussions on that topic. So I ask some questions below.
> >
> > > Following are the goals it tries to accomplish:
> > > - Create a library containing core DPDK libraries (librte_eal,
> > > librte_malloc, librte_mempool, librte_mbuf and librte_ring).
> > > The idea of core libraries is to group those libraries that are
> > > always required for any DPDK application.
> >
> > How is it better? Is it only to reduce dependencies lines?
> >
> In my opinion I think that there are a set of libraries that are always required
> and therefore should be grouped as a single one.
> Basically all apps and other DPDK libs would have dependencies to these core libraries.
>
> Aside from that, I don't think there is any difference. Note that this affects shared libraries,
> with no difference for apps linked against static libs.
>
> > > - Remove config option to build a combined library.
> >
> > Why removing combined library? Is there people finding it helpful?
> >
> I don't think it makes sense from a shared library point of view, maybe it does for static?
> For example, in the case of shared libraries I think we want to try to avoid the case where
> we have an app linked against librte_dpdk.so, but such library may contain different libraries
> depending on the options that were enabled when the lib was built.
>
> The core libraries would be that set of libraries that are always required for an app, and its content
> would be fixed regardless of the option libraries (like acl, hash, distributor, etc.)
> We could add more libraries as core if we think it is a better solution, but the goal should be that
> librte_core.so contains the same libraries/API regardless of the system/arch.
>
FWIW, I think Sergios approach is likely a good balance. As he notes, mempool,
eal, malloc and mbuf are needed for any dpdk application, and have
interdepedencies, so it makes sense to link them as a single library.
Everything else is optional. For static libraries, you can just add a few extra
lines to the linker, but for DSO's you might want the option of not linking
against a PMD, option to dynamically load it via the dlopen interface (using the
-d option). Theres not much sense in adding those PMD DSO's to a single library
just to save a few lines in the makefile there. This approach strikes a good
balance, combining items that will have to be linked together anyway, and
leaving everying else separate.
Neil
next prev parent reply other threads:[~2015-01-12 18:16 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-12 16:33 Sergio Gonzalez Monroy
2015-01-12 16:33 ` [dpdk-dev] [PATCH RFC 01/13] mk: Remove combined library and related options Sergio Gonzalez Monroy
2015-01-12 16:33 ` [dpdk-dev] [PATCH RFC 02/13] lib/core: create new core dir and makefiles Sergio Gonzalez Monroy
2015-01-12 16:33 ` [dpdk-dev] [PATCH RFC 03/13] core: move librte_eal to core subdir Sergio Gonzalez Monroy
2015-01-12 16:33 ` [dpdk-dev] [PATCH RFC 04/13] core: move librte_malloc " Sergio Gonzalez Monroy
2015-01-12 16:33 ` [dpdk-dev] [PATCH RFC 05/13] core: move librte_mempool " Sergio Gonzalez Monroy
2015-01-12 16:33 ` [dpdk-dev] [PATCH RFC 06/13] core: move librte_mbuf " Sergio Gonzalez Monroy
2015-01-12 16:34 ` [dpdk-dev] [PATCH RFC 07/13] core: move librte_ring " Sergio Gonzalez Monroy
2015-01-12 16:34 ` [dpdk-dev] [PATCH RFC 08/13] Update path of core libraries Sergio Gonzalez Monroy
2015-01-12 16:34 ` [dpdk-dev] [PATCH RFC 09/13] mk: new corelib makefile Sergio Gonzalez Monroy
2015-01-12 16:34 ` [dpdk-dev] [PATCH RFC 10/13] lib: Set LDLIBS for each library Sergio Gonzalez Monroy
2015-01-12 16:34 ` [dpdk-dev] [PATCH RFC 11/13] mk: Use LDLIBS when linking shared libraries Sergio Gonzalez Monroy
2015-01-12 16:34 ` [dpdk-dev] [PATCH RFC 12/13] mk: update apps build Sergio Gonzalez Monroy
2015-01-12 16:34 ` [dpdk-dev] [PATCH RFC 13/13] mk: add -lpthread to linuxapp EXECENV_LDLIBS Sergio Gonzalez Monroy
2015-01-12 16:51 ` [dpdk-dev] [PATCH RFC 00/13] Update build system Thomas Monjalon
2015-01-12 17:21 ` Gonzalez Monroy, Sergio
2015-01-12 18:16 ` Neil Horman [this message]
2015-01-22 10:03 ` Gonzalez Monroy, Sergio
2015-01-22 10:38 ` Thomas Monjalon
2015-01-22 11:01 ` Gonzalez Monroy, Sergio
2015-01-13 12:26 ` Neil Horman
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=20150112181602.GD23467@hmsreliant.think-freely.org \
--to=nhorman@tuxdriver.com \
--cc=dev@dpdk.org \
--cc=sergio.gonzalez.monroy@intel.com \
/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).