[ovs-dev] Status of Open vSwitch with DPDK

Daniele Di Proietto diproiettod at vmware.com
Wed Aug 12 21:34:40 UTC 2015

There has been some discussion lately about the status of the Open vSwitch
port to DPDK.  While part of the code has been tested for quite some time,
I think we can agree that there are a few rough spots that prevent it from
being easily deployed and used.

I was hoping to get some feedback from the community about those rough
i.e. areas where OVS+DPDK can/needs to improve to become more "production
ready" and user-friendly.

- PMD threads and queues management: the code has shown several bugs and
  netdev interfaces don't seem up to the job anymore.

  There's a lot of margin of improvement: we could factor out the code from
  dpif-netdev, add configuration parameters for advanced users, and figure
  a way to add unit tests.

  Related to this, the system should be as fast as possible out-of-the-box,
  without requiring too much tuning.

- Userspace tunneling: while the code has been there for quite some time it
  hasn't received the level of testing that the Linux kernel datapath

- Documentation: other than a step by step tutorial,  it cannot be said
  DPDK is a first class citizen in the OVS documentation.  Manpages could

- Vhost: the code has not received the level of testing of the kernel
  Another doubt shared by some developers is whether we should keep
  vhost-cuse, given its relatively low ease of use and the overlapping with
  the far more standard vhost-user.

- Interface management and naming: interfaces must be manually removed from
  the kernel drivers.

  We still don't have an easy way to identify them. Ideas are welcome: how
  we make this user friendly?  Is there a better solution on the DPDK side?

  How are DPDK interfaces handled by linux distributions? I've heard about
  ongoing work for RHEL and Ubuntu, it would be interesting to coordinate.

- Insight into the system and debuggability: nothing beats tcpdump for the
  kernel datapath.  Can something similar be done for the userspace

- Consistency of the tools: some commands are slightly different for the
  userspace/kernel datapath.  Ideally there shouldn't be any difference.

- Packaging: how should the distributions package DPDK and OVS? Should
  only be a single build to handle both the kernel and the userspace
  eventually dynamically linked to DPDK?

- Benchmarks: we often rely on extremely simple flow tables with single
  traffic to evaluate the effect of a change.  That may be ok during
  development, but OVS with the kernel datapath has been tested in
  scenarios with more complicated flow tables and even with hostile traffic

  Efforts in this sense are being made, like the vsperf project, or even
  simple ovs-pipeline.py

I would appreciate feedback on the above points, not (only) in terms of
solutions, but in terms of requirements that you feel are important for our
system to be considered ready.



More information about the dev mailing list