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 spots, 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 the 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 out 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 tunneling has. - Documentation: other than a step by step tutorial, it cannot be said that DPDK is a first class citizen in the OVS documentation. Manpages could be improved. - Vhost: the code has not received the level of testing of the kernel vhost. 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 can 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 datapath? - 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 there only be a single build to handle both the kernel and the userspace datapath, eventually dynamically linked to DPDK? - Benchmarks: we often rely on extremely simple flow tables with single flow traffic to evaluate the effect of a change. That may be ok during development, but OVS with the kernel datapath has been tested in different scenarios with more complicated flow tables and even with hostile traffic patterns. Efforts in this sense are being made, like the vsperf project, or even the 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. Cheers, Daniele _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
