Products

2–3 µs Network Latency on Virtualized Infrastructure: Kernel Bypass NICs with Arcfra AECP

Published on 2026-08-25 by Arcfra Team

Last edited on 2026-08-25

In recent years, general-purpose hardware has struggled to keep pace with rising performance demands. For latency-sensitive workloads, especially low-latency trading, relying only on general-purpose servers and software stacks is no longer enough. These scenarios depend more heavily on specialized hardware such as ultra-low-latency Network Interface Cards (NICs), which place higher demands on the underlying IT infrastructure’s ability to support, manage, and expose hardware capabilities efficiently.

To help optimize performance in virtualized environments, Arcfra Enterprise Cloud Platform (AECP) provides support for multiple specialized hardware technologies. At the networking layer, AECP leverages SR-IOV and PCI passthrough technologies to allow virtual machines (VMs) to directly access kernel-bypass NICs, enabling high-speed, low-latency network transmission.

This article explains why kernel-bypass NICs are used, how Arcfra AECP supports them in virtualized environments, and how they perform in real-world validation with Solarflare low-latency NICs, where network latency can be reduced to 2–3 µs.

Why Kernel Bypass NICs Matter

Kernel Bypass: Removing Kernel Stack Overhead to Cut Latency

In most modern computer systems, network communication depends on the operating system’s general-purpose kernel protocol stack. When an application sends or receives data, packets follow a standard path: they arrive at the NIC, trigger a CPU interrupt, enter kernel space, pass through TCP/IP stack processing such as packet validation, sequencing, and congestion control, and then cross the boundary between kernel space and user space before being delivered to the application through a memory copy.

This design is stable and broadly compatible, but it is not optimized for extreme performance. Frequent context switching, repeated memory copies, and kernel processing consume CPU cycles and introduce latency that can be unacceptable for microsecond-sensitive workloads.

For ordinary applications such as web browsing or file transfers, this overhead is usually harmless. In fields such as high-frequency trading (HFT), real-time financial market data, and high-performance computing (HPC), however, even a single microsecond of additional network latency can affect business outcomes. Kernel bypass technology addresses this by constructing a direct high-speed path from the NIC to the user-space application, effectively avoiding the bottlenecks of the kernel protocol stack.

Traditional TCP/IP Processing vs. Kernel Bypass

Core Kernel Bypass Techniques

User-Space Lightweight Drivers: Drivers are implemented in user space to manage the NIC directly. Applications can efficiently send and receive data via memory mapping (mmap).
Zero-Copy DMA: Utilizing the NIC’s Direct Memory Access (DMA) capabilities, data is read from and written directly to a pre-allocated memory pool in user space. This eliminates the data-shuffling overhead between kernel and user space.
Poll-Mode Drivers: High-efficiency polling replaces interrupt-driven mechanisms. The CPU actively polls for and processes data, avoiding interrupt-induced latency and jitter.

With these three features, kernel bypass technology reduces network processing latency from milliseconds to microseconds. At the same time, it minimizes kernel-state CPU consumption during network processing, allowing more CPU cycles to be dedicated to user-space application logic, helping ensure high-performance network processing.

Kernel Bypass NICs: Reducing Code Changes and CPU Load

Although kernel bypass technology significantly optimizes network performance, it still introduces two core challenges:

Requirement for Application Modification: Pure software-implemented kernel bypass typically requires refactoring the application’s network logic to support user-space network calls.
High CPU Occupation: Software kernel bypass merely shifts network processing from kernel space to user space; network tasks still require substantial CPU involvement, tying up critical computing resources.

Kernel bypass NICs are hardware-software co-designed solutions that combine kernel bypass technology with hardware offloading. Currently, mainstream products on the market include AMD Solarflare’s Onload technology, Nvidia Mellanox’s VMA technology, and Cisco Exablaze’s ExaNIC Software technology. These solutions build upon kernel bypass by offloading a portion of the network functions directly onto the NIC hardware, further improving network performance.

To resolve the aforementioned challenges, kernel bypass NICs and their accompanying solutions adopt the following strategies:

User-Space TCP/IP Stacks to Avoid Application Modification: Applications can continue using standard Socket APIs without altering a single line of existing code. Network offloading components on the OS side transparently intercept the traffic.
Hardware Offloading: The CPU only manages the control plane, while the NIC hardware handles the data plane. This drastically minimizes CPU involvement during network I/O processes.

