DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ray Kinsella <mdr@ashroe.eu>
To: dev@dpdk.org, Kevin Traynor <ktraynor@redhat.com>,
	"techboard@dpdk.org" <techboard@dpdk.org>
Subject: [dpdk-dev] DPDK ABI/API Stability
Date: Wed, 3 Apr 2019 16:42:16 +0100	[thread overview]
Message-ID: <c0856556-a42e-d0cf-6a01-6279643c8089@ashroe.eu> (raw)
Message-ID: <20190403154216.XaXFGv5qwP8_UZpTrUIl3mAwy4_onYGLv560mxiQlG8@z> (raw)

Hi folks,

Recently I started a discussion with the DPDK Technical Board on DPDK
ABI/API stability. This was born out informal feedback I had received
from a number of users of DPDK about ABI churn. In turn this feedback
then prompted an ABI analysis of DPDK using tools from abi-laboratory.

https://abi-laboratory.pro/index.php?view=timeline&l=dpdk

I guess the short story is that DPDK ABI hasn't really settled down as
the project has matured. If you take a look at the “Backward Compat.”
column which measures ABI compatibility compared to the previous
releases, you will see significant churn in the ABI over successive
releases since v16.04.

Now compare DPDK to GStreamer as an example of a very mature project
with a similar intent, a framework for building applications, and which
enjoys a very stable API.

https://abi-laboratory.pro/index.php?view=timeline&l=gstreamer

The DPDK ABI churn has the following affects for users:-

1. The churn obliges users of DPDK to commit to a constant
re-integration and re-validation effort for new versions of DPDK. This
effort from their perspective may not add value to their consuming
project, particular if they are only updating to "stay current".
2. The churn encourages users of DPDK to slip versions, putting off
reintegration to later, building up technical debt and causing their
projects to miss support for new hardware or features.
3. It makes DPDK different to almost every other system library and
framework that an operating systems might ship. This makes DPDK trickier
to dynamically link against, package and maintain for OS maintainers.

In order to address this issue, I have put together the minimal set of
concrete proposals below for discussion at the Technical Board next
Wednesday.

I wanted to share this, as these might not yet be the right proposals,
however I am putting them out there for feedback to start the discussion.

Thanks,

Ray K


Experimental API
1.	APIs designated as experimental are not considered part of the ABI
and may change without warning at any time.
2.	APIs designated as experimental must be marked depreciated for a
least one quarterly release before removal.
3.	APIs designated as experimental will no longer automatically graduate
to core after one release, they may stay experimental until their author
and the maintainer agree that graduation is appropriate.

Core API (non-experimental API)
4.	APIs designated as core must be depreciated for a least two years
before removal, to facilitate the continued compatibility with LTS
releases. A final removal notice will be published to the DPDK Mailing
List, and if there are no strong objections only then an API may be
removed.
5.	APIs designated as core may be changed as follows:-
5.a	The change proposer must demonstrated that the change has a
supporting use case and could not be achieved in any other way.
5.b	ABI version compatibility must be retained, as described below.

Shared Libraries
6.	DPDK will move to shared libraries & dynamic linking by default, to
accommodate greater use of ABI versioning by DPDK consumers.

