On Wed, Apr 10, 2019 at 05:14:43AM +0000, Honnappa Nagarahalli 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 > 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? > We do sometimes, but not enough. If we mandated ABI compatibility, or made ABI breaks harder, I think we'd see greater adoption of this versioning (something I am very much favour of).
/Bruce
