内核旁路技术综述与性能实测

在现代高性能交易系统中，网络延迟和吞吐量成为关键性技术指标。内核旁路（Kernel Bypass）技术因其能有效降低网络传输延迟、提升吞吐性能，受到越来越多系统开发者的关注。本文将围绕内核旁路的几种主流实现方式进行对比分析，并基于实际测试环境的结果，探讨其在不同场景下的表现和应用价值。

一、什么是内核旁路

传统网络数据路径需要经过内核协议栈处理，每次数据包收发都会带来上下文切换、中断和系统调用等开销。内核旁路的核心思想是在用户态实现网络数据的收发，直接与网卡交互，避开内核协议栈，从而显著减少延迟与系统开销。

实现内核旁路的常见方式包括：DPDK、Netmap、Solarflare OpenOnload、PF_RING、Snabb、PSIOE 等。

二、典型方案对比

1. DPDK

DPDK（Data Plane Development Kit）是 Intel 提出的用户态高速数据包处理框架，基于 UIO（Userspace I/O）机制实现网卡驱动用户态运行。它具备零拷贝、大页内存、流过滤等特性，支持多核并行和硬件加速，适用于对性能要求极高的场景。

DPDK 的优势在于高度可定制和完善的 API 支持，但局限于 Intel 系列网卡，并存在“网卡独占”问题，即系统在使用 DPDK 后，其他程序无法访问该网卡。

2. Netmap

Netmap 同样基于用户态实现高速收发，但通过修改内核驱动，在用户态映射网卡内存，实现高效访问。其优势在于代码轻量、可支持标准系统调用如 select、poll，并具备较好的跨平台支持。但其收发操作依赖 ioctl 调用，存在性能瓶颈，且仅支持部分网卡驱动。

3. OpenOnload

OpenOnload 是 Solarflare 公司推出的一种方案，使用 LD_PRELOAD 技术替换应用中的标准 socket 系统调用，通过 EF_VI 库在用户态实现 TCP/IP 协议栈。其好处是应用无需修改即可接入旁路功能，延迟表现优异。但限制在 Solarflare 网卡，成本与兼容性问题较大。

4. PF_RING 与其他方案

PF_RING、Snabb 等侧重数据捕获和 L2/L3 层处理，适用于 IDS、监控等场景。PF_RING 在收包效率方面表现突出，但发包能力依赖收费模块（DNA）；Snabb 和 PSIOE 的应用范围更小，存在诸如缺乏标准调用支持、网卡兼容性差等问题。

三、性能实测对比

为了对以上提出的内核旁路方案进行比对，在开发机上进行了延迟性能测试。主要包括 ping，UDP 包转发，经过内核的 UDP 包转发。

1. 测试环境

• 10.0.12.11、10.0.12.12、10.0.12.2 开发机
• 千兆网卡
• NUMA 架构
• Rocky8 操作系统
• 内存 128G，2 Node*4 core*2 核 = 24 线程

2. 测试方案

测试数据包大小为 1024 字节，数据包为 10 万个。每一个包统计一次环路延迟，最终取 平均值。 测试过程为：client 发送 UDP 包给 server；然后 client 阻塞等待从 server 接收包；server 死循环，收到从 client 发来的数据包后，立即从另一个 socket 转发出去；client 在接收到该 数据包后，退出阻塞状态。统计总的延迟。然后进入下一次循环。

Step1：

从 12 机器 ping 11 机器。11 机 器旁路程序收到数据后，直接交给 内核网络协议栈。协议栈返回信息 交给旁路程序，再由旁路程序发送 出去。 测试使用的程序仍然为常规 Linux 下转发程序。

• netmap 使用原始 brige 只输入一个 -i 参数即可 1. root 用户： insmod netmap.ko 2. root 用户： 执行： bridge -i netmap:em1 3. 12 机器 ping 11 机器
• dpdk 使用 kni 1. 编译 example/kni 2. ./kni -c 0xf0 -n 4 -- -P -p 0x01 -- config="(0,4,6,8)" 注：执行启动程序后，vEth0_0 会自动使 用所配置的 port 的 MAC 地址 3. ifconfig vEth0_0 10.0.12.11 netmask 255.255.255.0 4. 从 12 ping 11 机器

Step2：

