KNOD：Linux 内核直接向 AMD GPU 卸载网络处理

日期：2026-07-21
主题：KNOD：Linux 内核直接向 AMD GPU 卸载网络处理
原文：KNOD：Linux 内核直接向 AMD GPU 卸载网络处理
来源：Phoronix
领域：⚙️ 操作系统/内核

背景

网络数据包处理一直是 CPU 的核心职责之一。无论是传统的网络协议栈，还是近年来广泛部署的 XDP（eXpress Data Path），每一个数据包到达网卡后，都需要 CPU 内核逐包执行处理逻辑——做 L4 负载均衡、IPsec 加密解密、防火墙规则匹配等等。这种"一个核心一次处理一个包"的串行模型，在面对高速网络接口时越来越捉襟见肘：10Gbps、25Gbps、100Gbps 甚至更高速率下，CPU 核心被大量消耗在包处理上，留给应用程序的计算资源所剩无几。

与此同时，GPU 的架构与 CPU 截然不同——数千个轻量级核心并行执行相同的程序（SIMT），一次处理大批量数据。这种"大规模并行处理少量逻辑"的模式，恰好与 XDP 和 IPsec 等 per-packet 处理模型高度匹配。如果能让 GPU 来承担数据包的处理工作，岂不是可以一举解决 CPU 瓶颈？

这个想法并不新鲜，但以往的方案都有一个共同的问题：它们依赖用户态的 GPU 运行时（如 CUDA 或 ROCm）来管理 GPU 队列、编译程序、发起计算任务——这意味着用户态组件始终留在数据路径上，引入了额外的延迟和复杂性。能不能把这一切都移到内核态，让 GPU 直接作为内核的卸载引擎？

这正是 KNOD（Kernel Network Offload Device）要解决的问题。

KNOD 是什么

KNOD 是一组提交到 Linux 内核邮件列表的 RFC 补丁集，由开发者 Taehee Yoo 提交。这个想法其实早在 2025 年的 Linux Plumbers Conference（日本）上就以概念形式出现过。如今，它变成了实实在在的代码。

KNOD 的核心思路极其简洁，但影响深远：让网卡（NIC）直接将收到的数据包 DMA 到 GPU 显存中，GPU 在内核态运行 per-packet 程序对一批数据包进行并行处理，然后只将处理结果和需要继续上送的数据包送回主机。

具体来说，KNOD 在内核中完成以下几件事：

1. 管理 GPU 队列——内核直接操作 GPU 的命令队列和调度器，无需用户态介入。
2. JIT 编译 per-packet 程序到 GPU 机器码——将现有的 XDP BPF 程序或 IPsec SA 策略编译成 GPU 可以执行的指令。
3. 数据直接通道——NIC 通过 DMA 将收到的数据包写入 GPU 显存，GPU 读取后即可执行程序。
4. 结果回传——GPU 对每个数据包给出 verdict（放行/丢弃/重定向等），需要继续上送的数据包通过 DMA 回传到主机内存。

整个过程中，CPU 不再逐包支付处理开销，吞吐量随 GPU 占用率而非 CPU 核心数线性扩展。

为什么选择 AMD GPU

当前 KNOD 的开发和测试基于 AMD GPU 进行——具体硬件包括 GCN 架构的 Radeon RX Vega 和 RDNA2 架构的显卡。选择 AMD 并非偶然，根本原因在于 AMD GPU 的 Linux 驱动栈完全开源且已经主线化。

相比之下，NVIDIA 虽然有官方的开源内核驱动（Open Kernel Module），但并未完全合入 Linux 内核主线。而 Nouveau/NOVA 开源驱动目前尚不够成熟，无法承载如此复杂的内核态任务。Intel GPU 的支持未来可能实现，但当前所有工作都聚焦在 AMD 平台上。

这种完全在内核态完成的 GPU 卸载有一个关键优势：对现有 offload 路径完全透明。已有的 XDP 程序和 IPsec SA 可以直接被 KNOD 接管，不需要修改应用程序，不需要安装用户态库，不需要在系统里额外运行一个守护进程。

技术深度：从 XDP 到 GPU

