LWN：关于更快进行网络传输的两个议题！

关注了就能看到更多这么棒的文章哦～

Two sessions on faster networking

By Daroc Alden
June 4, 2025
LSFMM+BPF
Gemini flash translation
https://lwn.net/Articles/1022648/

Cong Wang 和 Daniel Borkmann 分别在 2025 年 Linux 存储、文件系统、内存管理和 BPF 峰会 (Linux Storage, Filesystem, Memory Management, and BPF Summit) 上主持了一场会议，讨论了他们各自加速 Linux 内核 (Linux kernel) 中网络功能的计划。两次会议都探讨了如何在网络协议栈 (networking stack) 中移除不必要的操作，但侧重点不同。Wang 讨论了如何利用 BPF (Berkeley Packet Filter) 加速 socket 操作，而 Borkmann 则讲述了如何消除虚拟机 (VM) 网络操作的开销。

sk_msg

Wang 首先解释说，struct sk_msg 是一种在 socket 层消息传递中内部使用的数据结构。他将其与更广泛使用的 struct sk_buff 进行了比较，并表示 sk_msg 要简单得多 。BPF 程序可以通过 socket 映射 (socket maps) 访问 sk_msg 结构体，它们主要用于让 BPF 程序在不同 socket 之间重定向消息。

这种重定向有一些使用场景。例如，在同一台机器上的客户端和服务器之间发送消息时，绕过 TCP 协议栈 (TCP stack)。Wang 解释说，这可以避免不必要的开销，但前提是使用 BPF 转发消息确实更快。在 Borkmann 提问后，Wang 澄清说这个使用场景是推测性的，目前并未在生产环境中使用。

取决于涉及的 socket 类型，消息重定向的具体方式也会有所不同。例如，当从发送 socket 重定向到接收 socket 时，BPF 程序完全不需要对数据进行任何修改，从而实现快速传输。另一方面，当从接收 socket 重定向到发送 socket 时，BPF 程序需要执行一系列转换，将接收到的数据转换为正确的格式。

多年来，TCP 协议栈已经进行了大量优化。例如，它可以高效地批量处理短消息。因此，对于短消息而言，BPF 重定向实际上比遍历整个 TCP 协议栈更慢。Zijian Zhang 的工作 部分纠正了这一点，他在 socket 中添加了一个缓冲区来批量处理短消息。然而，Wang 认为可以通过复用 TCP 协议栈中 Nagle 算法 (Nagle's algorithm) 的代码来进一步提升性能。

随后，Wang 提出了一些不同的、更具推测性的提升性能的想法。这些想法包括引入新的、更高效的接口供 BPF 程序操作 socket 消息，尽可能移除锁，以及简化接收 socket 到发送 socket 情况所需的转换。

会议中讨论了 sk_msg 结构体在整个内核中的使用位置以及这些区域将如何受到影响。Wang 在会议结束时指出，TCP socket 被广泛使用；越来越多的容器化工作负载使用 TCP socket 在同一物理机内部通信。任何旨在加速本地 socket 的工作都无疑会普遍有用。

Netkit 用于虚拟机

虚拟机 (VM) 提供了与物理硬件的全面隔离，代价是额外的开销。在可能的情况下，最好能减少这种开销。Borkmann 讲述了他为消除 VM 网络开销所做的工作，这是让 VM 工作负载和容器 (container) 工作负载在 Kubernetes 中使用相同底层工具的大计划的一部分。

如今，在 Kubernetes 下运行的 VM 位于一个包含 QEMU 的容器中。这种奇怪的现状是因为 Kubernetes 最初是一个容器管理引擎，因此将虚拟机管理器放在容器内可以让 Kubernetes 复用许多现有工具。Borkmann 分享了这张幻灯片来解释这会对网络协议栈造成什么影响：

简而言之，发往虚拟机中运行的应用的网络数据包必须由物理硬件接收，由主机内核处理，转发到虚拟容器桥接网络 (virtual container bridge network)，然后交给 QEMU 虚拟网络设备的主机端，传入虚拟机，最后由客户机内核处理。

Borkmann 说，这带来了大量不必要的工作。大约一年前，QEMU 获得了一个基于 AF_XDP socket (AF_XDP sockets) 的新网络后端；他感觉怀疑 AF_XDP socket 可以用来绕过上述步骤。这项改动并不简单，因为快速数据路径 (XDP - express data path) 在网络命名空间 (network namespaces) 内不受支持 (容器中使用了网络命名空间)。Borkmann 的想法是在物理网卡上预留一组队列，将这些队列绑定到 Cilium 的 Netkit (一个旨在帮助减少网络命名空间开销的内核驱动程序)，并将这些队列专用于容器的网络命名空间。

这将使流量可以直接从物理硬件到达 QEMU 的 AF_XDP 网络后端，再到 VM 的内核。这是开销能达到的最低限度，因为宿主机系统仍然需要控制实际的硬件。这种设计也将允许在宿主机上运行的 BPF 程序正常地拦截和修改流量。

就在峰会前，Borkmann 完成了一个概念验证 (proof-of-concept) 实现，并且运行成功。他说，代码本身并不太复杂，但仍有一些 API 他希望稍微调整一下，以简化整体构思。特别是，与硬件网络设备相比，XDP API 相当有限；Borkmann 希望扩展该 API，以支持各种类型的硬件卸载 (hardware offload)。

尽管这场会议并非 BPF 分会的最后一场，但它标志着 LWN 今年对 BPF 相关报道的结束。BPF 分会的最后一场会议已在与 Mahé Tardy 早期会议相同的文章中 报道 过。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～