从 12 机器向 11 机器发送 UDP 广 播报文。11 机器旁路程序收到数据 后，直接交给内核网络协议栈，协 议栈交给用户程序，用户程序转发 给协议栈，最终协议栈将返回信息 交给旁路程序，再由旁路程序发送 出去。

• dpdk 使用 kni 1. 编译 example/kni 2. ./kni -c 0xf0 -n 4 -- -P -p 0x01 -- config="(0,4,6,8)" 注：执行启动程序后，vEth0_0 会自动使 用所配置的 port 的 MAC 地址 3. ifconfig vEth0_0 10.0.12.11 netmask 255.255.255.0 4. 从 12 ping 11 机器，等 ping 通的时候，执 行下一步 5. 11 机器开启 UDP server 程序， 12 机器开 启 UDP client 程序

Step3：

从 12 机器向 11 机器发送 UDP 广播 报文。11 机器从 3490 端口收到 后，更改目的端口号为 3492，立即 从网卡发送出去。（1s 发一个包， 统计收发时延）

• 2w 多个包取均值
• netmap 测试时，修改了 bridge 源码。对收到的 数据包更改了 MAC 地址，目标端口地址，源 IP 地址。然后更新了 ip 和 udp 的 checksum。 执行： bridge -i netmap:em1
• 可能会遇到的坑：修改 udp 和 ip 头后， checksum 不对，导致接收端收不到数据。需要 使用 tcpdump -i em1 'udp port 3492' -X -vvv 来查看 checksum
• dpdk 测试。使用前期开发的框架。底层使用外 部链接 so。在 user application 里进行数据收发， 类似于 Linux 下常规操作。
• 可能会遇到的坑：直接修改 example 下面自带的 skeleton 来实现转发，发送释放掉的 buffer 会导 致网卡从双工变成单工，然后断开连接。此时需 要网络岗配合开启交换机端口。

备注：

• DPDK 出现周期性波动（175s 一次），延迟波动范围大（35μs 到 881μs）
• Netmap 在 ping 场景下性能明显劣于 DPDK 和 Linux 原生，主要适合高 PPS 场景

• DPDK 优势：在收发两端均采用 DPDK 的场景下，性能表现最优，延迟从 89μs 降至 64μs。
• Netmap 劣势：延迟表现不佳，且对包大小变化不敏感；更适合数据转发吞吐大（PPS）场景。
• OpenOnload 表现卓越：在万兆环境下实现了最低 12μs 延迟，优势显著，但依赖 Solarflare 专用网卡。

值得注意的是，DPDK 的性能提升明显体现在收发双方均使用旁路时。一端使用旁路而另一端仍为内核协议栈时，整体延迟收益较小。此外，Netmap 延迟表现不如人意，但在 PPS 吞吐场景中仍有其独特优势。

四、实际应用考量

选择内核旁路方案时应结合实际应用需求：

• 对低延迟和高可定制性有极致要求的系统，DPDK 是首选，前提是能接受网卡独占、编程复杂等代价。
• 对轻量化、快速接入、跨平台兼容性要求高的场景，可考虑 Netmap。
• 若已有使用 Solarflare 网卡，可考虑 OpenOnload 来实现高性能旁路。

同时，建议通过结合 KNI 等机制将关键流量旁路至用户态，非关键数据交由内核处理，以兼顾系统兼容性与性能。

五、总结

通过比较实现机制可以看出，所有的内核旁路方案，无非都是在用户态实现网卡驱动， 或者直接在用户态 mmap 映射网卡缓存地址来达到操纵网卡收发数据。 在环路延迟方面，通过性能测试结果可以看出，千兆网卡下，dpdk 旁路性能明显优于 netmap 和 linux。 以下是 dpdk 和 netmap 的整体对比

从以上对比可以看出，dpdk 更符合我们的应用场景，即低延迟和定制化需求。 在解决了当前 DPDK KNI 存在的周期性问题和两极分化问题后，可以有一个更好的内 核旁路框架即： 将我们关心的数据直接旁路给应用程序，将我们不关心的数据通过 kni 传递给内核，交 由操作系统处理。在这种方案下，可以解决使用 dpdk 引起的网卡独占问题，同时也不再影 响物理机上的其它业务，例如 arp、icmp、scp 等。