DPDK patches and discussions
 help / color / mirror / Atom feed
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] Update/Improve build system
Date: Sat, 1 Nov 2014 08:53:36 -0400
Message-ID: <20141101125336.GA9971@localhost.localdomain> (raw)
In-Reply-To: <91383E96CE459D47BCE92EFBF5CE73B004E9AAFB@IRSMSX108.ger.corp.intel.com>

On Fri, Oct 31, 2014 at 10:45:07AM +0000, Gonzalez Monroy, Sergio wrote:
> > 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.
> 
It might be reasonable here to consider pmd's separately from the rest of the
system, given that, they are supposed be built as isolated libraries that don't
export any symbols.  Some pmd's break that assumption, but they should really be
fixed anyway.  If you did that, you can build the dpdk as a single library, and
build the pmds as separate libraries (shared or static).

Neil

> Regards,
> Sergio
> 
> > Matthew.
> 

      parent reply	other threads:[~2014-11-01 12: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
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 [this message]

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=20141101125336.GA9971@localhost.localdomain \
    --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

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 \
		dev@dpdk.org
	public-inbox-index dev

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.dev


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