[dpdk-dev] libdpdk upstream changes for ecosystem best practices

[dpdk-dev] libdpdk upstream changes for ecosystem best practices

[Robie Basak]

Hi,

We’re looking at packaging DPDK in Ubuntu. We’d like to discuss upstream
changes to better integrate DPDK into Linux distributions. Here’s a
summary of what we need:

 1) Define one library ABI (soname and sover) that we can use instead of the
    split build.

 2) Fix #includes so we don't have to include config.h

 3) Put headers into /usr/include/dpdk instead of /usr/include

You can see our current packaging progress at
https://git.launchpad.net/~ubuntu-server/dpdk/log/?h=ubuntu-wily and a
test PPA at https://launchpad.net/~smb/+archive/ubuntu/dpdk/

First, it would be easier for us to ship a single binary package that
ships a single shared library to cover all of DPDK that library
consumers might need, rather than having it split up as you do. I
understand the build system is capable of doing this already, but what
we don’t have is a well defined soname and sover (currently
parameterized in the build) for ABI compatibility purposes. As a binary
distribution, this is something that we’d expect upstream to define,
since normally we expect to achieve binary compatibility across all
distributions at this level in the stack.

So I have the following requests:

So that we can get DPDK packaging into Ubuntu immediately, please could
we agree to define (and burn) libdpdk.so.0 to be the ABI that builds
with upstream release 2.0.0 when built with the native-linuxapp-gcc
template options plus the following changes:
    CONFIG_RTE_MACHINE=”default”
    CONFIG_RTE_APP_TEST=n
    CONFIG_LIBRTE_VHOST=y
    CONFIG_RTE_EAL_IGB_UIO=n
    CONFIG_RTE_LIBRTE_KNI=n
    CONFIG_RTE_BUILD_COMBINE_LIBS=y
    CONFIG_RTE_BUILD_SHARED_LIB=y
    CONFIG_RTE_LIBNAME=”dpdk”
The combined library would be placed into /usr/lib/$(ARCH)-linux-gnu/
where it can be found without modification to the library search path.
We want to ship it like this in Ubuntu anyway, but I’d prefer upstream
to have defined it as such since then we’ll have a proper definition of
the ABI that can be shared across distributions and other consumers any
time ABI compatibility is expected.
Though not strictly part of a shared library ABI, I also propose some
build-related upstream changes at API level below, that I’d like to also
ship in the initial Ubuntu packaging of the header files. Clearly you
cannot make this change in an existing release, but I propose that you
do this for your next release so all library consumers will see a
consistent and standard API interface. If you agree to this, then I’d
also like to ship the Ubuntu package with patches to do the same thing
in your current release.

Right now, I understand that library consumers need to either: 1) use
the upstream-provided build system (.mk files etc); or 2) otherwise make
sure to include rte_config.h by specifying it as an extra CPPFLAGS
parameter as the upstream API documentation does not require its
inclusion use in source files. This is problematic because somebody
writing against multiple libraries should just expect to #include the
API-defined headers and link simply with -l for the build to work. It is
common to have a config.h type file generated at build time, but in this
case I’d expect it to be conditionally included automatically as part of
the API, for example by #include’ing it in any file the API _does_
define that library users must include. To fix this, I propose to
#include <dpdk/rte_config.h> in every header file that library users may
#include according to the API.

That brings me to paths. To avoid polluting the /usr/include namespace,
I’d expect either a single /usr/include/dpdk.h, or everything inside
/usr/include/dpdk/, or both. Then library consumers would #include
combinations of <dpdk.h> and <dpdk/foo.h> as required, our packaging
could install into these directories without stealing any other part of
the shared filesystem namespace, and library users wouldn’t have to be
concerned about paths, configuration or build systems. This would then
match every other shared library we package. Does this sound reasonable
to you? Is this a change you will accept?

Thanks,

Robie

Re: [dpdk-dev] libdpdk upstream changes for ecosystem best practices

[Thomas Monjalon]

Hi,

2015-09-02 14:49, Robie Basak:
> Hi,
> 
> We’re looking at packaging DPDK in Ubuntu. We’d like to discuss upstream

Nice

> changes to better integrate DPDK into Linux distributions. Here’s a
> summary of what we need:
> 
>  1) Define one library ABI (soname and sover) that we can use instead of the
>     split build.
> 
>  2) Fix #includes so we don't have to include config.h
> 
>  3) Put headers into /usr/include/dpdk instead of /usr/include
> 
> You can see our current packaging progress at
> https://git.launchpad.net/~ubuntu-server/dpdk/log/?h=ubuntu-wily and a

Thanks for sharing

