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 [thread overview]
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.
Regards,
Sergio
> Matthew.
next prev parent 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:
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=91383E96CE459D47BCE92EFBF5CE73B004E9AAFB@IRSMSX108.ger.corp.intel.com \
--to=sergio.gonzalez.monroy@intel.com \
--cc=dev@dpdk.org \
--cc=mhall@mhcomputing.net \
/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).