SRU MRE Exception for DPDK
christian.ehrhardt at canonical.com
Thu Dec 14 09:39:04 UTC 2017
Hi Technical Board
I'd like to apply for a Minor Release Exception for the DPDK package.
If you want me to join a TB meeting please let me know, but I wanted
to give everyone the chance to read into the details before "just
showing up on the agenda".
DPDK was included in Ubuntu main during the 16.04 release cycle; since
then upstream DPDK have started maintaining LTS releases of DPDK;
At least for our LTS releases we try to base on DPDK LTS releases
The first one was 16.11 which shipped in Zesty, and the next DPDK LTS
will be 17.11 which is our target for Ubuntu 18.04 Bionic Beaver.
DPDK is a set of libraries and userspace drivers for fast packet
processing. It is designed to run on any processors. The first
supported CPU was Intel x86 and it is now extended to IBM POWER
and ARM. It runs mostly in Linux userland.
Having a MRE for DPDK will ensure that users of DPDK receive timely
critical updates to this software.
Upstream Change and Release Policy
Upstream have a policy  for accepting changes into the LTS release
branches which includes:
- Back-porting of any critical bug fixes (crashes, data loss, etc)
- Minor usability items that are very low risk
- Only changes are backported that are part of the last main release
(This ensures more test coverage on those changes)
There is a section on backporting features as well, but the
constraints limit it to something that is IMHO sane to SRU:
- There is a justifiable use case (for example a new PMD).
- The change is non-invasive.
- There is support within the community.
This so far happened very rarely and In addition those features
(mostly PMDs to support more HW) are only added in stable
releases being not built by default. For packaging that means
this is a no-op as we won't enable it so nothing changes.
Commits are peer reviewed as part of the normal development process
and are signed to signify both the developer and review (see  for
the doc on this).
LTS release updates are made after some time has passed (to allow
testing) and usually follow the new master release which happens
more or less every 3 months (see  for the current road-map).
Updates to LTS releases are numbered with a minor point release
16.11: 16.11.1, 16.11.2, ...
17.11: 17.11.1, 17.11.2, ...
I watched the DPDK 16.11.x LTS release as it was the first of its
kind and it was great. Due to the fast pace of DPDK development with
3 month release cycles a stable release is very important to carry
the stability needed by Distribution LTS releases.
Therefore I now plan to:
- release Ubuntu 18.04 with the first stable release 17.11.1
- Ask for this MRE to keep up with further stable releases
Upstream Regression Testing
The upstream DPDK regression suite is a mix of comprehensive
functional tests (API coverage, etc.) and stress workloads via packet
generators. The full set is defined at .
The QA suite is run against the branches regularly to
hunt for low-frequency problems. Everything should be tested
regularly, and all but the most recent patches have been tested over
and extended period of time.
Results are published via email to the dpdk-test-report mailing list
(see  for examples).
In addition there is a smaller set of integration tests that runs
pre-checks. This is integrated into patchwork to directly augment
the patch review.
Those checks were run by Intel so far but are currently extended
to be a Hardware vendor opt-in to gain even more coverage - see 
for details on this growing part of the project that will provide
even more coverage.
Ubuntu DPDK Testing
DPDK has very high constraints on the environment (a lot of memory,
huge pages, certain CPU features) as well as the Hardware (limited
to a set of cards that have PMDs).
Therefore we have a test  set outside of autopkgtest that tries to
cover the basic use case we know users have in mind (you can
use DPDK for way more, but we want and can only test what is in
In particular this sets up a set of KVM guests and runs a few test
tools to finally set up a dpdk enabled Open vSwitch between them.
On this dpdk enabled Open vSwitch it then runs some benchmarks to
ensure no significant performance loss (compared manually for now)
and some endurance tests via re-attaching devices or re-starting
guests (all those based on lessons learned by past issues we
In addition, we set up autopkgtests  as well for those components
that can be tested. Those are mostly the extra packaging bits that
would not be covered by the upstream testing:
- testing the init scrips
- testing dkms modules work withing Ubuntu
- testing the correct linking of builds against dpdk
Note: We also test the dpdk autotests in autopkgtests but for the
constraints mentioned before they are not reliable in the environment
they run in and thereby not yet gating.
Proposed SRU Approach
SRU updates for DPDK in Ubuntu will be aligned to the associated LTS
release of DPDK and only taken care for Ubuntu LTS releases:
18.04 -> DPDK 17.11.x
20.04 -> DPDK 19.11.x (if releases still align)
Ubuntu will only use the released version of updates and will not pull
directly from the upstream VCS. That is important as on the release of
a DPDK LTS there is another test/verification loop that we want to see
Proposed packages will be prepared, uploaded and tested both
standalone and in-conjunction with Open vSwitch (following the
methodology detail above) as part of the standard SRU verification
process for packages with MRE's.
I hope this information gives the technical board sufficient
confidence that DPDK is worthy of a minor release exception for SRU
Software Engineer, Ubuntu Server
More information about the technical-board