要理解 KNOD 的技术价值，我们不妨从 XDP 的局限说起。

XDP 允许用户在网卡驱动的最早入口点注入 BPF 程序，以极低的延迟处理数据包。但 XDP 的瓶颈在于 CPU 核心数的限制——一个 100Gbps 的网卡需要数个到十数个 CPU 核心才能满载运行 XDP，而在容器化、微服务的环境下，CPU 核心本就供不应求。

KNOD 将 XDP 的 per-packet 处理模型映射到 GPU 的 SIMT 执行模型上：

• XDP BPF 程序被 JIT 编译成 GPU 着色器程序
• 一批数据包被 DMA 到 GPU 显存后，GPU 的数千个核心同时对该批数据包执行同一程序
• 每个数据包的 verdict 被写回一个结果缓冲区，CPU 只需读取结果即可

这在本质上是一种"异构分流"——将计算密集但逻辑相对简单的包处理任务交给 GPU，CPU 腾出手来处理更复杂的业务逻辑。

IPsec 的处理也是类似的场景。IPsec 加密/解密涉及对称加密操作，计算量大但数据并行度极高，是 GPU 擅长的领域。KNOD 允许将 IPsec SA 的安全关联（Security Association）直接卸载到 GPU 上加速，CPU 不再需要为每条 SA 做加解密。

与现有方案的对比

业界并非没有 GPU 网络加速的方案，但它们通常走的是用户态路径：

• GPUDirect RDMA：NVIDIA 的技术，允许 NIC 直接与 GPU 显存交换数据，但依赖 CUDA 运行时，且数据路径仍经过用户态。
• DPDK + GPU：用 DPDK 接管网卡后把数据传给 GPU 处理，但 DPDK 本身是用户态框架，需要专用 CPU 核心做轮询。
• ROCm 用户态卸载：通过 AMD ROCm 栈在用户态管理 GPU 网络处理，但 ROCm 的运行时和数据路径强耦合。

KNOD 的不同之处在于：它消除了用户态运行时在数据路径上的存在。内核直接驱动 GPU，所有队列管理、程序编译、任务分发都在内核完成。这意味着：

• 更低的延迟（没有用户态到内核态的切换）
• 更薄的软件栈（不依赖 CUDA/ROCm 运行时）
• 更透明的集成（现有 XDP/IPsec 基础设施无感接入）

挑战与局限

当然，KNOD 仍处于 RFC 阶段，距离合入主线还有不少工作：

• GPU 内存管理：内核需要处理 GPU 显存的分配、映射、回收，这部分在现有 DRM 子系统中仍未完全对齐。
• 程序兼容性：并非所有 XDP BPF 程序都能被 JIT 编译到 GPU 上——涉及复杂辅助函数调用或内核 helper 的程序可能无法直接卸载。
• 硬件生态：当前仅 AMD GCN/RDNA2 可用，NVIDIA 和 Intel GPU 的支持取决于驱动栈的开源化程度。
• 稳定性与安全性：在内核态直接驱动 GPU 做包处理，出错的后果比用户态方案严重得多。

总结与展望

KNOD 代表了一种值得关注的思路转变：将 GPU 从"计算加速器"重新定义为"内核卸载引擎"。

在数据中心里，GPU 已经广泛用于 AI 训练和推理，但它们的利用率并不总是饱和的。如果能在 GPU 空闲时将其用于网络包处理，相当于"一卡多用"，提高了整个数据中心的硬件利用效率。

从更长远的角度看，KNOD 的理念可以延伸到更多场景：存储协议处理（NVMe over Fabrics 的 CRC 计算）、信号处理、甚至部分内核调度逻辑的加速。随着 AMD GPU 驱动的持续主线化和 Intel GPU 驱动的成熟，这类在内核态直接利用 GPU 的方案可能会成为 Linux 网络栈的下一个重要演进方向。

Linux 内核邮件列表上的这组补丁也许只是一个开始。正如提交者在其 LPC 2025 演讲中所展示的：当你把 GPU 看作一个通用 SIMT 卸载引擎，而不是仅用于图形和计算的专用硬件时，内核设计的想象空间就被打开了。