> test PPA at https://launchpad.net/~smb/+archive/ubuntu/dpdk/
> 
> First, it would be easier for us to ship a single binary package that
> ships a single shared library to cover all of DPDK that library
> consumers might need, rather than having it split up as you do. I
> understand the build system is capable of doing this already, but what
> we don’t have is a well defined soname and sover (currently
> parameterized in the build) for ABI compatibility purposes. As a binary

No it is now fixed:
	http://dpdk.org/browse/dpdk/commit/?id=c3ce2ad3548

> distribution, this is something that we’d expect upstream to define,
> since normally we expect to achieve binary compatibility across all
> distributions at this level in the stack.
> 
> So I have the following requests:
> 
> So that we can get DPDK packaging into Ubuntu immediately, please could
> we agree to define (and burn) libdpdk.so.0 to be the ABI that builds
> with upstream release 2.0.0 when built with the native-linuxapp-gcc
> template options plus the following changes:
>     CONFIG_RTE_MACHINE=”default”
>     CONFIG_RTE_APP_TEST=n
>     CONFIG_LIBRTE_VHOST=y
>     CONFIG_RTE_EAL_IGB_UIO=n
>     CONFIG_RTE_LIBRTE_KNI=n
>     CONFIG_RTE_BUILD_COMBINE_LIBS=y
>     CONFIG_RTE_BUILD_SHARED_LIB=y

I feel this configuration is the responsibility of the distribution.
What do you expect to have in the source project?

>     CONFIG_RTE_LIBNAME=”dpdk”

not exist anymore

> The combined library would be placed into /usr/lib/$(ARCH)-linux-gnu/
> where it can be found without modification to the library search path.
> We want to ship it like this in Ubuntu anyway, but I’d prefer upstream
> to have defined it as such since then we’ll have a proper definition of
> the ABI that can be shared across distributions and other consumers any
> time ABI compatibility is expected.

You mean you target ABI compatibility between Linux distributons?
But other libraries could have different versions so you would be lucky
to have a binary application finding the same dependencies.

> Though not strictly part of a shared library ABI, I also propose some
> build-related upstream changes at API level below, that I’d like to also
> ship in the initial Ubuntu packaging of the header files. Clearly you
> cannot make this change in an existing release, but I propose that you
> do this for your next release so all library consumers will see a
> consistent and standard API interface. If you agree to this, then I’d
> also like to ship the Ubuntu package with patches to do the same thing
> in your current release.

Yes cleanup patches are welcome :)

> Right now, I understand that library consumers need to either: 1) use
> the upstream-provided build system (.mk files etc); or 2) otherwise make
> sure to include rte_config.h by specifying it as an extra CPPFLAGS
> parameter as the upstream API documentation does not require its
> inclusion use in source files. This is problematic because somebody
> writing against multiple libraries should just expect to #include the
> API-defined headers and link simply with -l for the build to work. It is
> common to have a config.h type file generated at build time, but in this
> case I’d expect it to be conditionally included automatically as part of
> the API, for example by #include’ing it in any file the API _does_
> define that library users must include. To fix this, I propose to
> #include <dpdk/rte_config.h> in every header file that library users may
> #include according to the API.
> 
> That brings me to paths. To avoid polluting the /usr/include namespace,
> I’d expect either a single /usr/include/dpdk.h, or everything inside
> /usr/include/dpdk/, or both. Then library consumers would #include

The second option seems more reasonable.

> combinations of <dpdk.h> and <dpdk/foo.h> as required, our packaging
> could install into these directories without stealing any other part of
> the shared filesystem namespace, and library users wouldn’t have to be
> concerned about paths, configuration or build systems. This would then
> match every other shared library we package. Does this sound reasonable
> to you? Is this a change you will accept?

Yes there is clearly a namespace issue in DPDK.
I would add that libethdev should be librte_ethdev.

> Thanks,

Thanks for suggesting

Re: [dpdk-dev] libdpdk upstream changes for ecosystem best practices

[Stephen Hemminger]

On Wed, 02 Sep 2015 16:18:33 +0200
Thomas Monjalon <thomas.monjalon@6wind.com> wrote:

> Hi,
> 
> 2015-09-02 14:49, Robie Basak:
> > Hi,
> > 
> > We’re looking at packaging DPDK in Ubuntu. We’d like to discuss upstream
> 
> Nice

This matches what we do internally. I was heading towards making this
a real Debian package. Since Debian is more free and is a superset
of Ubuntu.

> 
> > changes to better integrate DPDK into Linux distributions. Here’s a
> > summary of what we need:
> > 
> >  1) Define one library ABI (soname and sover) that we can use instead of the
> >     split build.
> > 
> >  2) Fix #includes so we don't have to include config.h
> > 
> >  3) Put headers into /usr/include/dpdk instead of /usr/include
> > 
> > You can see our current packaging progress at
> > https://git.launchpad.net/~ubuntu-server/dpdk/log/?h=ubuntu-wily and a
> 
> Thanks for sharing

