Re: [dpdk-dev] DPDK ABI/API Stability

["Burakov, Anatoly" <anatoly.burakov@intel.com>]

On 03-Apr-19 4:42 PM, 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.
> 
> 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.

Hi Ray,

My somewhat rambly 2 cents :)

While i think some solution has to be found for the situation, we also 
have to balance this against speed of development and new features rollout.

For example, let's consider what i am intimately familiar with - the 
memory rework. I have made enormous efforts to ensure that pre-18.05 and 
post-18.05 remain as ABI/API compatible as possible, but there were a 
couple of API calls that were removed, and there couldn't have been any 
replacements (these API's were exposing internal structures that 
shouldn't have been exposed in the first place), and 18.05 also broke 
the ABI compatibility, because there was no way to do it without it 
(shared internal structures needed to change in part to support 
multiprocess).

So, if i understand your proposal correctly, assuming a 2-year waiting 
period for the deprecation of core API's, you would essentially still be 
waiting for the memory rework to land for a year more. Moreover, even 
*after* it has landed, there was a continuous stream of improvements and 
bugfixes, some of which has broke ABI compatibility as well. Some of 
them were my fault (as in, i could've foreseen the need for those 
changes, but didn't), but others came as a result of people using these 
new features in the wild and reporting issues/problems/suggestions - i 
am but one man, after all. Plus, you know, there's only 24 hours in a 
day, and some stuff takes time to implement :)

Since this rework goes right at the heart of DPDK (arguably there isn't 
a more "core" API than memory!), there is no (sane) way in the universe 
to 1) keep backwards compatibility for this, or 2) keep two parallel 
versions of it. We also need to test all that, and, to be honest, one 
validation cycle for a release wouldn't be enough to figure out all of 
the kinks and implications of such a case. It was really great that 
memory rework has landed in 18.05 and we had time to improve and prepare 
it for an 18.11 LTS - i think everyone can say that it's in much better 
shape in 18.11 than it was in 18.05, but if we couldn't do an ABI break 
here or there, this rate of improvements would have slowed down 
significantly.

Now, i understand that this is probably a highly exceptional case, but 
i'm sure that maintainers of other parts of DPDK will have their own 
examples of similar things happening.

I have no idea what a proper solution would look like. Any "splitting" 
of the trees into "experimental" vs. "stable" will end up causing the 
same issue - people choose to use stable over experimental because, 
well, it's more stable, and new/experimental features don't get tested 
as much because no one runs the thing in the first place.

TL;DR we have to be careful not to constrain the pace of 
development/bugfixing just for the sake of having a stable API/ABI :)

> 
> 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.
> 
> 


-- 
Thanks,
Anatoly