DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ray Kinsella <mdr@ashroe.eu>
To: Thomas Monjalon <thomas@monjalon.net>, techboard@dpdk.org
Cc: Bruce Richardson <bruce.richardson@intel.com>,
	Billy McFall <bmcfall@redhat.com>,
	Thomas F Herbert <therbert@redhat.com>, dpdk-dev <dev@dpdk.org>,
	Luca Boccassi <luca.boccassi@gmail.com>,
	ndas@suse.de,
	Christian Ehrhardt <christian.ehrhardt@canonical.com>,
	"Stokes, Ian" <ian.stokes@intel.com>
Subject: Re: [dpdk-dev] [dpdk-techboard] Discussion on the OS Packaging of DPDK
Date: Tue, 14 May 2019 10:41:50 +0100	[thread overview]
Message-ID: <8aa77d10-54c1-4f09-102d-23714f59d65c@ashroe.eu> (raw)
Message-ID: <20190514094150.ckLrYi7g-S6Y30I7B8WVgDonEITbY0_aVefwdhN1X-0@z> (raw)
In-Reply-To: <2098214.X7U14xP0QZ@xps>



On 10/05/2019 19:43, Thomas Monjalon wrote:
> 10/05/2019 15:43, Bruce Richardson:
>> On Fri, May 10, 2019 at 02:01:54PM +0100, Ray Kinsella wrote:
>>> ( from the undersigned )
>>>
<SNIP>
>> To a certain extent, this only applies with the "make" build system, which
>> is due to be deprecated in the next release and removed sometime next year.
>> With builds done with meson and ninja, both shared and static libraries are
>> always built. The default setting though remains as "static" which applies
>> only to the linking of applications as part of the DPDK build. This default
>> was set mainly for legacy purposes, but also has benefits for us developers
>> working on DPDK, since we don't need to worry about setting LD_LIBRARY_PATH
>> and EAL_PMD_PATH values for running applications we've built. Therefore,
>> I'm not sure of the value of changing the default here - it's certainly
>> less important than the default in the "make" build system where only one
>> library type at a time was built.
> 
> Yes no need to change the default.
> If you build DPDK yourself, it is more convenient to use static libs.
> If you want something easier to update, you probably use
> the packages from distributions which are shared libraries.

Well I disagree a bit.
I understand 100% that we don't want to break the developer experience.
My concern is that developers end using something different then, that
what the DPDK consumers are using - this always ends up being a hiding
place for bugs.

It might be worthwhile seeing if we could resolve this in another way,
either with RPATH or EAL_PMD_PATH change.

> 
>>> * Future guarantees around ABI/API stability should be provided, so that
>>> OS packagers can offer safe upgrade paths for consuming applications.
> 
> DPDK is a set of libraries, some more stable than others.
> If we cannot guarantee a full stability for a long time,
> we may have some changes here and there sometimes.
> And it's even worst with experimental functions.
> I think it is more realistic to provide a level of stability
> per DPDK library. In order to leverage such fine grained stability,
> the libraries should be packaged separately in the OS.
> Then the applications relying only on stable libraries will be able
> to link with updated libraries without any change or re-compilation.
> 
> 
> 

  parent reply	other threads:[~2019-05-14  9:42 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-10 13:01 [dpdk-dev] " Ray Kinsella
2019-05-10 13:01 ` Ray Kinsella
2019-05-10 13:43 ` [dpdk-dev] [dpdk-techboard] " Bruce Richardson
2019-05-10 13:43   ` Bruce Richardson
2019-05-10 18:43   ` Thomas Monjalon
2019-05-10 18:43     ` Thomas Monjalon
2019-05-13  7:15     ` Christian Ehrhardt
2019-05-13  7:15       ` Christian Ehrhardt
2019-05-14  9:41     ` Ray Kinsella [this message]
2019-05-14  9:41       ` Ray Kinsella

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=8aa77d10-54c1-4f09-102d-23714f59d65c@ashroe.eu \
    --to=mdr@ashroe.eu \
    --cc=bmcfall@redhat.com \
    --cc=bruce.richardson@intel.com \
    --cc=christian.ehrhardt@canonical.com \
    --cc=dev@dpdk.org \
    --cc=ian.stokes@intel.com \
    --cc=luca.boccassi@gmail.com \
    --cc=ndas@suse.de \
    --cc=techboard@dpdk.org \
    --cc=therbert@redhat.com \
    --cc=thomas@monjalon.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).