前言高性能网络的下半场在云原生和 AI 大模型时代网络性能的瓶颈正从“带宽”转向“拷贝”。为了消除 CPU 拷贝开销TCP devmem (设备内存)应运而生。然而容器环境下虚拟网卡veth/netkit与物理硬件的“天然隔阂”让这项黑科技长期难以进入容器。最近Linux 内核社区提交了一组重磅补丁Patchset通过“队列租赁” (Queue Leasing)方案正式打通了 netkit 设备对 devmem TX 的支持。今天我们就来深度扒一扒这背后的前世今生。一、 技术背景回顾演进的代价1. netkit 的前世今生veth 的接班人在 netkit 出现之前容器通信的霸主是veth pair。veth (Virtual Ethernet)模拟一根网线两端分别插在不同命名空间。虽然简单但数据包在内核协议栈中要走很长的路径且在高并发下 CPU 开销极大。netkit (2024年登场)它是专为 eBPF 设计的高性能虚拟接口。它不再模拟复杂的以太网特性而是作为一个“BPF 钩子载体”允许数据包通过 BPF 程序直接重定向Redirection极大地缩短了路径是 Cilium 等现代容器网络的理想选择。2. devmem 的崛起零拷贝的终极形态传统 TCP数据从网卡到内存再从内存拷贝到用户态或 GPU 显存CPU 忙于搬运数据。TCP devmem允许数据直接在硬件设备内存如 GPU 显存、TPU 内存和网卡之间传输。RX (接收)网卡直接将数据写入 GPU 显存。TX (发送)网卡直接从 GPU 显存读取数据发出。核心痛点由于数据不在主内存CPU 看不见也读不了Unreadable skb这对内核的校验和验证提出了极高要求。二、 现状与痛点被阻断的发送路径虽然 netkit 很快devmem 很强但两者结合时却遇到了“身份验证”问题。问题描述容器通过虚拟网卡netkit发送数据。当应用尝试通过 netkit 发送存储在 GPU 显存中的数据时内核的devmem TX 路径会进行安全检查内核问“当前发包的设备netkit支持 DMA直接内存访问吗”netkit 答“我是虚拟设备没有硬件 DMA 控制器。”内核判定“不支持丢弃数据包Drop。”现状目前 netkit 的RX接收路径由于逻辑较简单已经能够配合物理网卡工作。但TX发送路径因为涉及复杂的 DMA 绑定和本地化内存分配NUMA在补丁发布前一直处于不可用状态。三、 补丁方案拆解队列租赁Queue Leasing针对上述问题Bobby Eshleman 等开发者提出了“队列租赁”的概念。这套补丁集即你看到的 1.txt 中的内容核心逻辑如下1. 代理机制Proxying补丁允许 netkit 设备从底层的物理网卡如 Nvidia ConnectX-6中“租赁”硬件队列。逻辑绑定在容器内应用依然操作 netkit 的队列 ID。底层映射内核会在底层自动将这个虚拟队列映射到物理网卡的真实硬件队列上。2. 身份“借用”这是最精妙的地方。当bind-tx在 netkit 设备上调用时内核不再死板地检查 netkit。内核会查表“噢这个 netkit 租了物理网卡eth0的队列。”验证重定向内核转而检查物理网卡eth0是否支持 netmem TX。如果是则通过验证并将eth0作为 DMA 操作的实际目标。3. 双重保险验证为了防止数据包被意外重定向到不支持 devmem 的设备补丁引入了validate_xmit_unreadable_skb()增强检查第一道关卡数据包在 netkit 层面验证确保绑定的物理网卡合法。第二道关卡如果 BPF 逻辑将包重定向到其他网卡在最终发送前会再次检查目标网卡。如果不支持则宁可丢包也不引发系统崩溃。四、 性能表现与意义该补丁已经在100G 网卡Nvidia ConnectX-6 和 Broadcom BCM957504上通过了严格测试。它的意义在于容器原生性能容器内的 AI/HPC 应用终于可以像跑在宿主机上一样利用 TCP devmem 实现零拷贝且性能无损。架构解耦容器不需要知道物理网卡的复杂参数只需要通过“租赁”的虚拟队列即可享受硬件加速。五、 结语从veth到支持devmem TX的netkitLinux 内核网络协议栈正在经历一场面向 AI 时代的重构。通过“队列租赁”我们不仅打破了虚拟与物理的界限更在高性能网络通信的道路上迈出了关键一步。如果你正在开发高并发 AI 推理服务或分布式存储这个补丁集绝对值得你持续关注参考资料Linux Kernel Mailing List (LKML)BPF Kernel DevelopmentProject: Netkit and Queue Leasing Support