DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ray Kinsella <mdr@ashroe.eu>
To: "techboard@dpdk.org" <techboard@dpdk.org>,
	Billy McFall <bmcfall@redhat.com>,
	Thomas F Herbert <therbert@redhat.com>
Cc: 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: [dpdk-dev] Discussion on the OS Packaging of DPDK
Date: Fri, 10 May 2019 14:01:54 +0100	[thread overview]
Message-ID: <80c4f1df-da68-520e-d47d-b4ccaeedb69f@ashroe.eu> (raw)

( from the undersigned )

Hi folks,

In light of the renewed community discussion on API Stability
(https://mails.dpdk.org/archives/dev/2019-April/128969.html), now is
right time to open a discussion on how DPDK is distributed and updated.

To this point in time, DPDK's primary distribution method has been as
source code distributed as a tarball from dpdk.org. This distribution
method, in addition to abi instability and the dpdk's build system
default behaviour of static linking have all encouraged the "tight
coupling" or "vendorization" of DPDK.

These behaviours makes it a challenge for end users, those deploying
applications based on DPDK, to manage and update DPDK in a method
consistent with other system libraries. For instance, an end user may
not have any idea which version of DPDK a consuming application may be
using and if this DPDK version is reasonably up to date with the latest
upstream version. This would not be the case for other system libraries
such as glibc.

For these reasons, now is the right time for DPDK to embrace standard
Operating System practices for distributing and updating system
libraries. The current industry push towards cloud and
cloud-friendliness make addressing this issue all the more timely.

To this end, the following proposals are made for discussion at the next
techboard meeting:-

* The primary method of distributing DPDK should be as an operating
system package, dpdk.org should be updated to reflect this reality and
provide OS installation details in place of tarball downloads.

* DPDK should build as a dynamic shared libraries by default, to
encourage loose coupling with consuming applications.

* Future guarantees around ABI/API stability should be provided, so that
OS packagers can offer safe upgrade paths for consuming applications.

Look forward to the discussion, thank you,

Luca Boccassi, Debian maintainer and DPDK LTS maintainer
Nirmoy Das, SUSE dpdk maintainer
Christian Ehrhardt, Ubuntu maintainer and former DPDK LTS maintainer
Ian Stokes, Open vSwitch maintainer
Tom Herbert, FD.io/VPP contributor. CentOS NFV SIG chair.
Billy McFall, DPDK consumer and FD.io/VPP Contributor
Ray Kinsella, DPDK and FD.io Contributor

             reply	other threads:[~2019-05-10 13:02 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-10 13:01 Ray Kinsella [this message]
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
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=80c4f1df-da68-520e-d47d-b4ccaeedb69f@ashroe.eu \
    --to=mdr@ashroe.eu \
    --cc=bmcfall@redhat.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 \
    /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).