How to Supercharge Kube-OVN Performance: Benchmarks and Tuning Guide

Introduction

Kube-OVN brings rich SDN capabilities to cloud‑native environments, but its default installation script does not include performance‑specific optimizations. This document explains how to benchmark and tune Kube-OVN for latency‑sensitive or high‑throughput workloads.

Benchmark Overview

All tests were run on a Kubernetes 1.22 cluster (CentOS 7) with Kube-OVN 1.8.0, Intel Xeon E‑2278G CPUs and 2×10 Gbps NICs. The qperf tool was used to measure TCP/UDP bandwidth and latency for 1 byte, 1 KB, and 4 KB packets before and after optimization, as well as against the host network and alternative CNI solutions (Calico, Underlay). Results are shown in the accompanying charts.

Example command:

qperf -t 60 <server ip> -ub -oo msg_size:1 -vu tcp_lat tcp_bw udp_lat udp_bw

In some cases the optimized container network outperforms the host network because it bypasses netfilter, whereas host traffic always traverses kube‑proxy and netfilter.

Data‑Plane Performance Optimization

CPU Performance Mode

Switch the CPU from power‑saving to performance mode to eliminate latency spikes.

cpupower frequency-set -g performance

NIC Hardware Queue Adjustment

Check current queue lengths:

# ethtool -g eno1
Ring parameters for eno1:
Pre‑set maximums:
  RX: 4096
  TX: 4096
Current hardware settings:
  RX: 255
  TX: 255

Increase queues to the maximum supported values:

ethtool -G eno1 rx 4096
ethtool -G eno1 tx 4096

tuned System Profiles

Use the tuned daemon to apply pre‑defined profiles for specific workloads.

Latency‑first profile: tuned-adm profile network-latency Throughput‑first profile:

tuned-adm profile network-throughput

Interrupt Binding

Disable irqbalance and bind NIC interrupts to dedicated CPU cores to avoid performance jitter caused by interrupt migration.

Disable OVN Load Balancer

The OVN L2 load‑balancer uses conntrack and incurs roughly 20 % CPU overhead. Disabling it and letting kube‑proxy handle Service traffic can improve Pod‑to‑Pod performance.

command:
- /kube-ovn/start-controller.sh
args:
- --enable-lb=false

FastPath Kernel Module

FastPath bypasses netfilter for container traffic, reducing CPU usage by about 20 % when netfilter is not required. Load the module with:

insmod kube_ovn_fastpath.ko
# Verify loading
 dmesg | grep fastpath

Note: Using FastPath disables iptables/ipvs/nftables functionality inside the container network.

OVS Kernel Module Optimization

Open vSwitch flow processing consumes ~10 % CPU; enabling popcnt and sse4.2 instruction sets can cut this to ~5 %.

Compile OVS with the required flags (CentOS example):

git clone -b branch-2.17 --depth=1 https://github.com/openvswitch/ovs.git
cd ovs
curl -s https://github.com/kubeovn/ovs/commit/2d2c83c26d4217446918f39d5cd5838e9ac27b32.patch | git apply
./boot.sh
./configure --with-linux=/lib/modules/$(uname -r)/build CFLAGS="-g -O2 -mpopcnt -msse4.2"
make rpm-fedora-kmod
rpm -i openvswitch‑kmod-*.rpm

For Ubuntu, install build dependencies and run a similar compilation flow, then install the generated modules and reload the OVS service.

STT Tunnel

Standard Geneve/VxLAN tunnels encapsulate traffic over UDP, which prevents TCP offload optimizations. The STT (Stateless TCP) tunnel mimics TCP headers without establishing a real connection, allowing the kernel and NIC to apply TCP‑specific optimizations and achieving several‑fold throughput gains.

Enable STT:

kubectl set env daemonset/ovs-ovn -n kube-system TUNNEL_TYPE=stt
kubectl delete pod -n kube-system -lapp=ovs

After enabling, the OVS kernel module must be rebuilt with the STT patch (see the OVS compilation section).