Can the Open vSwitch (OVS) bottleneck be resolved? - Erez Cohen - OpenStack Day Israel 2017
Download as PPTX, PDF1 like1,251 views
The document discusses the challenges and solutions related to Virtual Switch (vSwitch) performance in cloud environments, particularly with Open vSwitch (OVS) and hardware acceleration. It emphasizes the need for low-level building blocks and integration within open-source frameworks to improve performance, reduce CPU overhead, and enhance efficiency for network demanding applications. Additionally, it outlines the status of community contributions and potential future applications of the proposed solutions.
Can the Open vSwitch (OVS) bottleneck be resolved? - Erez Cohen - OpenStack Day Israel 2017
- 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