Re: [dpdk-dev] ABI and inline functions

[Thomas Monjalon <thomas@monjalon.net>]

24/04/2019 14:22, Ray Kinsella:
> On 24/04/2019 12:08, Burakov, Anatoly wrote:
> > To me, part of the problem is that DPDK is an "everything and the
> > kitchen sink" kind of library where there is a bunch of drivers, a whole
> > quasi-OS layer of dealing with hardware in a cross-platform manner, a
> > separate memory management system, a bunch of libraries such as hash/lpm
> > tables, plus there's QOS, IP Pipeline, flow stuff, etc. - normally, "a
> > library" would concentrate on doing one thing well. DPDK, on the other
> > hand, tries to do *everything* well. The sheer breadth of DPDK's scope
> > is, i think, contributing to the breakages. If you keep 99% of your
> > libraries stable between version, but there's a small ABI tweak in an
> > LPM library, the entire DPDK stability gets invalidated.

Yes, that's why we keep the split in libraries.
So we can update LPM library version while keeping the same ethdev
version to allow applications to load the shared library of the same
name without any re-compilation. In this case, the need for
re-compilation is only for applications using LPM.
But this model is not convenient for distributions because they
manage DPDK as one package. It means they have to re-compile all
applications if one LPM ABI is broken, even if it is experimental.
Should the libraries be split in packages?

> Well I guess DPDK is no more complex than Java or .NET Framework in that
> respect, as these also feature OS-layers, memory management systems,
> application frameworks, primitives etc but do manage to give their
> consumers strong guarantee's on API stability. Clearly ABI stability has
> a no meaning when you always being JIT compiled.
> 
> I understand that doing everything right the first time, allowing for
> future evolution, while keep ABI/APIs relatively stable is a tough ask.
> 
> I would propose that API's marked as "experimental" be given greater
> freedom to change to give time of API's to bake, so they don't need to
> be always "right first time", that there is wriggle room for these.

As said above, experimental level does not solve ABI stability.
If we break an experimental API, the ABI is broken, requiring
to re-compile the application.

> I would also propose more use of ABI Versioning to enable evolution of
> DPDK while preserving backward compatibility.

Yes, if all other obvious versioning issues are solved,
we can walk the extra mile of better using ABI versioning.

> > Perhaps limiting DPDK's scope would help with this as well.
> 
> I agree.

Yes, either split the project in more limited scope areas,
or split the packages.