P5-06 · DPU 厂商调研：BlueField / Pensando / Nitro / 国产，一张矩阵看清格局 对应路线图：Phase 5 (Day 141-168) ｜ DPDK 24.11.6 LTS ｜ 内核对照 v6.6本篇为厂商调研，无源码引用，所有参数均基于公开文档/官方资料整理；厂商产品迭代快，具体参数以官方文档为准上一篇：P5-05 rte_flow offload 实测 ｜ 下一篇：P6-01 DPU 架构一句话定位学完 DMA/IOMMU、VFIO、virtio/vhost、vDPA、rte_flow 这五块积木，现在是时候回答：市面上谁把这些积木拼成了产品？ 本篇用"芯片形态 × 开放度"两张坐标轴给主流 DPU 定位，为 P6-01 的自研架构设计提供选型参照。对比矩阵（基于公开文档整理）厂商代表产品芯片形态网络能力软件栈/开放度备注NVIDIABlueField-316×Cortex-A78 + ConnectX-7 Dx 加速器400GbE / NDR InfiniBandDOCA SDK（开放，类 CUDA 生态）商用 DPU 事实标准；DPDK 25.03+ 需 -mcpu=cortex-a78ae 编译AMDPensando 系列（含 Pollara 400）P4 可编程流水线400G 产品族SSDK（P4 软件定义硬件）主打可编程性与 AI 网络（UEC RDMA）AWSNitro 系统Annapurna 自研 ASICv5 单卡 200G（公开报道）不对外销售，封闭云厂商自研标杆：网络/EBS/安全多卡分工，SRD 协议中科驭数K2-Pro自研 KPU + 16 簇 128 核 NP2×100G，80Mpps（官方口径）HADOS 平台（类 DOCA），兼容 DPDK/SPDK国内首颗量产三代 DPU（2024 发布）；适配鲲鹏/海光/飞腾云脉芯联metaFusion / xFusion50自研 DPU 芯片RDMA 智能网卡端到端拥塞控制、GPU Direct RDMA多场景 RDMA 与 HPC 定位大禹智芯Paratus 1.0/2.0Arm SoC（2.0 加 FPGA）10G/25G → 100G强调软件开放性，支持 VirtIO虚拟化/存储卸载 + 独立 BMC芯启源DPU 系列（含 Agilio）NP-SoC（Arm + RISC-V NP）目标 400G全栈自研，Chiplet 路线Agilio 产品公开资料：100G、28MppsIntelIPU E2000（Oak Springs Canyon）Arm SoC + 加速器200GInfrastructure Programmer Dev Kit公开报道 2025 年已停售，注意选型风险厂商逐个看NVIDIA BlueField-3——路线最稳的"通用计算 + 网络加速"双引擎：Arm 侧跑控制面/存储/安全代理，ConnectX-7 Dx 侧做流量卸载和加解密。生态是其真正护城河：DOCA 对标 CUDA 的打法，DPDK 也为 BF3 单独适配（25.03+ 的 -mcpu=cortex-a78ae 编译选项）。BlueField-4 按公开报道会引入 GPU 加速，向 AI 算力网收敛。AMD Pensando——"软件定义芯片"路线的旗手：P4 流水线让客户自己定义匹配/动作逻辑，SSDK 附送参考流水线（与 SONiC 集成）。Pollara 400 在 Hot Chips 2025 披露了 UEC-ready RDMA 细节（adaptive spraying、SACK 等），主打 AI 集群东西向网络。适合数据面协议需要频繁重定义的场景。AWS Nitro——不卖产品，卖的是"DPU 该解决什么问题"的参考答案：网络/EBS/本地存储多卡分工、SR-IOV 直通、SRD 协议替代 TCP、密钥只在 Nitro 卡受保护内存中明文存在。三代进化路线是云厂商"性能翻倍、成本砍半"打法的范本：Nitro 代际网络能力（公开报道）说明v110Gbps / 1.2 Mpps首代，验证"卸载虚拟化"可行v4100Gbps / 15 Mpps配套 Graviton2/3 时代v5单卡 200Gbpsre:Invent 2022 发布；较上代晶体管翻倍、PCIe 带宽翻倍、每瓦性能提升至多 40%国产阵营——共同点是"对标 BlueField、卡位信创"：中科驭数 K2-Pro 是公开资料最完整的一家（官方口径 2×100G、80Mpps、HADOS 平台，2026 年计划量产 K3）；云脉芯联聚焦 RDMA 与 GPU Direct；大禹智芯走 Arm+FPGA 强调开放性；芯启源押注 Chiplet 与全栈自研。集体短板是软件生态厚度——DOCA 有数千家开发者的沉淀，国产 SDK 目前还在"能跑通 demo"到"能承载生产"之间。定位矩阵三个观察：右上角（开放 + 专用加速）是商业化的主战场：BlueField 和 Pensando 都走"卖芯片/卡 + 卖 SDK"路线，生态壁垒在软件栈（DOCA/SSDK）而不在硅片。云厂商路线完全相反：AWS Nitro 不对外卖、不开源核心，把 DPU 当内部基础设施用——性能和成本极致优化，但外人无法复用。阿里（CIPU）、腾讯（玄灵）同理，公开细节更少。国产玩家集体走"对标 BlueField、补齐生态"路线：芯片形态多元（KPU/NP/FPGA/Arm 混合），统一卖点是国产 CPU 适配 + 金融/信创场景落地；差距主要在软件生态厚度和代际带宽（100G-200G 为主）。选型决策树（个人推演，供 P6 参考）纯软件转发够用（≤25G、单租户、协议栈简单）→ 不上 DPU，x86 + DPDK 就是答案（uNOS Home CPE 归此类）。要卸载但预算/生态受限（25G-100G，虚拟化网络/存储加速）→ 国产 25G 智能网卡或二手 BlueField-2，先验证 vDPA/rte_flow 能力集。高吞吐 + 重协议定制（100G+，AI 集群、自定义拥塞控制）→ Pensando 类 P4 可编程路线，或 BlueField-3 + DOCA。自用规模够大（十万级服务器）→ 学 AWS：自研 ASIC，成本与安全都自己说了算。🐧 内核对照：内核的 DPU 钩子已经就位本系列前五篇学的内核设施，就是厂商 DPU 全部要对接的接口面：IOMMU（dma-iommu.c）保证设备 DMA 隔离；VFIO（vfio_pci_core.c）把加速器安全交给用户态；vDPA（vdpa.c + virtio_vdpa.c）把 virtio 数据面卸载进硬件；cls_flower（net/sched/cls_flower.c）承担内核侧 offload 判断。评判一张 DPU 的 Linux 生态成色，看它在这四个接口上的内核驱动质量即可——这是我在 P6 自研架构里评估软硬分工的依据。面试 3 问云厂商为什么要自研 DPU 而不是直接买 BlueField？ → 三个理由：成本（Nitro 摊薄到百万级实例）、安全（硬件根信任自己掌握，AWS Nitro 明文密钥只存在于 Nitro 卡受保护内存）、定制（SRD 这类自家协议只有自研硅片能做）。P4 可编程 DPU（Pensando）和 Arm 通用 DPU（BlueField）的本质区别？ → P4 把匹配/动作流水线暴露给软件重定义，数据面性能确定、硬件资源固定；Arm 路线数据面灵活度低（依赖固定加速器），但通用计算（控制面、存储、安全代理）无上限。选型先问"数据面要多大灵活度"。国产 DPU 选型最该验证什么？ → 不只看带宽数字，看三样：内核驱动在 mainline 的成熟度（vfio/vDPA/rdma 四件套）、DPDK 适配程度（PMD 是否支持 rte_flow offload 能力集）、软件栈生态（有没有类 DOCA 的 SDK 和真实客户案例）。🔧 动手调研（替代实验）本模块没有可跑的硬件实验，产出两份调研文档到 perf-data/P5/：perf-data/P5/06-vendor-matrix.md：上表 + 每家厂商的官方产品页/白皮书链接归档，标注查阅日期（参数会过时，日期是可信度的一部分）。perf-data/P5/06-uNOS-fit.md：结合 uNOS 双产品定位做选型推演——Home CPE（J3455）：不需要 DPU，纯软件 DPDK 转发足够（P1 数据已证明单核可打满 10G）；Cloud Edge（T140）：若有 25G+ 卸载需求，优先评估二手 BlueField-2 / 国产 25G 智能网卡，验证点就是本篇面试第 3 问的三件套。来源（检索于 2026-08）：NVIDIA DOCA 设备支持列表 ｜ 中科驭数 K2-Pro 官方页 ｜ AMD Pensando 博客 ｜ ServeTheHome: Pollara 400 @ Hot Chips 2025 ｜ AWS Nitro 安全设计白皮书 ｜ ServeTheHome: AWS Nitro v5 ｜ 国产 DPU 格局盘点（eet-china）下一篇：P6-01 · 自研 DPU 数据面架构设计

