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

[Thomas Monjalon <thomas.monjalon@6wind.com>]

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