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

[Luca Boccassi <bluca@debian.org>]

On Wed, 2019-04-10 at 05:14 +0000, Honnappa Nagarahalli wrote:
> > 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.

>From first-hand experience: re-integration and re-validation are
different in scope and resource requirements.
Validation is usually done by the QA group, and usually doesn't cover
just one library that makes up a part of a product. In other words,
whether the DPDK version changes or not, a new version of a product
will typically undergo full regression testing anyway.

Integration is done by the development group. Any engineering-days that
have to be dedicated to re-integrate a new version of DPDK are
resources taken away from development of new features or bug fixing.
Maintenance costs of OSS components are a sometimes overlooked but
critical part of correctly scoping the opex of a project, and it's
something that product/project managers do look at.

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

For many reasons. For example the argument I always use is that while
new version Y might not be needed, new version Z might suddenly become
required for the successful delivery of critical feature A, or to fix
critical bug B.
In my experience, jumping from version X to Y and then Y to Z is always
cheaper and quicker and lower effort than jumping from X to Z, and the
larger the jump, the more work it is.

Another reason is that it's orders of magnitude cheaper to consume
dependencies from the base distribution of choice when building a Linux
product, rather than vendorizing. Doing that has of course drawbacks,
including not being in control of the version of dependencies - so you
don't have a choice, you need to keep up as the base distro moves on.

-- 
Kind regards,
Luca Boccassi