Posted by P4.org on July 13, 2015
Open vSwitch (“OVS”) is a virtual switch that is commonly used with Linux-based hypervisors such as KVM and Xen, although it supports other environments too such as FreeBSD and Hyper-V. Surveys have reported that OVS is the most popular networking plugin for the widely adopted OpenStack cloud management system. OVS is also popular in research: Google Scholar reports about 1,600 scholarly works that mention it.
Most releases of Open vSwitch add support for new network protocols or for fields within a given network protocol. Until now, every new field or protocol change has required changes across multiple locations in the OVS source tree. In turn, every change to the OVS source requires the overhead of building, distributing, and installing a new version of OVS on each system that uses it. In a cloud environment this usually means that every hypervisor needs a significant software update to support newly defined packet fields, protocol changes, or other data plane changes. Many of these changes also require building a new Linux kernel module for each type of target system. That’s a painful requirement and puts onerous workloads on system adminstrators, and ultimately makes it much more difficult for controller authors to take advantage of new protocols.
It would be great to avoid all of these problems. In my opinion, software-defined networking isn't really complete until the various network protocols, and not just the handling of network packets, can be defined by flexible and reconfigurable software. Years ago I tried sketching out a couple of possible approaches, but each approach I came up with either seemed too inflexible to work with real network protocols or so general that it simply became another embedded programming language. That's why I was so pleased when I first read a pre-release draft of the P4 specification. From my point of view, it strikes the right balance along the spectrum from fixed support for protocols to a general-purpose programming language.
My vision for P4 in Open vSwitch is that it can be used to reconfigure the protocols and fields that OVS supports at runtime, without recompiling, reinstalling, or restarting OVS. This is not an easy task: due to the need for backward compatibility we don't think that users would accept a new version with compatibility regressions. Of course, performance also matters here: of particular interest is the field extraction and header parsing code. Our profiling work has shown this is often the critical path when determining overall OVS performance, so optimization work here can provide substantial benefits.
To learn whether this vision is a realistic one, I spent about a week late this spring doing some experiments. I wrote C code for a P4 syntax lexer and, using that, a parser for a P4 language subset that included the header_type, header, and parser elements of the language. I also wrote a compiler that accepts the P4 parser's output and emits code in a RISC-like bytecode, called "eBPF". eBPF is increasingly used in the Linux kernel to allow user programs to safely implement sophisticated features; the Linux kernel includes an eBPF bytecode verifier and a multi-architecture JIT engine that allows eBPF to achieve near-native performance.
All of this was far from production quality, but it effectively modeled the means by which Open vSwitch could put a reconfigurable protocol engine into the Linux kernel. That covered the Linux kernel module based "datapath" for the OVS software switch, which is currently the most popular datapath. To increase my confidence by modeling support for the OVS's increasingly popular DPDK-based userspace datapath, I also implemented an eBPF interpreter in OVS userspace. (For production use this would be replaced by a userspace JIT engine or another way to generate native code.)
I went into my prototyping exercise with legitimate questions about the value of P4 in Open vSwitch. After working through this, I'm now confident that protocol reconfigurability is practical and adds real value to the OVS tree. Numerous questions remain about the relationship between P4, OpenFlow, and OVS -- but I'm excited about the possibilities. If we do it correctly OVS can become more useful, easier for developers to understand and maintain, and perhaps even faster. I'm looking forward to building and helping others build in that new direction.
This blog is based on my talk at the June 4, 2015 P4 Workshop. The slides for that talk are available at http://p4.org/p4-workshop/. The code for the prototype mentioned in this blog is available at https://github.com/blp/ovs-reviews/tree/p4-workshop and will be contributed to https://github.com/p4lang.
About the author: Ben Pfaff is a lead developer of the Open vSwitch project. He was a co-creator of OpenFlow and led the development effort of the original OpenFlow reference implementation. He was a founding employee at Nicira and is currently at VMware. He received his PhD from Stanford University in 2007. Ben has worked in free and open source software projects, including Debian and GNU, for over 20 years.
