DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ray Kinsella <mdr@ashroe.eu>
To: dpdk-dev <dev@dpdk.org>,
	"O'Driscoll, Tim" <tim.odriscoll@intel.com>,
	Brian <brian.aherne@intel.com>
Cc: "techboard@dpdk.org" <techboard@dpdk.org>
Subject: [dpdk-dev] [RFC] Proposals and notes from ABI stability panel @ DPDK Userspace
Date: Mon, 23 Sep 2019 18:51:16 +0100	[thread overview]
Message-ID: <126e7de8-d2cd-d9f0-4fe8-d0d05963589f@ashroe.eu> (raw)

Folks,

As you may be aware, there was a panel on ABI Stability @ DPDK
Userspace.  There where a number of proposed amendments to the ABI
stability proposal made, as well as a number of points and comments, you
will find all these below. The proposals needs further discussion so
please chime in below.

Thanks to Tim for capturing while I was busy on the stage.

Thanks,

Ray K


Table of Contents
_________________

1. Proposals from the panel discussion.
.. 1. Developer releases (versus User Releases)
.. 2. Core and non-core packaging
.. 3. Approach for public data structures
.. 4. Delaying v19.11
2. Other notes from the panel discussion.
.. 1. Performance as the paramount goal.
.. 2. Length of ABI Stability.
.. 3. Testing ABI Stability
.. 4. Call to action


1 Proposals from the panel discussion.
======================================

1.1 Developer releases (versus User Releases)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  - Summary: Differentiate between "developer" and "user" releases.
    - 1 year is too long to wait to upstream a new feature which breaks
      ABI.
    - Developer releases would be for use by the development community
      only.
    - A proposed compromise was that the .08 release would be the only
      "developer release".


1.2 Core and non-core packaging
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  - Summary: OS packaging doesn't include all libraries.
    - This would create a delta between the community ABI, and the OS
      packaging.
    - OS packagers rational is that some libraries are used very rarely.


1.3 Approach for public data structures
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  - Summary: Public/exposed data structures are tricky for ABI
    stability.
    - See discussion @

<http://inbox.dpdk.org/dev/980083c6-130a-9658-f82b-0c9ddc7cc0cc@ashroe.eu/>


1.4 Delaying v19.11
~~~~~~~~~~~~~~~~~~~

  - Summary: push v19.11 to v19.12 to make more time to prepare and wave
    the depreciation process.
    - OVS take Nov LTS release in their Feb release. Delaying 19.11 may
      have an impact on this.
    - Not easy to change release at this stage as many things depend on
      it (OS distros etc.).


2 Other notes from the panel discussion.
========================================

2.1 Performance as the paramount goal.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  - Some users, would trade performance for better readability and
    debug-ability.
  - Skepticism that micro-benchmarks reflect real world performance.


2.2 Length of ABI Stability.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  - Some users, questioned if 1 year would be long enough.
  - It was clarified that the 1 year period, would be reviewed after the
    first year with the intention of lengthening the period.


2.3 Testing ABI Stability
~~~~~~~~~~~~~~~~~~~~~~~~~

  - More work for developers and validation teams. Need to validate
    multiple paths for symbol versioning.


2.4 Call to action
~~~~~~~~~~~~~~~~~~

  - We should do something. So we don’t want to have the same
    conversation again in a year.

             reply	other threads:[~2019-09-23 17:51 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-23 17:51 Ray Kinsella [this message]
2019-09-25 13:31 ` Kevin Traynor
2019-09-25 14:29   ` Ray Kinsella
2019-09-25 14:40     ` [dpdk-dev] [dpdk-techboard] " Bruce Richardson
2019-09-25 14:49       ` Kevin Traynor
2019-09-25 15:06       ` 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=126e7de8-d2cd-d9f0-4fe8-d0d05963589f@ashroe.eu \
    --to=mdr@ashroe.eu \
    --cc=brian.aherne@intel.com \
    --cc=dev@dpdk.org \
    --cc=techboard@dpdk.org \
    --cc=tim.odriscoll@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
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).