From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id BAD3EA0679 for ; Thu, 4 Apr 2019 11:47:07 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id AFC667CEB; Thu, 4 Apr 2019 11:47:06 +0200 (CEST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id AAF797CB0; Thu, 4 Apr 2019 11:47:05 +0200 (CEST) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 101EB5D688; Thu, 4 Apr 2019 09:47:05 +0000 (UTC) Received: from [10.40.205.77] (unknown [10.40.205.77]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4D9C01001DEE; Thu, 4 Apr 2019 09:47:03 +0000 (UTC) To: Ray Kinsella , dev@dpdk.org, "techboard@dpdk.org" References: From: Kevin Traynor Message-ID: Date: Thu, 4 Apr 2019 10:47:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Thu, 04 Apr 2019 09:47:05 +0000 (UTC) Subject: Re: [dpdk-dev] DPDK ABI/API Stability X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190404094701.ITHaYYxO4mIPbPloGLDxrppioK5lrSGd7R3NgSErhsY@z> On 03/04/2019 16:42, Ray Kinsella wrote: > 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. > +1 > 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. > I don't think they automatically graduate in the current scheme, so it would seem to be no change to the process. One thing to note is that in the current experimental API scheme those API are tagged as deprecated which can cause problems with application build/CI if they are used. But this is more related to implementation rather than the classification indicating the API may change. It might need to change if there was a trend for keeping API as experimental for a longer time. > 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. I agree with the sentiment but it needs real buy in from authors. Otherwise the burden falls on the reviewer to spend time exploring/finding a way not to change the API. > 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. >