| 2015-09-04 09:58:13 |
Stefan Bader |
bug |
|
|
added bug |
| 2015-09-04 09:58:35 |
Stefan Bader |
bug |
|
|
added subscriber Leann Ogasawara |
| 2015-09-04 09:58:46 |
Stefan Bader |
bug |
|
|
added subscriber Chris J Arges |
| 2015-09-04 09:59:07 |
Stefan Bader |
bug |
|
|
added subscriber Robie Basak |
| 2015-09-04 10:12:26 |
Stefan Bader |
ubuntu: status |
New |
Incomplete |
|
| 2015-09-04 10:12:37 |
Stefan Bader |
information type |
Private |
Public |
|
| 2015-09-04 10:12:54 |
Stefan Bader |
description |
*** Private as long as still processing FFE and filling in the template ***
[Availability]
The source code is available from: git://dpdk.org/dpdk
General information: http://dpdk.org
[Rationale]
The DPDK library will be a build dependency for openvswitch package (extra variant using DPDK instead of kernel network stack). Potentially there will be more projects doing the same, so this should be part of the endorsed set of packages.
[Security]
[Quality assurance]
[Dependencies]
texlive-fonts-extra is in universe (!)
[Standards compliance]
[Maintenance]
[Background information]
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.
Can we only put the source and both library package into main and by that avoid the dependency issue? |
*** Still processing FFE and filling in the template ***
[Availability]
The source code is available from: git://dpdk.org/dpdk
General information: http://dpdk.org
[Rationale]
The DPDK library will be a build dependency for openvswitch package (extra variant using DPDK instead of kernel network stack). Potentially there will be more projects doing the same, so this should be part of the endorsed set of packages.
[Security]
[Quality assurance]
[Dependencies]
texlive-fonts-extra is in universe (!)
[Standards compliance]
[Maintenance]
[Background information]
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.
Can we only put the source and both library package into main and by that avoid the dependency issue? |
|
| 2015-09-07 09:01:32 |
Nobuto Murata |
bug |
|
|
added subscriber Nobuto Murata |
| 2015-10-07 22:08:58 |
Leann Ogasawara |
affects |
ubuntu |
dpdk (Ubuntu) |
|
| 2015-11-16 08:59:02 |
Christian Ehrhardt |
description |
*** Still processing FFE and filling in the template ***
[Availability]
The source code is available from: git://dpdk.org/dpdk
General information: http://dpdk.org
[Rationale]
The DPDK library will be a build dependency for openvswitch package (extra variant using DPDK instead of kernel network stack). Potentially there will be more projects doing the same, so this should be part of the endorsed set of packages.
[Security]
[Quality assurance]
[Dependencies]
texlive-fonts-extra is in universe (!)
[Standards compliance]
[Maintenance]
[Background information]
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.
Can we only put the source and both library package into main and by that avoid the dependency issue? |
*** 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-openstack-dpgk.
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.
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
TODO - clarify with Stefan: the package should either provide a debian/README.source file or a debian/watch file (with comments only) providing clear instructions on how to generate the source tar file.
[UI Standards]
This does not apply to a library, so we should be fine on this part.
[Dependencies]
texlive-fonts-extra is in universe - we are currently working on removing that dependency (Plan end of November)
[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.
We won't be able to change that without a tremendous unmaintainable ubuntu delta to upstream.
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 xenial - but at least it is being worked on and will one day comply.
TODO - check FSH in detail
TODO - check Debian policy
[Maintenance]
TODO - clarify with Stefan
[Background information]
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.
Can we only put the source and both library package into main and by that avoid the dependency issue? |
|
| 2015-11-16 12:41:27 |
Christian Ehrhardt |
description |
*** 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-openstack-dpgk.
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.
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
TODO - clarify with Stefan: the package should either provide a debian/README.source file or a debian/watch file (with comments only) providing clear instructions on how to generate the source tar file.
[UI Standards]
This does not apply to a library, so we should be fine on this part.
[Dependencies]
texlive-fonts-extra is in universe - we are currently working on removing that dependency (Plan end of November)
[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.
We won't be able to change that without a tremendous unmaintainable ubuntu delta to upstream.
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 xenial - but at least it is being worked on and will one day comply.
TODO - check FSH in detail
TODO - check Debian policy
[Maintenance]
TODO - clarify with Stefan
[Background information]
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.
Can we only put the source and both library package into main and by that avoid the dependency issue? |
*** 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.
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
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
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)
[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)
[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.
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. |
|
| 2015-11-16 12:42:14 |
Christian Ehrhardt |
bug |
|
|
added subscriber ChristianEhrhardt |
| 2015-11-19 14:01:38 |
Christian Ehrhardt |
description |
*** 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.
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
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
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)
[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)
[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.
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. |
*** 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 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. |
|
| 2015-11-19 14:04:01 |
Christian Ehrhardt |
description |
*** 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 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. |
*** 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. |
|
| 2015-11-19 16:23:38 |
Christian Ehrhardt |
bug |
|
|
added subscriber MIR approval team |
| 2015-11-19 16:32:14 |
Michael Terry |
dpdk (Ubuntu): assignee |
|
Jamie Strandboge (jdstrand) |
|
| 2015-12-04 15:34:27 |
Nick Brown |
bug |
|
|
added subscriber Nick Brown |
| 2015-12-16 17:36:49 |
Tyler Hicks |
dpdk (Ubuntu): importance |
Undecided |
High |
|
| 2015-12-16 17:36:49 |
Tyler Hicks |
dpdk (Ubuntu): status |
Incomplete |
In Progress |
|
| 2015-12-16 17:36:49 |
Tyler Hicks |
dpdk (Ubuntu): assignee |
Jamie Strandboge (jdstrand) |
Seth Arnold (seth-arnold) |
|
| 2016-01-20 17:36:01 |
Jon Grimm |
bug |
|
|
added subscriber Jon Grimm |
| 2016-02-11 02:57:55 |
Seth Arnold |
bug |
|
|
added subscriber Seth Arnold |
| 2016-02-11 02:57:58 |
Seth Arnold |
dpdk (Ubuntu): assignee |
Seth Arnold (seth-arnold) |
|
|
| 2016-02-11 21:37:25 |
Michael Terry |
dpdk (Ubuntu): status |
In Progress |
Incomplete |
|
| 2016-02-24 11:46:48 |
Christian Ehrhardt |
bug watch added |
|
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815760 |
|
| 2016-02-24 14:02:47 |
Michael Terry |
dpdk (Ubuntu): status |
Incomplete |
Fix Committed |
|
| 2016-02-24 14:45:25 |
Matthias Klose |
dpdk (Ubuntu): status |
Fix Committed |
Fix Released |
|
| 2016-02-24 21:43:10 |
James Page |
bug task added |
|
openvswitch (Ubuntu) |
|
| 2016-02-25 08:07:49 |
Launchpad Janitor |
openvswitch (Ubuntu): status |
New |
Fix Released |
|