P5-05 · rte_flow offload 实测：SW 匹配 vs HW 卸载，同一个 API 对应路线图：Phase 5 (Day 141-168) ｜ DPDK 24.11.6 LTS ｜ 内核对照 v6.6代码出处：source/dpdk-stable-24.11.6/lib/ethdev/rte_flow.h、source/linux-stable/net/sched/cls_flower.c上一篇：P5-04 vDPA ｜ 下一篇：P5-06 DPU 厂商调研一句话定位P1-07 学过 rte_flow 的"流与核绑定"，本篇回答另一个问题：同一条 flow rule，由网卡硬件执行还是由 CPU 执行？ API 完全一样（rte_flow_create），区别在 PMD 的 capability 判断——支持就下发硬件（零 CPU），不支持就回退软件匹配（每包吃 CPU）。DPU 的价值主张"把网络处理卸载进硬件"，落到 API 层就是这个开关。真实源码精读① 规则三要素：struct rte_flow_attr（lib/ethdev/rte_flow.h:89-129，节选）struct rte_flow_attr { // ...省略 group 的长注释 ... uint32_t group; // :100 规则组（层级树根在 0） uint32_t priority; // :101 组内优先级 // ... uint32_t ingress:1; // :105 入向规则 // ... uint32_t egress:1; // :109 出向规则 // ...省略 transfer 的长注释 ... uint32_t transfer:1; // :127 转移到设备层（eswitch/representor） uint32_t reserved:29; // :128 };三个 bit 决定规则贴在哪里：普通 app 用 ingress/egress；DPU/SmartNIC 场景用 transfer:1 把规则下到"设备层"——这就是 OVS 卸载、vDPA 卸载共用的通道。② pattern 与 action 的枚举（rte_flow.h:153 / :2590）enum rte_flow_item_type { // :153 // ... RTE_FLOW_ITEM_TYPE_END, // :162 列表终止符 // ... RTE_FLOW_ITEM_TYPE_RAW, // :211 任意字节匹配（几乎只能软件做） // ... RTE_FLOW_ITEM_TYPE_ETH, // :218 // ... RTE_FLOW_ITEM_TYPE_VLAN, // :225 // ... RTE_FLOW_ITEM_TYPE_IPV4, // :232 // ... RTE_FLOW_ITEM_TYPE_IPV6, // :239 // ... RTE_FLOW_ITEM_TYPE_UDP, // :253 // ... RTE_FLOW_ITEM_TYPE_TCP, // :260action 侧（:2590 起）：RTE_FLOW_ACTION_TYPE_END（:2597）终止列表，RTE_FLOW_ACTION_TYPE_VOID（:2605）是占位符，往下是 QUEUE/DROP/RSS/COUNT 等。枚举是通用的，能力是各异的——这就是 offload 判断存在的根本原因。③ 入口签名（rte_flow.h:4694-4699）struct rte_flow * rte_flow_create(uint16_t port_id, const struct rte_flow_attr *attr, const struct rte_flow_item pattern[], const struct rte_flow_action actions[], struct rte_flow_error *error);error 参数是调试神器：PMD 拒绝规则时把原因填进去（哪条 item 不支持、哪条 action 不支持），实测时打印 error->message 就能看到自己网卡的 offload 能力边界。🐧 内核对照：tc flower 的 offload 判断内核的对应物是 cls_flower（net/sched/cls_flower.c）：fl_change（:2229）处理 tc filter add flower ... 配置，其中 :2369 调用 fl_hw_replace_filter（:452）尝试硬件卸载；卸载失败再走软件分类。和 DPDK 的差别：维度tc flowerrte_flow下发入口netlink 消息 + tc 命令行C API 直接调用（rte_flow.h:4695）失败语义静默回退软件或返回错误rte_flow_error 明细报告软件路径内核分类器逐包查PMD 软件匹配器（lcore 上）硬件目标驱动 ndo_setup_tcPMD flow_ops（如 mlx5 eswitch）同一件事："先试硬件，不行回软件"。内核走配置面 netlink，DPDK 走数据面 API——后者把下发延迟从毫秒级压到微秒级，这正是 DPU 上动态流表需要的。面试 3 问怎么判断一条规则最终走了硬件还是软件？ → 查 PMD capability（rte_flow_validate 提前试错）+ rte_flow_create 的 error 明细（rte_flow.h:4694-4699）；实验上对比有/无规则时的 lcore CPU 占用，HW 卸载路径 CPU 几乎不动。transfer:1 属性和普通 ingress 规则区别在哪？ → ingress/egress 规则作用于"到达本端口的流量"，transfer 规则下到设备层端点（eswitch/representor），用于跨物理口/VF 的转发——rte_flow.h:105/109/127 三个 bit 的语义。为什么 RAW item 几乎只能走软件路径？ → 任意字节匹配不在典型硬件流表能力内（rte_flow.h:211 的 RAW 是"匹配元数据类"item 之一），PMD 无法下发时只能软件逐包比对；5-tuple 类（ETH/IPV4/UDP/TCP，:218/:232/:253/:260）才是硬件卸载的甜区。🔧 动手实验本机 82599（ixgbe）offload 能力有限（5-tuple ntuple filter），设计一个"能力边界 + 双路径"实验：# 1. 起 testpmd，rss 模式跑通 ./testpmd -c 0x3 -n 2 -- -i --forward-mode=rxonly # 2. HW 路径：下发 5-tuple → QUEUE 规则（ixgbe ntuple 能力内） testpmd> flow create 0 ingress pattern eth / ipv4 src is 10.0.0.1 dst is 10.0.0.2 \ / udp src is 1234 dst is 5678 / end actions queue index 1 / end # 观察返回 Flow rule #0 以及 error->message 是否报 unsupported # 3. SW 路径：换 RAW pattern（ixgbe 不支持硬件匹配） testpmd> flow create 0 ingress pattern raw relative is 1 pattern is \ ff:ff:ff:ff:ff:ff:08:00 / end actions queue index 1 / end # 若 PMD 报 unsupported，记录错误文本；用支持 SW 匹配的路径验证 # 4. 打流对比：dperf 或 pktgen 打目标 5-tuple， # 对比有规则（HW 卸载）/无规则时 testpmd 的 lcore CPU（mpstat）与 PPS # 5. 加分项：mlx5 或 dperf 侧做 COUNT action 验证硬件计数数据落点：perf-data/P5/05-offload.md（flow create 日志与 error 明细、SW/HW 两路径的 PPS 与 CPU 对比、ixgbe 能力边界清单）。预期：ixgbe 上 5-tuple 规则下发成功且 CPU 占用不升（硬件过滤后只剩匹配流量上 CPU）；RAW 规则被明确拒绝——这条"拒绝日志"本身就是能力边界的实证。下一篇：P5-06 · DPU 厂商调研：BlueField/Pensando/Nitro/国产

P5-04 · vDPA 框架：把 virtqueue 卸载进硬件，guest 零感知 对应路线图：Phase 5 (Day 141-168) ｜ DPDK 24.11.6 LTS ｜ 内核对照 v6.6代码出处：source/linux-stable/drivers/vdpa/vdpa.c、drivers/virtio/virtio_vdpa.c、source/dpdk-stable-24.11.6/lib/vhost/vdpa.c上一篇：P5-03 virtio 与 vhost-user ｜ 下一篇：P5-05 rte_flow offload 实测一句话定位vhost-user 把后端搬到用户态，性能还是受限于"每包过一遍 CPU"。vDPA 更进一步：virtqueue 的收发数据面整个下沉到 SmartNIC/DPU 硬件，guest 里还是那个标准 virtio-net 驱动，什么都不用改。控制面仍走标准接口（vDPA bus + vhost-vdpa / DPDK rte_vdpa），数据面走硬件——"协议不变，执行者变了"。内核 vDPA 框架：一个 bus，一套 ops① 设备注册入口：vdpa_register_device（drivers/vdpa/vdpa.c:265-274）int vdpa_register_device(struct vdpa_device *vdev, u32 nvqs) { int err; down_write(&vdpa_dev_lock); err = __vdpa_register_device(vdev, nvqs); up_write(&vdpa_dev_lock); return err; }vDPA 设备是一个虚拟 bus 上的设备（vdpa_bus）：厂商驱动（比如 drivers/vdpa/mlx5/net/mlx5_vnet.c）probe 到硬件后，分配 vdpa_device 并在这里注册（doc 注释 :257-264 明确"先调 vdpa_alloc_device 再注册"）。设备的能力全部通过 vdpa_config_ops 虚表暴露——get_features、set_vq_state、get_vq_state、kick_vq 等（struct 定义在 include/linux/vdpa.h，本阶段未逐行读）。总线负责对接，ops 负责翻译成硬件操作。② 把 vDPA 设备变成 virtio 设备：virtio_vdpa_probe（drivers/virtio/virtio_vdpa.c:489-526）static int virtio_vdpa_probe(struct vdpa_device *vdpa) { const struct vdpa_config_ops *ops = vdpa->config; struct virtio_vdpa_device *vd_dev, *reg_dev = NULL; int ret = -EINVAL; vd_dev = kzalloc(sizeof(*vd_dev), GFP_KERNEL); if (!vd_dev) return -ENOMEM; // ...省略 dev/ops/锁初始化 ... vd_dev->vdev.id.device = ops->get_device_id(vdpa); if (vd_dev->vdev.id.device == 0) goto err; vd_dev->vdev.id.vendor = ops->get_vendor_id(vdpa); ret = register_virtio_device(&vd_dev->vdev); reg_dev = vd_dev; if (ret) goto err; vdpa_set_drvdata(vdpa, vd_dev); return 0; }这一步是整个 vDPA 的点睛之笔：从 vDPA 设备读出 virtio 设备 ID（:506），用 register_virtio_device（:511）把它注册成标准 virtio 设备。内核的 virtio 核心一看到它，就会让 guest 侧的 virtio-net 驱动去 probe——guest 完全以为自己在跟一个软件后端说话。驱动结构在 :535-543：.probe = virtio_vdpa_probe，module_vdpa_driver(virtio_vdpa_driver) 注册到 vDPA bus。数据面上，guest 的 kick 经过 ops 的 kick_vq 变成"告诉硬件队列有活干"；硬件收发包直接 DMA 读写 guest 的 ring，CPU 只处理控制面。DPDK 侧：rte_vdpa 让 vhost-user 应用无感接硬件③ 注册与强制接口检查（lib/vhost/vdpa.c:74-124，节选）struct rte_vdpa_device * rte_vdpa_register_device(struct rte_device *rte_dev, struct rte_vdpa_dev_ops *ops) { struct rte_vdpa_device *dev; int ret = 0; if (ops == NULL) return NULL; /* Check mandatory ops are implemented */ if (!ops->get_queue_num || !ops->get_features || !ops->get_protocol_features || !ops->dev_conf || !ops->dev_close || !ops->set_vring_state || !ops->set_features) { VHOST_CONFIG_LOG(rte_dev->name, ERR, "Some mandatory vDPA ops aren't implemented"); return NULL; } // ...省略重复注册检查、分配、type 获取 ... TAILQ_INSERT_TAIL(vdpa_device_list, dev, next); // ...对外接口是 vhost-user 协议，对内接口是这 7 个强制 ops——DPDK 应用（testpmd/OVS）不用改一行代码，vDPA 驱动在协议层把 SET_VRING_NUM/SET_FEATURES 等消息翻译成硬件配置。这份设计让"软件 vhost-user 后端"和"硬件 vDPA 后端"可以互换。④ used ring 回填：硬件算完，框架负责"交作业"（lib/vhost/vdpa.c:150-182，节选）int rte_vdpa_relay_vring_used(int vid, uint16_t qid, void *vring_m) { // ...省略空指针/队列号/packed 检查 ... s_vring = (struct vring *)vring_m; vq = dev->virtqueue[qid]; idx = vq->used->idx; idx_m = s_vring->used->idx; ret = (uint16_t)(idx_m - idx); vq->used->flags = s_vring->used->flags; while (idx != idx_m) { /* copy used entry, used ring logging is not covered here */ vq->used->ring[idx & (vq->size - 1)] = s_vring->used->ring[idx & (vq->size - 1)]; desc_id = vq->used->ring[idx & (vq->size - 1)].id; desc_ring = vq->desc; nr_descs = vq->size; // ...省略 indirect 描述符处理 ...硬件收完包后写的是自己的 shadow ring（s_vring），框架把这个"成绩单"逐条拷回 guest 的 used ring（:179-182）——硬件不必知道 guest 内存布局，框架兜住协议兼容性。这是 vDPA 数据面最后 1% 的关键设计。🐧 内核对照：内核 vhost-vdpa vs DPDK rte_vdpa维度内核 vhost-vdpaDPDK rte_vdpa控制面接口vDPA bus 原生接口（vdpa.c:265）vhost-user 协议桥接（vdpa.c:74）对接方virtio_vdpa（virtio_vdpa.c:511）注册标准 virtio 设备应用侧仍是 vhost-user fd/消息数据面硬件直操作 guest ring硬件 shadow ring + relay 回填（vdpa.c:150）典型用户KVM + SmartNIC 直通OVS-DPDK 云网络卸载两边都遵守同一个原则：数据面下沉硬件，控制面留在通用层。内核版从 virtio 生态接入，DPDK 版从 vhost-user 生态接入——殊途同归。面试 3 问vDPA 与 SR-IOV 直通有什么本质区别？ → SR-IOV 里 guest 用厂商专用驱动（如 iavf）感知真实硬件；vDPA 里 guest 用标准 virtio 驱动，硬件细节被 vDPA 层完全隐藏——迁移、升级、换硬件都不动 guest。为什么 virtio_vdpa_probe 要读 get_device_id？ → vDPA 设备要先"伪装"成对应类型的 virtio 设备（virtio_vdpa.c:506-511），内核 virtio 核心才会让 guest 驱动正确 probe；device id 为 0 视为无效直接失败（:507-508）。硬件的 shadow ring 是什么，为什么要 relay？ → 硬件在自己的内存里维护处理结果，不直接写 guest 的 used ring；rte_vdpa_relay_vring_used 把 used 条目批量拷回 guest ring（vdpa.c:179-182），隔离硬件实现与协议内存布局。🔧 动手实验J3455 没有 vDPA 硬件（mlx5_vdpa 需要 ConnectX SmartNIC），用内核自带的模拟器 vdpa_sim 走通框架：# 1. 加载模拟设备（drivers/vdpa/vdpa_sim/vdpa_sim_net.c， # mgmtdev 名字 "vdpasim_net" 见 :443） modprobe vdpa_sim_net ls /sys/bus/vdpa/devices/ # 期望看到 vdpa0 之类 # 2. 用 iproute2 的 vdpa 工具创建 mgmtdev / 设备 vdpa mgmtdev show vdpa dev add name vdpa0 mgmtdev vdpasim_net # 3. QEMU 用 vhost-vdpa 启动 guest qemu-system-x86_64 -netdev vhost-vdpa,id=n1,vhostdev=/dev/vhost-vdpa-0 ... # 4. 抓取关键路径证据：guest 内 dmesg 确认 probe 到 virtio_net # host 侧对比 vhost-net / vhost-vdpa / vhost-user 三种后端 iperf3数据落点：perf-data/P5/04-vdpa-sim.md（vdpa_sim 拓扑截图、三种后端吞吐对比、guest dmesg 中 virtio_net probe 日志）。模拟器没有性能意义，价值在于把注册/probe/数据面 relay 这条链路完整走一遍。下一篇：P5-05 · rte_flow offload 实测：SW vs HW 路径对比

P5-03 · virtio 与 vhost-user：虚拟化的数据面协议 对应路线图：Phase 5 (Day 141-168) ｜ DPDK 24.11.6 LTS ｜ 内核对照 v6.6代码出处：source/linux-stable/drivers/net/virtio_net.c、source/linux-stable/drivers/vhost/net.c、source/dpdk-stable-24.11.6/lib/vhost/vhost_user.c上一篇：P5-02 VFIO ｜ 下一篇：P5-04 vDPA一句话定位虚拟机没有真网卡，于是 virtio 造了台"纸面网卡"：guest 里跑一个标准驱动，host 上跑一个后端，中间用三段共享内存队列（virtqueue）通信。协议只有两个动作——guest 往 avail ring 塞条目并 kick，后端往 used ring 写结果并注入中断。vhost-user 则是把这个后端从内核挪进 DPDK 用户态进程。协议骨架（virtio 规范，公开知识）Split virtqueue 三段（全在 guest 内存里，GPA 对 host 可见）：Descriptor Ring（guest 描述每段缓冲的 addr/len/flags）、Avail Ring（guest 公布"哪些描述符可用"）、Used Ring（后端公布"哪些已完成"）。单方向通信靠下标（idx）推进，双向通知靠 kick（guest→host）和中断注入（host→guest）。packed virtqueue 把三段压成一个环，用环内标志位代替 avail/used 两段，省 cache 访问。真实源码精读① Guest 侧：收包靠"预填空 buffer"（drivers/net/virtio_net.c:2044-2071）static bool try_fill_recv(struct virtnet_info *vi, struct receive_queue *rq, gfp_t gfp) { int err; bool oom; do { if (vi->mergeable_rx_bufs) err = add_recvbuf_mergeable(vi, rq, gfp); else if (vi->big_packets) err = add_recvbuf_big(vi, rq, gfp); else err = add_recvbuf_small(vi, rq, gfp); oom = err == -ENOMEM; if (err) break; } while (rq->vq->num_free); if (virtqueue_kick_prepare(rq->vq) && virtqueue_notify(rq->vq)) { // ...省略统计计数 ... } return !oom; }和 P1-05 的 ixgbe refill 一个哲学：buffer 是提前挂进队列的。收包路径 virtnet_receive（:2140）只做"从 used ring 取条目 → 交给协议栈"，然后在空闲过半时补货： // virtio_net.c:2166-2173，节选 if (rq->vq->num_free > min((unsigned int)budget, virtqueue_get_vring_size(rq->vq)) / 2) { if (!try_fill_recv(vi, rq, GFP_ATOMIC)) { spin_lock(&vi->refill_lock); if (vi->refill_enabled) schedule_delayed_work(&vi->refill, 0); spin_unlock(&vi->refill_lock); } }注意这个和 DPDK PMD 的区别：virtio-net 是软中断驱动（virtnet_poll 在 :2218），受 budget 约束；它只是"和真网卡驱动长得一样"的前端驱动，真正的包搬运在后端。② 内核后端 vhost-net：数据面线程 + 双模式（drivers/vhost/net.c:973-997）static void handle_tx(struct vhost_net *net) { struct vhost_net_virtqueue *nvq = &net->vqs[VHOST_NET_VQ_TX]; struct vhost_virtqueue *vq = &nvq->vq; struct socket *sock; mutex_lock_nested(&vq->mutex, VHOST_NET_VQ_TX); sock = vhost_vq_get_backend(vq); if (!sock) goto out; if (!vq_meta_prefetch(vq)) goto out; vhost_disable_notify(&net->dev, vq); vhost_net_disable_vq(net, vq); if (vhost_sock_zcopy(sock)) handle_tx_zerocopy(net, sock); else handle_tx_copy(net, sock); out: mutex_unlock(&vq->mutex); }TX 方向（guest 发包）从 avail ring 取描述符，把数据拷进 host 的内核 socket（handle_tx_copy，:774）或走 zerocopy（:864）。注意"先 disable notify 再干活"：批处理期间关掉 guest 的 kick 通知，防止每包一次 VM exit。RX 方向 handle_rx（:1120）先 peek socket 队列长度（:1167），凑齐 vhost_hlen + sock_hlen（:1159-1160）后 get_rx_bufs 拿 guest 的空 buffer 填包。两条路径都是内核线程在忙，每包要过一次内核 socket。③ vhost-user：后端搬到用户态，直接映射 guest 内存（lib/vhost/vhost_user.c:841-895，节选）translate_ring_addresses(struct virtio_net **pdev, struct vhost_virtqueue **pvq) { // ...省略 log_guest_addr 处理 ... if (vq_is_packed(dev)) { len = sizeof(struct vring_packed_desc) * vq->size; vq->desc_packed = (struct vring_packed_desc *)(uintptr_t) ring_addr_to_vva(dev, vq, vq->ring_addrs.desc_user_addr, &len); if (vq->desc_packed == NULL || len != sizeof(struct vring_packed_desc) * vq->size) { // ...省略错误日志 ... return; } // ...省略 numa_realloc ... len = sizeof(struct vring_packed_desc_event); vq->driver_event = (struct vring_packed_desc_event *) (uintptr_t)ring_addr_to_vva(dev, vq, vq->ring_addrs.avail_user_addr, &len); // ...省略校验与 device_event ...QEMU 通过 vhost-user 协议把三段 ring 的 guest 物理地址发给 DPDK 进程，DPDK 侧把 GPA 翻译成自己的虚拟地址（ring_addr_to_vva），之后直接读写——没有 copy，没有内核 socket。协议消息的处理入口是 vhost_user_msg_handler（:3105-3146）：read_vhost_message（:3133）读 fd，按 request 编号查 vhost_message_handlers 表（:3139-3143）分发；表里 SET_MEM_TABLE / SET_VRING_NUM / SET_VRING_ADDR 三个消息的注册在 :75-79。🐧 内核对照：vhost-net vs vhost-user维度内核 vhost-netDPDK vhost-user后端位置内核线程（handle_tx/handle_rx，net.c:973/1120）用户态 lcore 直接读写 ring数据路径copy 进内核 socket（net.c:774 起）零拷贝，GPA→VVA 后直接操作kick 处理vhost 线程被唤醒eventfd → 用户态轮询每包成本内核 socket 出入栈与 DPDK 收发包同量级中断注入内核负责DPDK 写 used ring 后 kick eventfd，QEMU 注入同一份 virtio 协议，内核实现守"通用"，用户态实现冲"线速"。vhost-user 是 OVS-DPDK 云网络的默认形态，也是理解 DPU 上 virtio 卸载的起点。面试 3 问virtqueue 为什么是"三段式"而不是一个环？ → desc 环描述缓冲（多段 scatter-gather），avail 环让 guest 批量公布可用描述符（可以攒批再 kick），used 环让后端批量回写结果（攒批再中断）——三段分离是批量化和双向通知的结构基础。vhost-user 怎么做到零拷贝？ → QEMU 只传 GPA（SET_VRING_ADDR），DPDK 用 ring_addr_to_vva 翻译成进程内地址直接读写（vhost_user.c:861-883）；对比内核 vhost-net 要走 socket copy。为什么 handle_tx 开头要先 vhost_disable_notify？ → 批处理期间避免 guest 每提交一个包就 kick 一次（每次 VM exit 都是成本），处理完再恢复通知（net.c:987-988）。🔧 动手实验# 1. 启动 DPDK vhost-user 后端（testpmd 起一个 vhost 端口） ./testpmd -c 0xf -n 2 --vdev 'net_vhost0,iface=/tmp/vhost-user.sock' -- -i testpmd> start # 2. QEMU 启动 guest，后端走 vhost-user socket qemu-system-x86_64 -netdev vhost-user,id=n1,chardev=c1,queues=1 \ -chardev socket,id=c1,path=/tmp/vhost-user.sock,server=off ... # 3. guest 内 iperf3 打流，对比两个后端： # a) 同规格 QEMU 换成 -netdev tap + vhost=on（内核 vhost-net） # b) 关闭 vhost（QEMU 纯软件模拟） # 记录三种后端的吞吐/CPU # 4. testpmd 里 show port stats 0，看 virtqueue 方向流量数据落点：perf-data/P5/03-vhost-user.md（三种后端 iperf3 吞吐对比表、testpmd 端口统计、CPU 占用）。J3455 上跑 QEMU 会比较吃力，重点看相对差异而不是绝对值。下一篇：P5-04 · vDPA 框架：把 virtqueue 卸载进硬件

P5-02 · VFIO 源码深读：把设备安全地交给用户态 对应路线图：Phase 5 (Day 141-168) ｜ DPDK 24.11.6 LTS ｜ 内核对照 v6.6代码出处：source/linux-stable/drivers/vfio/pci/vfio_pci_core.c 与 vfio_pci.c，引用均标 文件:行号上一篇：P5-01 DMA/IOVA/IOMMU ｜ 下一篇：P5-03 virtio 与 vhost-user一句话定位DPDK 轮询收包的前提是用户态能直接摸到网卡寄存器、收到网卡中断、让网卡 DMA 自己的内存。VFIO 就是管这三件事的内核设施：mmap 交出 BAR，ioctl 交出中断，IOMMU 兜住 DMA——而且每一步都带着安全检查。真实源码精读① open 即接管：vfio_pci_open_device（vfio_pci.c:103-128）static int vfio_pci_open_device(struct vfio_device *core_vdev) { struct vfio_pci_core_device *vdev = container_of(core_vdev, struct vfio_pci_core_device, vdev); struct pci_dev *pdev = vdev->pdev; int ret; ret = vfio_pci_core_enable(vdev); if (ret) return ret; if (vfio_pci_is_vga(pdev) && ...) { // ...省略 Intel IGD 特殊处理 ... } vfio_pci_core_finish_enable(vdev); return 0; }用户态 open("/dev/vfio/<group>") 最终落到这里。核心动作在 vfio_pci_core_enable（vfio_pci_core.c:470 起）：先 pci_clear_master（:484，清掉上一个使用者留下的 bus master），pci_enable_device（:486），然后强制复位： /* If reset fails because of the device lock, fail this path entirely */ ret = pci_try_reset_function(pdev); // vfio_pci_core.c:491 if (ret == -EAGAIN) goto out_disable_device; vdev->reset_works = !ret; pci_save_state(pdev); // :496open 即 reset：上一个租户（比如虚拟机）把网卡搞到任何脏状态，下一个 open 的人拿到的都是一张干净的卡。这是多租户共享裸机场景的安全底线。② ioctl 分发表：vfio_pci_core_ioctl（vfio_pci_core.c:1452-1479）long vfio_pci_core_ioctl(struct vfio_device *core_vdev, unsigned int cmd, unsigned long arg) { struct vfio_pci_core_device *vdev = container_of(core_vdev, struct vfio_pci_core_device, vdev); void __user *uarg = (void __user *)arg; switch (cmd) { case VFIO_DEVICE_GET_INFO: return vfio_pci_ioctl_get_info(vdev, uarg); case VFIO_DEVICE_GET_IRQ_INFO: return vfio_pci_ioctl_get_irq_info(vdev, uarg); // ...省略 HOT_RESET 相关两条 ... case VFIO_DEVICE_GET_REGION_INFO: return vfio_pci_ioctl_get_region_info(vdev, uarg); case VFIO_DEVICE_IOEVENTFD: return vfio_pci_ioctl_ioeventfd(vdev, uarg); // ...省略 PCI_HOT_RESET / RESET ... case VFIO_DEVICE_SET_IRQS: return vfio_pci_ioctl_set_irqs(vdev, uarg); default: return -ENOTTY; } } EXPORT_SYMBOL_GPL(vfio_pci_core_ioctl);整个接口面就这 9 个命令。对 DPDK 最关键的两个：GET_REGION_INFO（问清楚每个 BAR 的 offset/大小/可否 mmap），SET_IRQS（把 MSI-X 中断注册成 eventfd——DPDK 的 eal_interrupt 用 epoll 等它）。挂载点在 vfio_pci_ops 虚表里（vfio_pci.c:130-144，.ioctl = vfio_pci_core_ioctl 在 :136）。③ BAR mmap：物理页映射 + 属性钳制（vfio_pci_core.c:1690-1759，节选）int vfio_pci_core_mmap(struct vfio_device *core_vdev, struct vm_area_struct *vma) { // ...省略 container_of 和 index 计算 ... index = vma->vm_pgoff >> (VFIO_PCI_OFFSET_SHIFT - PAGE_SHIFT); if (index >= VFIO_PCI_NUM_REGIONS + vdev->num_regions) return -EINVAL; // ...省略合法性检查 ... if (!vdev->bar_mmap_supported[index]) return -EINVAL; // ...省略 barmap 申请（pci_request_selected_regions） ... vma->vm_private_data = vdev; vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); // :1748 vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot); // :1749 // ...省略注释 ... vm_flags_set(vma, VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP); // :1756 vma->vm_ops = &vfio_pci_mmap_ops; return 0; }三个细节：① pgprot_noncached——BAR 是设备寄存器语义，绝不能用 cache 语义（缓存了寄存器读写的值就是灾难）；② VM_PFNMAP——这段 vma 背后是物理页帧而不是普通匿名页，缺页路径走 vfio_pci_mmap_ops 的 fault handler 逐页 map；③ VM_DONTDUMP——core dump 时不 dump 这段，避免崩溃时把设备寄存器状态拷出来。安全不是"禁止访问"，而是"把访问钳制在设备该有的语义里"。🐧 内核对照：正常内核驱动 vs VFIO 用户态直通维度内核驱动（如 P4-03 的 mini 驱动）VFIO寄存器访问probe 里 ioremap，内核态读写用户态 mmap BAR 直接读写（:1690）中断处理注册 irq handler，软中断收包eventfd 通知用户态 epoll（SET_IRQS）DMA 安全内核统一管，设备可访问全部内存IOMMU 限制在映射范围内（P5-01）故障面驱动 bug → 内核崩溃应用 bug → 最多杀应用 + 设备复位（:491）性能中断 + 协议栈开销轮询 + 零拷贝（P1-05 的对比）VFIO 的哲学是把"驱动"从内核搬到用户态，但只搬运行权，不搬安全权——权限检查、复位、隔离都留在内核。面试 3 问为什么 VFIO 的 mmap 要设置 pgprot_noncached？ → BAR 是设备寄存器语义，必须绕过 CPU cache（vfio_pci_core.c:1748）；配合 VM_IO | VM_PFNMAP（:1756）让内核以物理页帧方式管理这段 vma。用户态程序拿到设备后搞挂了怎么办？ → open 时先 pci_try_reset_function（:491），下次打开自动复位；应用退出时走 close 路径收回资源（vfio_pci_ops.close_device = vfio_pci_core_close_device，vfio_pci.c:135），release 在 :133。VFIO 和 UIO 的核心区别？ → UIO 只是简单的中断直通，没有 IOMMU 隔离，DMA 可写全物理内存；VFIO 强绑定 IOMMU group，把 DMA 限制在映射范围内，还支持完整 MSI-X、VF 直通等（group 语义见 drivers/vfio/group.c，本阶段未逐行深读）。🔧 动手实验# 1. 绑定网卡到 vfio-pci modprobe vfio-pci dpdk-devbind --bind=vfio-pci 03:00.0 # 2. 观察三件事 lspci -v -s 03:00.0 | grep "Kernel driver" # 期望 vfio-pci ls /dev/vfio/ # 期望出现 group 设备节点 dmesg | tail -20 # 看 vfio-pci probe 日志 # 3. testpmd 跑通并抓 EAL 日志里的 VFIO 初始化（region/irq 信息） ./testpmd -c 0x3 -n 2 -- -i # 4. 反向实验：vfio-pci 未加载时跑 testpmd，记录报错 # 再对比 igb_uio/vfio-pci 两种模式下的中断延迟（PPS）数据落点：perf-data/P5/02-vfio-bind.md（bind 前后 lspci/dmesg 对比、testpmd 启动日志、两种内核驱动绑定方式的 PPS）。J3455 只有一块 82599 的话，注意实验间隙要把网卡绑回 ixgbe 供日常使用。下一篇：P5-03 · virtio 与 vhost-user：虚拟化的数据面协议

P5-01 · DMA/IOVA/IOMMU：设备看到的地址，从来不是你 malloc 出的那个 对应路线图：Phase 5 (Day 141-168) ｜ DPDK 24.11.6 LTS ｜ 内核对照 v6.6代码出处：source/linux-stable/drivers/iommu/dma-iommu.c、source/dpdk-stable-24.11.6/lib/eal/linux/eal.c，引用均标 文件:行号上一篇：P4-03 最小 PCIe 驱动 ｜ 下一篇：P5-02 VFIO一句话定位CPU 用页表把 VA 变成 PA，设备做 DMA 时也要有一套自己的"页表"：IOMMU 页表。IOVA 就是设备视角的虚拟地址——没有 IOMMU 时 IOVA 直接等于 PA，有 IOMMU 时内核替你维护 IOVA→PA 的映射。DPDK 的 mempool 写进网卡描述符的"物理地址"，本质都是 IOVA。真实源码精读① 内核的 DMA 抽象：每设备一张 dma_map_ops 虚表（dma-iommu.c:1613-1636）static const struct dma_map_ops iommu_dma_ops = { .flags = DMA_F_PCI_P2PDMA_SUPPORTED, .alloc = iommu_dma_alloc, .free = iommu_dma_free, .alloc_pages = dma_common_alloc_pages, .free_pages = dma_common_free_pages, // ...省略 alloc_noncontiguous / mmap / get_sgtable ... .map_page = iommu_dma_map_page, // :1623 .unmap_page = iommu_dma_unmap_page, .map_sg = iommu_dma_map_sg, // :1625 .unmap_sg = iommu_dma_unmap_sg, // ...省略 sync_* / map_resource ... };驱动代码从来不直接调 iommu_map，而是调 dma_map_sg() 宏 → 落到 dev->dma_ops->map_sg。IOMMU 打开时指向这张表，关掉时指向直通实现——上层驱动一行不用改，这就是内核 DMA-API 分层的意义。② iommu_dma_map_sg：先算总长度，再一次性分配 IOVA（dma-iommu.c:1332-1349） if (!iova_len) return __finalise_sg(dev, sg, nents, 0); iova = iommu_dma_alloc_iova(domain, iova_len, dma_get_mask(dev), dev); if (!iova) { ret = -ENOMEM; goto out_restore_sg; } /* * We'll leave any physical concatenation to the IOMMU driver's * implementation - it knows better than we do. */ ret = iommu_map_sg(domain, iova, sg, nents, prot, GFP_ATOMIC); if (ret < 0 || ret < iova_len) goto out_free_iova; return __finalise_sg(dev, sg, nents, iova);三步走，跟我 P0 学的内存池一个思路——先要一块连续的 IOVA 空间，再把 sg 里散落的物理页逐段映射进去。__finalise_sg（:1349）把算好的 IOVA 写回每个 sg_dma_address，驱动接下来只跟 IOVA 打交道。函数签名在 :1241-1242，开头还要处理 sg 段对齐（:1275 起 for_each_sg 的 pad 逻辑）。③ 挂载点：IOMMU 可用时偷换 dev->dma_ops（dma-iommu.c:1642-1663）void iommu_setup_dma_ops(struct device *dev, u64 dma_base, u64 dma_limit) { struct iommu_domain *domain = iommu_get_domain_for_dev(dev); if (!domain) goto out_err; // ...省略注释... if (iommu_is_dma_domain(domain)) { if (iommu_dma_init_domain(domain, dma_base, dma_limit, dev)) goto out_err; dev->dma_ops = &iommu_dma_ops; // :1656 关键一行 } return; out_err: pr_warn("Failed to set up IOMMU for device %s; retaining platform DMA ops\n", dev_name(dev)); }设备注册时调用一次，之后所有 DMA API 全部改道 IOMMU 路径。注意 :1661 的失败路径：IOMMU 初始化失败就保留 platform DMA ops（直通 PA）——系统不崩，只是没有隔离，这种"静默降级"排查问题时要想到。④ DPDK 侧：启动时三态选择 IOVA 模式（lib/eal/linux/eal.c:1038-1066） /* if no EAL option "--iova-mode=<pa|va>", use bus IOVA scheme */ if (internal_conf->iova_mode == RTE_IOVA_DC) { /* autodetect the IOVA mapping mode */ enum rte_iova_mode iova_mode = bus_iova_mode; if (iova_mode == RTE_IOVA_DC) { // ...省略 build option / phys addrs 判断 ... } else if (is_iommu_enabled()) { /* we have an IOMMU, pick IOVA as VA mode */ iova_mode = RTE_IOVA_VA; // :1054-1057 } else { /* physical addresses available, and no IOMMU * found, so pick IOVA as PA. */ iova_mode = RTE_IOVA_PA; // :1058-1063 } } rte_eal_get_configuration()->iova_mode = iova_mode;IOVA=VA 是默认最优解：有 IOMMU 就选 VA（mempool 里存的是 mbuf 虚拟地址，IOMMU 页表替设备翻译）；没有 IOMMU 才退回 PA。所以 DPDK 起不来的常见报错之一就是 PA 模式 + 物理地址不可得（eal.c:1072-1076 的检查）。🐧 内核对照：同一件事，谁来做翻译维度内核驱动DPDK抽象层DMA-API（dma_map_ops 虚表，dma-iommu.c:1613）IOVA 全局三态（PA/VA/DC），无 per-device 虚表选择时机设备注册时挂表（:1656）EAL 启动时一次选定（eal.c:1066）映射粒度sg 段级，按需 map/unmapmempool 大块预映射，mbuf 只记 IOVA 偏移失败语义降级直通 + pr_warn（:1661）启动即报错退出（:1072-1076）内核把 DMA 当"每次 I/O 都建立的一段契约"，DPDK 把 IOVA 当"一次启动定死的世界设定"。性能取向不同：内核要通用和隔离，DPDK 要热路径零开销。面试 3 问IOVA 和 PA、VA 什么关系？ → 有 IOMMU 时 IOVA 是设备视角的虚拟地址，由 IOMMU 页表映射到 PA（iommu_map_sg 建表，dma-iommu.c:1345）；无 IOMMU 时 IOVA 就是 PA。VA 是 CPU 视角的虚拟地址，和 IOVA 是两套体系。内核怎么决定走不走 IOMMU？ → 设备注册时 iommu_setup_dma_ops 检查默认域，可用就把 dev->dma_ops 换成 iommu_dma_ops（:1656），失败则保留直通 ops 并打 warning（:1661）。DPDK 的 --iova-mode 为什么默认选 VA？ → 有 IOMMU 时选 VA 可让 mbuf 直接存虚拟地址、避免 PA 碎片问题（eal.c:1054-1057）；没有 IOMMU 且能读 /proc/self/pagemap 才退 PA（:1058-1063）。🔧 动手实验J3455 支持 VT-d，做一次"开关 IOMMU"的对照实验：# 1. 默认开启：dmesg 确认 IOMMU 生效 dmesg | grep -i -E "iommu|dmar" | head # 期望看到 DMAR: IOMMU enabled / dmar irq 等字样 # 2. 跑 testpmd，看 EAL 启动日志的 IOVA 选择 ./testpmd -c 0x3 -n 2 -- -i # 期望日志："Selected IOVA mode 'VA'" # 3. 重启，Grub 内核参数加 intel_iommu=off（关掉 IOMMU） # 再跑 testpmd，日志应变为 "Selected IOVA mode 'PA'" # 4. 两种模式下各跑 5 分钟 rxonly，记录 PPS/CPU数据落点：perf-data/P5/01-iommu-mode.md（两种模式的 EAL 日志、dmesg 证据、PPS 对比）。预期：小包转发下 VA/PA 吞吐基本持平（IOMMU 页表走 cache），但 VA 模式是生产部署的默认答案。下一篇：P5-02 · VFIO 源码深读：把设备安全地交给用户态