[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