DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Gonzalez Monroy, Sergio" <sergio.gonzalez.monroy@intel.com>
To: "Gonzalez Monroy, Sergio" <sergio.gonzalez.monroy@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH RFC] Update/Improve build system
Date: Thu, 30 Oct 2014 11:53:18 +0000	[thread overview]
Message-ID: <91383E96CE459D47BCE92EFBF5CE73B004E9A155@IRSMSX108.ger.corp.intel.com> (raw)
In-Reply-To: <91383E96CE459D47BCE92EFBF5CE73B004E97FFB@IRSMSX108.ger.corp.intel.com>

Hi,

Apologies for the previous email format, I seems like I misconfigured something on my email-client.
In case people find it annoying to read with extra line spaces, here is the RFC with fixed formatting:


I would like to propose an update on the way the libraries are being built on DPDK.

Motivation/Issues:
- No agreement on libraries to build (separated, combined, different grouping).
- People having issues building their applications cannot rely on the information given by ldd when using shared libraries because currently we are not building against dependent libraries.
- External library dependencies are introduce in multiple places (ie. when building librte_vhost, -lfuse is added into the lib CFLAGS, LDFLAGS and also need to update rte.app.mk).
- Do we want to keep support for building shared libraries using LD? Currently unused as both Linux and BSD enable linking using CC.

Proposal:
- Define external lib dependencies per module/lib/dir. ie. EXT_DEP_LIBS = -lfuse -lm
- Define internal lib dependencies per module/lib/dir. ie. DPDK_DEP_LIBS = -lrte_eal
- Remove compile config option CONFIG_RTE_BUILD_COMBINE_LIBS and always build all wanted libraries (see below about different libraries to build).
- Shared linking: we want to link apps and libs against dependant libraries. Basically add EXT_DEP_LIBS and DPDK_DEP_LIBS when linking libs and apps.
- Static linking: we want to link apps against dependant libraries.

>From my point of view, we can classify DPDK libraries into three categories (note that not all libraries are included and the following is just for illustration purposes):
CORE_LIBS: librte_kvargs, librte_mbuf, librte_malloc, librte_mempool, librte_ring, librte_eal, libethdev?
NON_CORE_LIBS: librte_vhost, librte_cfgfile, librte_cmdline, librte_sched, librte_lpm, librte_acl, ...
PMD_LIBS: librte_pmd_i40e, librte_pmd_e1000, librte_ixgbe, ...

IMHO CORE_LIBS are a set of libraries that have inter-dependencies and are always required to build an application. Such set of core libraries should be provided as a single library.
I can think of a few different ways to go about this:
A) Build just one combined library for static or shared libraries.
     Pros: it would reduce and simplify makefile rules, as well as make it easier for users to build their own apps against DPDK.
     Cons: limited flexibility when building custom apps with selected libraries.     Link apps with something like:
                --whole-archive -ldpdk --no-whole-archive --as-needed $(EXT_DEP_LIBS) --no-as-needed
B) Build CORE_LIBS (as a single lib, librte_core), NON_CORE_LIBS and PMD_LIBS:
     Pros: flexibility.
     Cons: more complex build process, as we would add dependencies for each NON_CORE_LIB and PMD_LIB.     Link apps with something like:
                --whole-archive $(PMD_LIBS) --no-whole-archive $(NON_CORE_LIBS) -lrte_core --as-needed $(EXT_DEP_LIBS) --no-as-needed
C) Similar to B but building a single library containing both CORE_LIBS and NON_CORE_LIBS.
     Link apps with something like:
                --whole-archive $(PMD_LIBS) --no-whole-archive -lrte_xxxx --as-needed $(EXT_DEP_LIBS) --no-as-needed
D) Build all libs in both A) and B) but linking DPDK provided apps only against combined lib for slightly simpler makefile rules.

I would say that D) is a good balance, although not being the simplest.

Thoughts?

Thanks,
Sergio

  reply	other threads:[~2014-10-30 11:44 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-30  9:18 Gonzalez Monroy, Sergio
2014-10-30 11:53 ` Gonzalez Monroy, Sergio [this message]
2014-10-30 20:50 ` Matthew Hall
2014-10-31 10:45   ` Gonzalez Monroy, Sergio
2014-10-31 22:33     ` Matthew Hall
2014-11-01 12:53     ` 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=91383E96CE459D47BCE92EFBF5CE73B004E9A155@IRSMSX108.ger.corp.intel.com \
    --to=sergio.gonzalez.monroy@intel.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).