Committers to the Open vSwitch (OVS) project have made tweaks that boost Open vSwitch performance to “ludicrous” speed, as they put it.

It's work that has gone on for a while, but the details are summarized in a posting on the Network Heresy blog today. The team is also discussing the improvements in more detail today as part of an Open vSwitch conference being held at VMware headquarters in Palo Alto, Calif.

OVS's core problem — one that's been a priority for the team in the past year or two — was that it was spending too much time processing requests in Linux user space, also called the slow path. (The alternative is kernel space, the fast path.) Earlier, the team was able to improve performance in small increments — “10 percent or 20 percent faster, and we were patting ourselves on the back,” Justin Pettit, VMware staff engineer (and a conference organizer) tells SDxCentral. But a bigger push was needed.

The central issue was that OVS was scanning the entire packet header and looking for for exact matches in its flow cache. In other words, it was too picky about deciding whether it knew what to do with a flow; anything without an exact match got kicked into the slow path.

This got addressed in OVS version 1.11. (OVS is up to version 2.3 now.) It introduced the concept of a megaflow — the ability to use wildcards for some cache fields, essentially, so the OVS can more quickly decide what to do with a flow.

User space was also single-threaded, so a multithreaded version got introduced with OVS 2.0. This helped the switch get closer to handling traffic in real time. The kernel cache also grew, to 200,000 flows from 1,000 previously.

Both improvements let the OVS team improve the classifier, the code that decides which OpenFlow rules apply to a packet. Capabilities added there include prioritized sorting of search results and the ability to do a staged lookup, which applies to policies that apply to just a subset of headers.

This all adds up to a performance boost. Exactly what constitutes “ludicrous” speed is up to the user — or, actually, up to Rackspace, which used the term in an OpenStack Summit presentation on the topic a couple of weeks ago. The OVS team isn't promising specific numbers, but the Network Heresy blog lists the results of one test against the Linux bridge (the default switching option in Linux).

With performance taken care of (for now), the next steps for OVS will likely involve moving up the stack. “We're pretty good in the Layer 2-3 space, but people are interested in going to Layer 4-7,” Pettit says.

Specifically, Pettit and colleagues at the conference are discussing ways to add a stateful firewall (likely to come with OVS version 2.4, which might arrive early next year), network address translation (NAT), and deep packet inspection.

The challenge is that these are stateful functions being imported into OpenFlow's stateless world. “How do we define it in such a way that OpenFlow can make use of it?” Pettit says. The OVS team's answer focuses on using the connection tracking mechanism in Linux; you can check out some of the related code on Github.

Other future directions for OVS involve supporting environments other than Linux's KVM, such as Microsoft's Hyper-V hypervisor and Intel's Data Plane Developer Kit (DPDK).

(Photo: Thomas Graf of Noiro Networks and Justin Pettit of VMware, presenting at the Open vSwitch conference today.)