Kernel Bypass Hardware Offloading vs. Software-Based Solutions

These improvements make kernel bypass technology more practical in production environments. By combining kernel bypass, zero-copy, reduced context switching, and hardware offloading, kernel bypass NICs minimize microsecond-level latency and jitter, making them well suited to low-latency application scenarios.

Kernel Bypass NIC Performance on Arcfra AECP: 2–3 µs Latency

Enabling Kernel Bypass NICs on Arcfra AECP

In industries such as futures and securities, some organizations run quantitative trading systems based on customized trading strategies. HFT is highly sensitive to market changes, and millisecond-level or even microsecond-level delays can affect trading returns. To meet these requirements, the industry often adopts solutions such as Solarflare kernel bypass NICs to reduce network latency.

In traditional deployment models, these NICs are usually installed in bare-metal physical servers, with independent NICs dedicated to each server, significantly increasing hardware costs. Virtualization can help reduce hardware investment and improve resource utilization flexibility.

However, traditional virtualized networks generally use virtio or similar virtual NICs to provide network interfaces for VMs, which do not possess the high-performance attributes of kernel bypass NICs on physical servers. To bridge this gap, Arcfra AECP supports network card passthrough, which allows both physical PCI NICs and SR-IOV NICs to be passed through directly to VMs for use.

PCI NIC Passthrough: A physical NIC on the host is passed through directly to a VM as a PCI passthrough NIC, becoming exclusively dedicated to that specific VM.

SR-IOV Passthrough: A single physical NIC supporting SR-IOV is virtualized into multiple VFs (Virtual Functions). These VFs are attached directly to VMs as SR-IOV passthrough NICs, allowing multiple VMs to share the communication capabilities of a single physical NIC.

Network card passthrough directly maps all the features of a physical NIC into the VM, granting the VM complete access to the physical hardware. Through this feature, VMs can utilize hardware acceleration capabilities, including PTP (Precision Time Protocol) and Onload offloading, thereby meeting the rigorous demands of high-performance network scenarios such as futures trading and HPC.

Validating Kernel Bypass NIC Performance on Arcfra AECP

In this test case using Arcfra AECP and Solarflare low-latency NICs, sfnettest was used to conduct peer-to-peer latency testing and evaluate latency performance across five scenarios:

VM to VM (Virtual NIC): Two VMs are deployed across different nodes on Arcfra AECP with virtual NICs attached. The latency results serve as the baseline value to compare the latency reductions of other solutions.
VM to Host (SR-IOV): One VM is deployed on Arcfra AECP with an SR-IOV NIC attached to test the latency against a physical host.
VM to VM (SR-IOV NIC): Two VMs are deployed across different nodes on Arcfra AECP with SR-IOV NICs attached to test the latency.
VM to Host (Onload Acceleration): One VM is deployed on Arcfra AECP with an SR-IOV NIC attached, while the physical server uses a physical NIC. Once the NICs are correctly recognized on both sides, the acceleration solution is enabled for latency testing.
VM to VM (Onload Acceleration): Two VMs are deployed across different nodes on Arcfra AECP with SR-IOV NICs attached. Once the NICs are correctly recognized, the acceleration solution is enabled for latency testing.

The test results indicate that under a direct peer-to-peer connection mode, without passing through an intermediate switch, relying solely on standard virtual NICs cannot meet the demands of low-latency applications. Conversely, employing SR-IOV passthrough NICs, even without enabling the acceleration software, dramatically reduces latency in both VM-to-VM and VM-to-Host scenarios. When the network acceleration solution is fully enabled, the combination of Solarflare NICs and Onload acceleration further reduces network latency to 2–3 µs across all tested scenarios.

A securities institution has validated the performance of Arcfra AECP + Solarflare low-latency NICs in a production environment for ultra-fast trading. By using low-latency VMs to support client algorithmic trading engines, the institution reduced hardware costs by over 50% and power consumption by approximately 50% compared with bare-metal servers.

Conclusion

To meet modern applications’ higher infrastructure requirements, Arcfra AECP introduces kernel bypass NICs into virtualized environments through SR-IOV and PCI NIC passthrough technologies. This improves virtualized network performance while helping reduce infrastructure costs, providing enterprises with a practical path to build high-performance, cloud-based datacenters on Arcfra AECP.

Appendix: Physical Host Configurations Used in Testing