I have made basically the same decisions. Target is /usr/include/dpdk
and the library version comes from rte config. It seems more logical
to make the library shared object version equal the major version
of DPDK (ie 2) rather than having shared object and source versions
diverge.

Just updating to 2.1 packaging now, will send patches.

Re: [dpdk-dev] libdpdk upstream changes for ecosystem best practices

[Nikita Kozlov]

On 09/02/2015 03:49 PM, Robie Basak wrote:
> Hi,
>
> We’re looking at packaging DPDK in Ubuntu. We’d like to discuss upstream
> changes to better integrate DPDK into Linux distributions.
> ...
>
> Thanks,
>
> Robie
Hello,

For your interest, we have also done some kind of packaging of dpdk for
debian : https://github.com/Gandi/dpdk-debian
It's not really clean and it triggers many lintian things, but feel free
to dig from it anything valuable.

Thanks for your packaging effort,

Nikita

Re: [dpdk-dev] libdpdk upstream changes for ecosystem best practices

[Robie Basak]

Hi Thomas,

On Wed, Sep 02, 2015 at 04:18:33PM +0200, Thomas Monjalon wrote:
> > First, it would be easier for us to ship a single binary package that
> > ships a single shared library to cover all of DPDK that library
> > consumers might need, rather than having it split up as you do. I
> > understand the build system is capable of doing this already, but what
> > we don’t have is a well defined soname and sover (currently
> > parameterized in the build) for ABI compatibility purposes. As a binary
> 
> No it is now fixed:
> 	http://dpdk.org/browse/dpdk/commit/?id=c3ce2ad3548

It's great that the name "dpdk" is pinned down - thanks. But we need to
define the sover also, and make sure it is bumped when the ABI changes.
AIUI the build currently produces no sover - is this correct?

We'll use a sover of 0 in our packaging for now, unless you object. Then
we'll be able to move up to whatever you do when it is well-defined.

> > So that we can get DPDK packaging into Ubuntu immediately, please could
> > we agree to define (and burn) libdpdk.so.0 to be the ABI that builds
> > with upstream release 2.0.0 when built with the native-linuxapp-gcc
> > template options plus the following changes:
> >     CONFIG_RTE_MACHINE=”default”
> >     CONFIG_RTE_APP_TEST=n
> >     CONFIG_LIBRTE_VHOST=y
> >     CONFIG_RTE_EAL_IGB_UIO=n
> >     CONFIG_RTE_LIBRTE_KNI=n
> >     CONFIG_RTE_BUILD_COMBINE_LIBS=y
> >     CONFIG_RTE_BUILD_SHARED_LIB=y
> 
> I feel this configuration is the responsibility of the distribution.
> What do you expect to have in the source project?

I just wanted to make it clear what we were doing in case changing build
configuration parameters resulted in a different ABI. If this isn't the
case, then that's fine - it is solely the consider of the distribution
as to what build parameters we pick.

> > The combined library would be placed into /usr/lib/$(ARCH)-linux-gnu/
> > where it can be found without modification to the library search path.
> > We want to ship it like this in Ubuntu anyway, but I’d prefer upstream
> > to have defined it as such since then we’ll have a proper definition of
> > the ABI that can be shared across distributions and other consumers any
> > time ABI compatibility is expected.
> 
> You mean you target ABI compatibility between Linux distributons?
> But other libraries could have different versions so you would be lucky
> to have a binary application finding the same dependencies.

In theory we do get ABI compatibility between distributions. Finding the
dependencies is a separate issue; but if the right binaries were
installed, there would be no conflicts in finding shared libraries
across binaries from different distributions if the ABI is managed
right.

But that isn't directly our target.

It's still useful to us to have this done right. It makes ABI
transitions in the distribution (coordinating updates to libraries and
their consumers concurrently) possible without breaking things in the
middle. It means that when we talk to upstreams (both libraries and
their consumers) then we're speaking the same language as other
distributions, and patches apply to them all without each distribution
having to kludge things independently. And it gives us options when
different library consumers require different ABI versions since we can
concurrently install two different ABIs of the same library (although we
prefer to avoid that).

> > Though not strictly part of a shared library ABI, I also propose some
> > build-related upstream changes at API level below, that I’d like to also
> > ship in the initial Ubuntu packaging of the header files. Clearly you
> > cannot make this change in an existing release, but I propose that you
> > do this for your next release so all library consumers will see a
> > consistent and standard API interface. If you agree to this, then I’d
> > also like to ship the Ubuntu package with patches to do the same thing
> > in your current release.
> 
> Yes cleanup patches are welcome :)

I'm arranging to have someone work on these with you upstream and send
you patches, thanks.

Robie