ABI Versioning
7.	New quarterly releases of DPDK will remain ABI compatible with the
most recent DPDK LTS release.
(e.g. DPDK 19.08 will remain ABI compatible with DPDK LTS 18.11).
8.	New DPDK LTS releases will remain ABI compatible with the previous
two DPDK LTS releases.
(e.g. DPDK 20.11 will be ABI compatible with DPDK 19.11 and DPDK 18.11,
DPDK 21.11 will be ABI compatible with DPDK 20.11 and DPDK 19.11 etc)
8. & 9. will be achieved with ABI symbol versioning.


             reply	other threads:[~2019-04-03 15:42 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-03 15:42 Ray Kinsella [this message]
2019-04-03 15:42 ` Ray Kinsella
2019-04-03 19:53 ` Luca Boccassi
2019-04-03 19:53   ` Luca Boccassi
2019-04-04  9:29 ` Burakov, Anatoly
2019-04-04  9:29   ` Burakov, Anatoly
2019-04-04 10:54   ` [dpdk-dev] [dpdk-techboard] " Bruce Richardson
2019-04-04 10:54     ` Bruce Richardson
2019-04-04 12:02     ` Luca Boccassi
2019-04-04 12:02       ` Luca Boccassi
2019-04-04 13:05       ` Ray Kinsella
2019-04-04 13:05         ` Ray Kinsella
2019-04-04 13:10         ` Bruce Richardson
2019-04-04 13:10           ` Bruce Richardson
2019-04-05 13:25           ` Ray Kinsella
2019-04-05 13:25             ` Ray Kinsella
2019-04-07  9:37             ` Thomas Monjalon
2019-04-07  9:37               ` Thomas Monjalon
2019-04-04 13:21         ` Luca Boccassi
2019-04-04 13:21           ` Luca Boccassi
2019-04-04 12:52     ` Ray Kinsella
2019-04-04 12:52       ` Ray Kinsella
2019-04-04 14:07       ` Burakov, Anatoly
2019-04-04 14:07         ` Burakov, Anatoly
2019-04-07  9:48         ` Thomas Monjalon
2019-04-07  9:48           ` Thomas Monjalon
2019-04-08  9:04           ` Ray Kinsella
2019-04-08  9:04             ` Ray Kinsella
2019-04-08 10:15             ` Burakov, Anatoly
2019-04-08 10:15               ` Burakov, Anatoly
2019-04-08 13:00               ` Ray Kinsella
2019-04-08 13:00                 ` Ray Kinsella
2019-04-08 13:38                 ` Burakov, Anatoly
2019-04-08 13:38                   ` Burakov, Anatoly
2019-04-08 13:58                   ` David Marchand
2019-04-08 13:58                     ` David Marchand
2019-04-08 14:02                     ` Burakov, Anatoly
2019-04-08 14:02                       ` Burakov, Anatoly
2019-04-08 14:38                       ` David Marchand
2019-04-08 14:38                         ` David Marchand
2019-04-08 15:13                         ` Stephen Hemminger
2019-04-08 15:13                           ` Stephen Hemminger
2019-04-08 15:49                         ` Burakov, Anatoly
2019-04-08 15:49                           ` Burakov, Anatoly
2019-04-10  8:35                           ` David Marchand
2019-04-10  8:35                             ` David Marchand
2019-04-08 15:50                         ` Burakov, Anatoly
2019-04-08 15:50                           ` Burakov, Anatoly
2019-04-09  9:42                   ` Ray Kinsella
2019-04-09  9:42                     ` Ray Kinsella
2019-04-14  0:42             ` Neil Horman
2019-04-14  0:42               ` Neil Horman
2019-04-15  9:10               ` Bruce Richardson
2019-04-15  9:10                 ` Bruce Richardson
2019-04-04 15:51     ` Stephen Hemminger
2019-04-04 15:51       ` Stephen Hemminger
2019-04-04 16:37       ` Burakov, Anatoly
2019-04-04 16:37         ` Burakov, Anatoly
2019-04-04 16:56     ` Kevin Traynor
2019-04-04 16:56       ` Kevin Traynor
2019-04-04 19:08       ` Wiles, Keith
2019-04-04 19:08         ` Wiles, Keith
2019-04-04 20:13         ` Kevin Traynor
2019-04-04 20:13           ` Kevin Traynor
2019-04-05 13:30           ` Ray Kinsella
2019-04-05 13:30             ` Ray Kinsella
2019-04-05 13:29         ` Ray Kinsella
2019-04-05 13:29           ` Ray Kinsella
2019-04-04  9:47 ` [dpdk-dev] " Kevin Traynor
2019-04-04  9:47   ` Kevin Traynor
2019-04-04 13:16   ` Ray Kinsella
2019-04-04 13:16     ` Ray Kinsella
2019-04-10  5:14 ` Honnappa Nagarahalli
2019-04-10  5:14   ` Honnappa Nagarahalli
2019-04-10  9:03   ` [dpdk-dev] [dpdk-techboard] " Bruce Richardson
2019-04-10  9:03     ` Bruce Richardson
2019-04-10  9:43   ` [dpdk-dev] " Luca Boccassi
2019-04-10  9:43     ` Luca Boccassi

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=c0856556-a42e-d0cf-6a01-6279643c8089@ashroe.eu \
    --to=mdr@ashroe.eu \
    --cc=dev@dpdk.org \
    --cc=ktraynor@redhat.com \
    --cc=techboard@dpdk.org \
    /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).