[dpdk-dev] Discussion on the OS Packaging of DPDK

[dpdk-dev] Discussion on the OS Packaging of DPDK

[Ray Kinsella]

( from the undersigned )

Hi folks,

In light of the renewed community discussion on API Stability
(https://mails.dpdk.org/archives/dev/2019-April/128969.html), now is
right time to open a discussion on how DPDK is distributed and updated.

To this point in time, DPDK's primary distribution method has been as
source code distributed as a tarball from dpdk.org. This distribution
method, in addition to abi instability and the dpdk's build system
default behaviour of static linking have all encouraged the "tight
coupling" or "vendorization" of DPDK.

These behaviours makes it a challenge for end users, those deploying
applications based on DPDK, to manage and update DPDK in a method
consistent with other system libraries. For instance, an end user may
not have any idea which version of DPDK a consuming application may be
using and if this DPDK version is reasonably up to date with the latest
upstream version. This would not be the case for other system libraries
such as glibc.

For these reasons, now is the right time for DPDK to embrace standard
Operating System practices for distributing and updating system
libraries. The current industry push towards cloud and
cloud-friendliness make addressing this issue all the more timely.

To this end, the following proposals are made for discussion at the next
techboard meeting:-

* The primary method of distributing DPDK should be as an operating
system package, dpdk.org should be updated to reflect this reality and
provide OS installation details in place of tarball downloads.

* DPDK should build as a dynamic shared libraries by default, to
encourage loose coupling with consuming applications.

* Future guarantees around ABI/API stability should be provided, so that
OS packagers can offer safe upgrade paths for consuming applications.

Look forward to the discussion, thank you,

Luca Boccassi, Debian maintainer and DPDK LTS maintainer
Nirmoy Das, SUSE dpdk maintainer
Christian Ehrhardt, Ubuntu maintainer and former DPDK LTS maintainer
Ian Stokes, Open vSwitch maintainer
Tom Herbert, FD.io/VPP contributor. CentOS NFV SIG chair.
Billy McFall, DPDK consumer and FD.io/VPP Contributor
Ray Kinsella, DPDK and FD.io Contributor

Re: [dpdk-dev] [dpdk-techboard] Discussion on the OS Packaging of DPDK

[Bruce Richardson]

On Fri, May 10, 2019 at 02:01:54PM +0100, Ray Kinsella wrote:
> ( from the undersigned )
> 
> Hi folks,
> 
> In light of the renewed community discussion on API Stability
> (https://mails.dpdk.org/archives/dev/2019-April/128969.html), now is
> right time to open a discussion on how DPDK is distributed and updated.
> 
> To this point in time, DPDK's primary distribution method has been as
> source code distributed as a tarball from dpdk.org. This distribution
> method, in addition to abi instability and the dpdk's build system
> default behaviour of static linking have all encouraged the "tight
> coupling" or "vendorization" of DPDK.
> 
> These behaviours makes it a challenge for end users, those deploying
> applications based on DPDK, to manage and update DPDK in a method
> consistent with other system libraries. For instance, an end user may
> not have any idea which version of DPDK a consuming application may be
> using and if this DPDK version is reasonably up to date with the latest
> upstream version. This would not be the case for other system libraries
> such as glibc.
> 
> For these reasons, now is the right time for DPDK to embrace standard
> Operating System practices for distributing and updating system
> libraries. The current industry push towards cloud and
> cloud-friendliness make addressing this issue all the more timely.
> 
> To this end, the following proposals are made for discussion at the next
> techboard meeting:-
> 
> * The primary method of distributing DPDK should be as an operating
> system package, dpdk.org should be updated to reflect this reality and
> provide OS installation details in place of tarball downloads.

I really like that idea. Since DPDK is available in distro packages that
should be the first port of call for users getting DPDK. Since it's just a
doc update - as I understand it anyway - it should be easy to implement if
agreed, which is a nice bonus.

> 
> * DPDK should build as a dynamic shared libraries by default, to
> encourage loose coupling with consuming applications.
> 

To a certain extent, this only applies with the "make" build system, which
is due to be deprecated in the next release and removed sometime next year.
With builds done with meson and ninja, both shared and static libraries are
always built. The default setting though remains as "static" which applies
only to the linking of applications as part of the DPDK build. This default
was set mainly for legacy purposes, but also has benefits for us developers
working on DPDK, since we don't need to worry about setting LD_LIBRARY_PATH
and EAL_PMD_PATH values for running applications we've built. Therefore,
I'm not sure of the value of changing the default here - it's certainly
less important than the default in the "make" build system where only one
library type at a time was built.

> * Future guarantees around ABI/API stability should be provided, so that
> OS packagers can offer safe upgrade paths for consuming applications.
> 
> Look forward to the discussion, thank you,
> 
> Luca Boccassi, Debian maintainer and DPDK LTS maintainer
> Nirmoy Das, SUSE dpdk maintainer
> Christian Ehrhardt, Ubuntu maintainer and former DPDK LTS maintainer
> Ian Stokes, Open vSwitch maintainer
> Tom Herbert, FD.io/VPP contributor. CentOS NFV SIG chair.
> Billy McFall, DPDK consumer and FD.io/VPP Contributor
> Ray Kinsella, DPDK and FD.io Contributor

Thanks all for kicking off this discussion.

/Bruce

Re: [dpdk-dev] [dpdk-techboard] Discussion on the OS Packaging of DPDK

[Thomas Monjalon]

10/05/2019 15:43, Bruce Richardson:
> On Fri, May 10, 2019 at 02:01:54PM +0100, Ray Kinsella wrote:
> > ( from the undersigned )
> > 
> > Hi folks,
> > 
> > In light of the renewed community discussion on API Stability
> > (https://mails.dpdk.org/archives/dev/2019-April/128969.html), now is
> > right time to open a discussion on how DPDK is distributed and updated.
> > 
> > To this point in time, DPDK's primary distribution method has been as
> > source code distributed as a tarball from dpdk.org. This distribution
> > method, in addition to abi instability and the dpdk's build system
> > default behaviour of static linking have all encouraged the "tight
> > coupling" or "vendorization" of DPDK.
> > 
> > These behaviours makes it a challenge for end users, those deploying
> > applications based on DPDK, to manage and update DPDK in a method
> > consistent with other system libraries. For instance, an end user may
> > not have any idea which version of DPDK a consuming application may be
> > using and if this DPDK version is reasonably up to date with the latest
> > upstream version. This would not be the case for other system libraries
> > such as glibc.
> > 
> > For these reasons, now is the right time for DPDK to embrace standard
> > Operating System practices for distributing and updating system
> > libraries. The current industry push towards cloud and
> > cloud-friendliness make addressing this issue all the more timely.
> > 
> > To this end, the following proposals are made for discussion at the next
> > techboard meeting:-
> > 
> > * The primary method of distributing DPDK should be as an operating
> > system package, dpdk.org should be updated to reflect this reality and
> > provide OS installation details in place of tarball downloads.
> 
> I really like that idea. Since DPDK is available in distro packages that
> should be the first port of call for users getting DPDK. Since it's just a
> doc update - as I understand it anyway - it should be easy to implement if
> agreed, which is a nice bonus.

Yes. The real effort will be to stay up to date with changes
in OS distributions. If distro maintainers are willing to maintain it,
that's fine. Thank you :)

> > * DPDK should build as a dynamic shared libraries by default, to
> > encourage loose coupling with consuming applications.
> 
> To a certain extent, this only applies with the "make" build system, which
> is due to be deprecated in the next release and removed sometime next year.
> With builds done with meson and ninja, both shared and static libraries are
> always built. The default setting though remains as "static" which applies
> only to the linking of applications as part of the DPDK build. This default
> was set mainly for legacy purposes, but also has benefits for us developers
> working on DPDK, since we don't need to worry about setting LD_LIBRARY_PATH
> and EAL_PMD_PATH values for running applications we've built. Therefore,
> I'm not sure of the value of changing the default here - it's certainly
> less important than the default in the "make" build system where only one
> library type at a time was built.

Yes no need to change the default.
If you build DPDK yourself, it is more convenient to use static libs.
If you want something easier to update, you probably use
the packages from distributions which are shared libraries.

> > * Future guarantees around ABI/API stability should be provided, so that
> > OS packagers can offer safe upgrade paths for consuming applications.

DPDK is a set of libraries, some more stable than others.
If we cannot guarantee a full stability for a long time,
we may have some changes here and there sometimes.
And it's even worst with experimental functions.
I think it is more realistic to provide a level of stability
per DPDK library. In order to leverage such fine grained stability,
the libraries should be packaged separately in the OS.
Then the applications relying only on stable libraries will be able
to link with updated libraries without any change or re-compilation.

Re: [dpdk-dev] [dpdk-techboard] Discussion on the OS Packaging of DPDK

[Christian Ehrhardt]

On Fri, May 10, 2019 at 8:43 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> 10/05/2019 15:43, Bruce Richardson:
> > On Fri, May 10, 2019 at 02:01:54PM +0100, Ray Kinsella wrote:
> > > ( from the undersigned )
> > >
> > > Hi folks,
> > >
> > > In light of the renewed community discussion on API Stability
> > > (https://mails.dpdk.org/archives/dev/2019-April/128969.html), now is
> > > right time to open a discussion on how DPDK is distributed and updated.
> > >
> > > To this point in time, DPDK's primary distribution method has been as
> > > source code distributed as a tarball from dpdk.org. This distribution
> > > method, in addition to abi instability and the dpdk's build system
> > > default behaviour of static linking have all encouraged the "tight
> > > coupling" or "vendorization" of DPDK.
> > >
> > > These behaviours makes it a challenge for end users, those deploying
> > > applications based on DPDK, to manage and update DPDK in a method
> > > consistent with other system libraries. For instance, an end user may
> > > not have any idea which version of DPDK a consuming application may be
> > > using and if this DPDK version is reasonably up to date with the latest
> > > upstream version. This would not be the case for other system libraries
> > > such as glibc.
> > >
> > > For these reasons, now is the right time for DPDK to embrace standard
> > > Operating System practices for distributing and updating system
> > > libraries. The current industry push towards cloud and
> > > cloud-friendliness make addressing this issue all the more timely.
> > >
> > > To this end, the following proposals are made for discussion at the next
> > > techboard meeting:-
> > >
> > > * The primary method of distributing DPDK should be as an operating
> > > system package, dpdk.org should be updated to reflect this reality and
> > > provide OS installation details in place of tarball downloads.
> >
> > I really like that idea. Since DPDK is available in distro packages that
> > should be the first port of call for users getting DPDK. Since it's just a
> > doc update - as I understand it anyway - it should be easy to implement if
> > agreed, which is a nice bonus.
>
> Yes. The real effort will be to stay up to date with changes
> in OS distributions. If distro maintainers are willing to maintain it,
> that's fine. Thank you :)

Speaking for Ubuntu but knowing it applies to most others the "up to
date" will usually apply per release.
So if going forward some Distro releases with DPDK 19.11 it will
likely pick up all updates to 19.11.x that we will create but rather
unlikely switch to anything newer.
The two year support that DPDK grants to LTS releases was already a
great step forward and I think at that time it reasonably matured to
stay "stable".

But the DPDK project could further help distribution consumption be either:
- extending these LTS times (a tradeoff of LTS maintainer effort)
Or and that might be a more interesting tradeoff:
- after the ~2 years of functional LTS the DPDK project could still
provide an pure security "LTSS"

So is in 2023 we 100 fixes those won't be backported to 19.11.x anymore.
But if we find an issue in DPDK which affects security the
distributions are forced to get this done anyway.
Doing that together with upstream to have a single agreed fix to such
cases would be very great.

Not sure how doable that is (mostly depends on LTS maintainers), but I
thought this would be a great thing for Distribution consumption and
this is the right context to bring it up.

> > > * DPDK should build as a dynamic shared libraries by default, to
> > > encourage loose coupling with consuming applications.
> >
> > To a certain extent, this only applies with the "make" build system, which
> > is due to be deprecated in the next release and removed sometime next year.
> > With builds done with meson and ninja, both shared and static libraries are
> > always built. The default setting though remains as "static" which applies
> > only to the linking of applications as part of the DPDK build. This default
> > was set mainly for legacy purposes, but also has benefits for us developers
> > working on DPDK, since we don't need to worry about setting LD_LIBRARY_PATH
> > and EAL_PMD_PATH values for running applications we've built. Therefore,
> > I'm not sure of the value of changing the default here - it's certainly
> > less important than the default in the "make" build system where only one
> > library type at a time was built.
>
> Yes no need to change the default.
> If you build DPDK yourself, it is more convenient to use static libs.
> If you want something easier to update, you probably use
> the packages from distributions which are shared libraries.
>
> > > * Future guarantees around ABI/API stability should be provided, so that
> > > OS packagers can offer safe upgrade paths for consuming applications.
>
> DPDK is a set of libraries, some more stable than others.
> If we cannot guarantee a full stability for a long time,
> we may have some changes here and there sometimes.
> And it's even worst with experimental functions.
> I think it is more realistic to provide a level of stability
> per DPDK library. In order to leverage such fine grained stability,
> the libraries should be packaged separately in the OS.

Agreed and done in Debian/Ubuntu creating quite some fun with 124 such
libs (and a few utility and dev packages on top) :-)

I agree that less common libraries and such are harder to support and
will certainly have a different quality level than others.
In addition what often also can be a challenge is PMDs for devices
unavailable to the Distributions, those are essentially also
unsupportable.

I have worked on that already and right now (as an ever changing
example) we have 41 of them in main supported by Canonical and 88 on
community support [1] in universe.

> Then the applications relying only on stable libraries will be able
> to link with updated libraries without any change or re-compilation.


[1]: https://help.ubuntu.com/community/Repositories/Ubuntu



-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Re: [dpdk-dev] [dpdk-techboard] Discussion on the OS Packaging of DPDK

[Ray Kinsella]

On 10/05/2019 19:43, Thomas Monjalon wrote:
> 10/05/2019 15:43, Bruce Richardson:
>> On Fri, May 10, 2019 at 02:01:54PM +0100, Ray Kinsella wrote:
>>> ( from the undersigned )
>>>
<SNIP>
>> To a certain extent, this only applies with the "make" build system, which
>> is due to be deprecated in the next release and removed sometime next year.
>> With builds done with meson and ninja, both shared and static libraries are
>> always built. The default setting though remains as "static" which applies
>> only to the linking of applications as part of the DPDK build. This default
>> was set mainly for legacy purposes, but also has benefits for us developers
>> working on DPDK, since we don't need to worry about setting LD_LIBRARY_PATH
>> and EAL_PMD_PATH values for running applications we've built. Therefore,
>> I'm not sure of the value of changing the default here - it's certainly
>> less important than the default in the "make" build system where only one
>> library type at a time was built.
> 
> Yes no need to change the default.
> If you build DPDK yourself, it is more convenient to use static libs.
> If you want something easier to update, you probably use
> the packages from distributions which are shared libraries.

Well I disagree a bit.
I understand 100% that we don't want to break the developer experience.
My concern is that developers end using something different then, that
what the DPDK consumers are using - this always ends up being a hiding
place for bugs.

It might be worthwhile seeing if we could resolve this in another way,
either with RPATH or EAL_PMD_PATH change.

> 
>>> * Future guarantees around ABI/API stability should be provided, so that
>>> OS packagers can offer safe upgrade paths for consuming applications.
> 
> DPDK is a set of libraries, some more stable than others.
> If we cannot guarantee a full stability for a long time,
> we may have some changes here and there sometimes.
> And it's even worst with experimental functions.
> I think it is more realistic to provide a level of stability
> per DPDK library. In order to leverage such fine grained stability,
> the libraries should be packaged separately in the OS.
> Then the applications relying only on stable libraries will be able
> to link with updated libraries without any change or re-compilation.
> 
> 
>