DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Gonzalez Monroy, Sergio" <sergio.gonzalez.monroy@intel.com>
To: Matthew Hall <mhall@mhcomputing.net>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH RFC] Update/Improve build system
Date: Fri, 31 Oct 2014 10:45:07 +0000
Message-ID: <91383E96CE459D47BCE92EFBF5CE73B004E9AAFB@IRSMSX108.ger.corp.intel.com> (raw)
In-Reply-To: <20141030205000.GA9956@mhcomputing.net>

> From: Matthew Hall [mailto:mhall@mhcomputing.net]
> Sent: Thursday, October 30, 2014 8:50 PM
> On Thu, Oct 30, 2014 at 09:18:23AM +0000, Gonzalez Monroy, Sergio wrote:
> > I would say that D) is a good balance, although not being the simplest.
> A, or D. Depending on things such as, "If you run the DPDK on Random
> Platform X," where X could be something like Power CPUs or other weird
> stuff, will all of the things needed for the Combined Lib 1) be compilable, 2)
> be able to load w/o errors.
> For example, I could see probe ctor functions from various PMD's blowing up
> on unsupported hardware. Like how the rte_pmd_virtio had issues when I
> tried it on my VM system.
IMHO the underlying issue was that virtio was unsupported for that platform.
What I am trying to say is that any app built against a combined shared lib or combined/separated 
static lib will have that same issue if the feature/PMD is unsupported for the platform.
In the virtio case, building against combined shared or combined/separated static DPDK libs
would have the same result because the virtio PMD would be in the app.

> If we think we can make sure no platform specific stuff breaks when it ends
> up in Combined Lib A then A is probably the easiest for all.
I agree, a combined lib would simplify all app/lib linking, making it easier for the user and less error prone.

One of the downsides that comes to mind is a flow work (I think you mentioned it) where you
have multiple apps building against a single DPDK copy, and each app uses different features/PMDs.
In that scenario, having separated libs would make your life easier as you would not need to  have
multiple DPDK copies customized for each app, giving you the flexibility to hand pick each lib you
want to include into your app.
That flow work still presents some issues as they may be features that are incompatible between
each other and would need to be in different DPDK copies.


> Matthew.

  reply	other threads:[~2014-10-31 10:36 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
2014-10-30 20:50 ` Matthew Hall
2014-10-31 10:45   ` Gonzalez Monroy, Sergio [this message]
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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=91383E96CE459D47BCE92EFBF5CE73B004E9AAFB@IRSMSX108.ger.corp.intel.com \
    --to=sergio.gonzalez.monroy@intel.com \
    --cc=dev@dpdk.org \
    --cc=mhall@mhcomputing.net \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

DPDK patches and discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.dpdk.org/dev/0 dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dev dev/ https://inbox.dpdk.org/dev \
	public-inbox-index dev

Example config snippet for mirrors.
Newsgroup available over NNTP:

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git