*** Still processing FFE and filling in the template ***
[Availability]
The source code is available from: git://dpdk.org/dpdk
General information: http://dpdk.org
The package is already part of universe and builds for the target architecture https://launchpad.net/ubuntu/+source/dpdk/2.0.0-0ubuntu1
In the Xenial cycle we intend to upgrade to 2.2 which gets released end of November which - due to being more recent should be good for maintenance and security.
[Rationale]
The DPDK library will be a build dependency for openvswitch package (extra variant using DPDK instead of kernel network stack).
So it will be useful for a large part of our user base around OpenStack.
Potentially there will be more projects doing the same, so this should be part of the endorsed set of packages.
[Security]
As of today there are no known CVEs nor any advisories on Secunia.
There is only one /sbin executable in the form of /sbin/dpdk_nic_bind to get a hold on the network devices.
There is one service that gets started in the form of /etc/init.d/dpdk which eventually comes down to "/lib/dpdk/dpdk-init --start"
It does not have privileged privileged ports (ports < 1024) bound.
[Quality assurance]
While configuration is quite complex, since the dpdk package itself is only a library it does not require *user* configuration. That is a job of the consumers of the library e.g. openvswitch-switch-dpdk.
There are no long-term outstanding bugs which affect the usability of the program to a major degree. Upstream is very active and supports and cares for the package.
There is no Debian package to consider and the Ubuntu bug tracking system currently only hold this MIR request as an open bug.
https://bugs.launchpad.net/ubuntu/+source/dpdk
The package in the meantime supports various network cards and even virtio-net so not only exotic hardware that we cannot support.
The package ships a full test suite as can be seen on http://dpdk.org/doc/dts/gsg/config.html but it is extremely complex. Still it could and should one day become part of semi-manual QA on that package.
There is a quick test which requires network, but not really network access (to the outside) that might be possible to implement as a Dep8 test for build time http://dpdk.org/doc/quick-start
Both the testsuite as well as the easy testpmd do not qualify for a build level verification - because due to the way it works it always starts with "consuming" network devices which violates the constraints of the build environment.
Due to the nature of this "only" being a library real tests should and to some extend can only be handled in the depending packages like openvswitch-switch-dpdk - but even there most of the constraints will dis-qualify it for a build test.
We added a debian/watch to indicate clear instructions on how to generate the latest source tar file
[UI Standards]
Does not apply to a library
[Dependencies]
Just removed the last universe dependency being texlive-fonts-extra in an upload to the xenial version which is currently in review (2.0.0-0ubuntu2)
[Standards compliance]
As of today the upstream version has some conflicts regarding the FHS compliance related to the positioning and versioning of headers and libraries.
This was discussed and upstream DPDK is willing to accept patches to fix that. But due to the roadmap it won't be possible to get that soon enough for the initial release of this packet in main with xenial - but at least it is being worked on and will one day comply without so much Ubuntu delta.
The current packaging tries to minimize this as much as possible:
- libdpdk - only the lib in standard path /lib
- the lib there is kind of the lowest denominator, only requires sse3
- the library tries to detect on load and opimizes as good as possible
- some further optimizations need upstream changes to enhance detection
(gnu ifunc?)
- libdpdk-dev - provides the header in standard pfad - /usr/include/dpdk
- dpdk-dev - represents the way upstream handles it but with all content
- below /usr/share/dpdk. Links back to the other two packages to avoid
redundancy
What is missing is proper so library versions, but we can't define those without upstream.
FYI - In Kernel we already have drivers for virtual function I/O and pci based cards. So there is no need to per device libraries as it was in the beginning.
There is no major violation of the Debian policy and not a lot of conflict since there is no Debian package as of today.
[Maintenance]
The Server Team will be responsible.
[Background information]
General purpose of the package is a performance improvement on handling network packets in userspace. There it can drop the generic approach of a kernel IP stack and focus on performance. At the same time it is highly optimized for latency by using concurrent threads, huge pages and even polling to some extend.
Of the produced binary packages only libdpdk0 and libdpdk-dev would be required to be in main.
We can't have texlive-fonts-extra as a build dependency if it is in universe. We can put some binaries that we build in universe, but the build itself must be able to operate entirely out of main. During the build of a source package that is in main, universe is not in sources.list and so the build would fail otherwise.
Can we pull texlive-fonts-extra out of the build depends but arrange the build to still succeed? If we miss building some specific version of the documentation then that's OK, though preferably we'd still have non-TeX documentation available.