What to Accelerate?

Software data processing is de facto the next very popular topic today after ASIC packet processors, both for telecom and data centers.

However, the main question is – What to accelerate? A virtual Switch or Linux native data path?

There are different types of data paths presented today in Linux environment.

The first option is the native Kernel flow presented by TCP/IP stack. The network device pre-allocates a number of sk_buffs for reception. How many, is configured per device. Usually, the addresses to the data space in those sk_buffs are configured directly as DMA area for the device. The device interrupt handler takes the sk_buff and performs reception handling on it. In NAPI, it is done in two phases: First, from the interrupt handler, the device driver just calls netif_rx_schedule and returns from interrupt, which forwards action to the device’s poll virtual method and finally pass the sk_buff to upper layers.

In that option, the packet goes either to TCP/IP in the local application or to data processing in ebtables and iptables: for NAT, FW, or any other type of data forwarding. This method had been used for many years, and in the era of SDN was transferred into vSwitch option.

vSwitch or Open vSwitch, sometimes abbreviated as OVS, is a production-quality open-source implementation of a distributed virtual multilayer switch. The main purpose of Open vSwitch is to provide a switching stack for hardware virtualization environments, while supporting multiple protocols and standards used in computer networks. OVS was introduced for SDN and armed with basic L2 functions and flow manipulations aligned with OF (Open Flow), and currently is matching OFv1.4. By the way, there is an alternative vRouter, also presented in Linux.

vSwitch data path was firstly introduced in Kernel, moved after that to Linux space to reduce CPU IO overhead upon process context switching during data flow forwarding, and now with DPDK environment becomes more and more popular for NFV implementations.

Each Linux data processing model requires CPU resources. In addition, different markets will require more and more complex packet manipulations: VxLAN and Geneva tunnels for DCE; header alterations for vCPE and vIoT solutions; OAM and time stamping for monitoring. Those and many other functions once moved into cloud will take a lot of CPU resources, and it goes without saying that in 1-2 years telecom service providers will ask for some optimization. That is why Mellanox, Intel and others are acquiring network-processing companies to accelerate data forwarding.

vSwitch in Kernel has actually already started this process: Switchdev initiative enables offload integration module with some L2 and L3 functions (see On the contrary, DPDK approach assumes that all data would be proceeded within CPU. The last option seemingly will shortly reach the “saturation”: it does not make sense to buy more and more servers to support many NFs.

So the main question for any company deciding to propose an acceleration solution for software data path: what is the best possible option to do?