OpenStack practitioners who have deployed cloud at scale would frown when they hear the mention of Open Virtual Switch (OVS), which has been a bottleneck for cloud network performance and scalability. As emerging technologies such as NFV keep pushing for higher data forwarding performance across the network infrastructure, it becomes critical to improve OVS performance without compromising flexibility, network programmability, and cost. We will present a novel way to offload the entire OVS dataplane onto the embedded switch (eSwitch) implemented in the server NIC. This approach maximizes the effective bandwidth that the applications can use to communicate with each other or fetch data from storage, and enhances the efficiency of the cloud. Accelerated Switching And Packet Processing (ASAP2) Direct works seamlessly within the framework of SDN, and allow controllers to configure and update flows onto OVS the same way as before so that network programmability remains intact.

1. © 2017 Mellanox Technologies 1
OpenStack Day Israel 2017
Erez Cohen, VP CloudX Program
Can Open vSwitch Bottlenecks Be Resolved?

2. © 2017 Mellanox Technologies 2
What Is vSwitch?
▪ Virtual Switch (vSwitch) provides switching (and sometime routing) services to VMs within a host
▪ Open vSwitch (OVS) is the most popular vSwitch
• Flow based switch/router
▪ vSwitch is typically controlled by an SDN controller
Para-Virtualized
NIC
Hypervisor
vSwitch
VM VM

3. © 2017 Mellanox Technologies 3
vSwitch Challenges
▪ Message per second
▪ Latency
▪ Jitter
▪ CPU overhead
Para-Virtualized
NIC
Hypervisor
vSwitch
VM VM
Challenging For Network Demanding Applications (i.e., NFV)
• Slow
• Unpredictable
• Inefficient
Executed on the
main x86 CPU

4. © 2017 Mellanox Technologies 4
The Solution: Hardware Acceleration!
▪ Virtualization, Containers and Software defined Networks are key for todays clouds
▪ SDN solutions provide (almost) the needed functionality but lacking the performance
▪ To gain both flexibility and cost efficiency Hardware Acceleration is needed
HW Acceleration Can Reduce Servers Footprint by 10x to 100x
Software Software + Hardware Acceleration

5. © 2017 Mellanox Technologies 5
Hardware Acceleration Challenges
▪ Many different HW architectures
▪ Operating systems support
▪ Orchestration support
▪ Application level support

6. © 2017 Mellanox Technologies 6
Top Down Architecture
▪ Top down architecture is very challenging
• Very comprehensive (not only network)
• Many layers: orchestration, virtualization, OS, hardware
• A lot of intergroup projects dependencies
▪ Multiple attempts, non materialized

7. © 2017 Mellanox Technologies 7
Bottom Up, Open Source Architecture
▪ Hardware to implement common, low level building blocks
▪ Define APIs in open source consortiums such as Linux Kernel
▪ Integration into high level open source frameworks and application such as OpenStack and OVS

8. © 2017 Mellanox Technologies 8
OVS Acceleration
▪ Hardware enablement
• Powerful, flexible and programmable flow based switch in NIC

9. © 2017 Mellanox Technologies 9
Para-Virtualized SR-IOV
▪ PCIe device presents multiple instances to the OS/Hypervisor
▪ Enables Application Direct Access
• Bare metal performance for VM
• Reduces CPU overhead
▪ Enable RDMA to the VM
• Low latency applications benefit from the Virtual infrastructure
A word about Single Root I/O Virtualization (SR-IOV)
Bare Metal
Latency
Bare Metal
BW
NIC
Hypervisor
vSwitch
VM VM
SR-IOV NIC
Hypervisor VM VM
eSwitch
Physical Function
(PF)
Virtual Function
(VF)

10. © 2017 Mellanox Technologies 10
OVS Offload / Acceleration with ASAP2
OVS Offload OVS acceleration

11. © 2017 Mellanox Technologies 11
Application Acceleration with ASAP2
ConnectX 4 eSwitch
VM
Hypervisor
OVS
SR-IOV
VF
DataPath
PF
TC/DPDKOffload
Application
Application
Acceleration

12. © 2017 Mellanox Technologies 12
Open Source Communities Impacted
▪ Linux kernel community
• Representor ports
• TC (Traffic Control) HW offload (flower)
▪ DPDK community
• Flow offload directly from DPDK
▪ OVS user space community
• Policy mechanism
• Flow offload via TC / DPDK
▪ OpenStack community
• OVS ML2 driver to bind with Direct port type
HW Vendor Agnostic!

13. © 2017 Mellanox Technologies 13
OVS over DPDK VS. OVS Offload
▪ Zero CPU utilization on hypervisor
compared to 2 cores with OVS over
DPDK
• Same CPU load on VM
Test OVS DPDK ASAP2 Direct
1 Flow 7.6M PPS 33M PPS
60K flows 1.9M PPS 16.4M PPS

14. © 2017 Mellanox Technologies 14
Status And Availability
▪ Linux kernel fully upstream (kernel 4.13 and newer)
▪ OVS user space in final integration phases
▪ DPDK APIs upstream
▪ OpenStack blueprints and patches submitted and
tentatively accepted
• Pending OVS user space
▪ key Linux and OpenStack distributions backporting,
integrating and testing

15. © 2017 Mellanox Technologies 15
Additional Potential Usage For ASAP2 - Cloudigo
▪ Cloudigo - Serverless Network Services
20% Other…
CLOUDIGO SW PROGRAMMABLE ENGINE
NAT FW DDoS LB
User
Defined
ASIC Layer - NIC Adapter
Offload Learning Engine

16. © 2017 Mellanox Technologies 16
Additional Potential Usage For ASAP2
▪ vSwitches/vRouters
• FD.IO / VPP
• OpenContrail / vRouter
▪ Application / VNFs
• vRouters
• CDNs
• vBRAS
• vRAN
• And many more

17. © 2017 Mellanox Technologies 17
Thank You
Erez Cohen: erezc@mellanox.com