** Description changed: *** 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 - [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 test suite http://dpdk.org/doc/dts/gsg/config.html - but it is extremely complex and therefore does not qualify for a build - level verification. Still it could and should one day become part of - manual QA on that package. + 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 consuming packages like - openvswitch-switch-dpdk + 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. - There is no debian/README.source file or a debian/watch file providing - clear instructions on how to generate the source tar file, but Stefan is - working on that (Target End of November) - + 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] - texlive-fonts-extra is in universe - we are currently working on removing that dependency (Plan end of November) - + 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?) + - 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 + - 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. + 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. The texlive-fonts-extra build dependency only is - required to process the dpkd-doc binary(-indep) package - but we work on - removing it the dependency anyway. + required to be in main.
** Description changed: *** 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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1492186 Title: [MIR] dpdk To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dpdk/+bug/1492186/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
