[dpdk-dev] DPDK ABI/API Stability

[Honnappa Nagarahalli]

> 
> 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
This link can be used to check which structures are not needed to be exposed to the application.
For ex: for rte_hash library in "19.02 vs current", backward compatibility is ~69%. Digging into further details indicates that the break is due to addition of a member to, what I think should be, an internal structure (but is external).

> 
> 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".
Even if the ABI did not change, any claim of support with newer version needs re-validation. I think, re-integration is the only extra effort.
Why would anyone like to move to newer version just to stay current if the newer version does not add any value to them? IMO, this is doing work for no benefit.

> 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.
+1, however, I think applications should have been doing this already (if they were bothered with ABI compatibility)
Would not https://doc.dpdk.org/guides/contributing/versioning.html#abi-versioning solve the issue? Are we not doing versioning for some changes?

<snip>