SRU MRE Exception for DPDK

Christian Ehrhardt christian.ehrhardt at
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 [1] 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 [2] 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 [3] 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 [4].

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 [5] 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 [6]
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 [7] 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
the archive).

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 [8] 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




Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

More information about the technical-board mailing list