P6-03 · 总结篇：18 个月，从 DPDK 用户到 DPU 架构师 对应路线图：Phase 6 (Day 169-196，加速路径收官) ｜ 母本：2026-06-29-dpdk-roadmap-v3-design.md 546 天设计文档（Day 456-546 收口段）上一篇：P6-02 面试题库精选 ｜ 下一篇：全系列完结一句话定位把 18 个月的执行结果摊开：六阶段走到了哪、性能数字兑现了没有、四个出口通向哪里——以及最重要的，路线图开篇的三个问题，现在能不能答上来。起点：先诚实盘点（母本第二章）动笔写路线图那天，我的自评是：DPDK API 中级、用户态协议栈中级、SONiC 入门、内核网络"只看过书没读过源码"、PCIe"没亲手解码过 BAR"。结论只有一句——广度够了，深度不足；能写 demo，写不出线速数据面。这份路线图就是针对这个诊断开的药方。目标：三个"给我"（母本 1.1 节）给我一张 100Gbps 网卡，我能写出单核线速的用户态数据面；给我一颗 DPU/SmartNIC，我能设计它的数据面架构；给我一套 SONiC，我能让它跑在纯 DPDK 软件转发上。六阶段回顾（母本第三章主线）#阶段Day 区间核心交付博客P1DPDK 内功 + 协议栈1-91单核 100Gbps echo + 性能报告P0-01~P1-07P2SONiC×DPDK92-18215 个 SAI API 跑通 L2/L3/ACLP2-01~P2-07P3vSwitch / 云网关183-273VPP plugin + LB 4-tuple hashP3-01~P3-06P4安全数据面274-364抗 5Mpps SYN floodP4-01~P4-03P5DPU 数据面365-45530 页 DPU 架构设计文档P5-01~P5-06P6收口 + 出口456-546简历 + 1 个开源项目P6-01~P6-03（本篇）路径逻辑是螺旋上升：P2 的 sai-dpdk-mini 用 P1 的内功，P3 的 LB 用 P1 的协议栈，P4 的清洗用 P3 的流处理，P5 把前面全部串起来。每一步都在复用上一步，这是路线图设计里我最满意的一点。性能基线：数字先行（母本附录 B）路线图把每个阶段钉死在数字上——"优化过了"和"单核 14.88 Mpps"是两种完全不同的完成标准。下表是写进母本附录 B 的公开承诺，每个阶段的实测数据回填 perf-data/，数字与命令一一对应：场景硬件目标 PPS目标带宽单核 echoX710 10G / 1 core14.88 Mpps (64B)10 Gbps 线速多核 echoCX5 100G / 8 cores~100 Mpps~100 GbpsOVS-DPDK L2 fwd4 cores20 Mpps80% 线速dpdk-lb4 cores5 Mpps20 Gbpsddos-clean SYN cookie8 cores5 Mpps SYN—Suricata IDS8 cores—10 Gbps（本文初稿随 Phase 6 第一篇动笔，最终版在 Day 196 收官日按实测数据回填定稿。）方法论三条（值得带走的部分）内核横切对照（母本 4.5 节）：内核学习不是单独排期，而是每周注入 🐧 子任务，K1-K7 七个模块（packet path → NIC 驱动 → TCP/IP → netlink → tc → 虚拟设备 → PCI/VFIO）横切全程，~195h。DPDK 的每个设计都是对内核某一痛点的回应，不读内核就不知道为什么这么设计。每天一个可见产出物（母本 1.3 节）：commit / 笔记 / 数据 / 图，没有产出物的一天等于没学。546 天 × 1 个产出物，就是 546 份证据。阶段答辩：每个阶段末尾自问自答（P1 七篇每篇 2-3 问、P6 20 题对照题库），答不上来就说明这三个月有水分，回去补。出口映射（母本第六章）出口关键阶段简历卖点时机一线大厂网络团队P1+P3+P5单核 100Gbps 协议栈 / DPU 架构设计M15 末投递DPU 厂商P5 主 + P2 副SAI-DPDK 适配器 / rte_flow offload 验证M15 末投递现公司晋升专家P2+P4SONiC×DPDK 融合落地 / DDoS 清洗 5MppsM12 末申报开源 / 个人品牌全程libmtcp-v3 + sai-dpdk-mini + 博客M18简历是长出来的，不是写出来的——每个阶段结束更新一版（v1→v6）。系列博客全目录（39 篇）P0 地基（7）：cache line → NUMA → PCIe → 无锁 MPSC → perf/火焰图 → gdb → 内核网络栈初探P1 DPDK 内功（7）：EAL → mempool → ring → mbuf → PMD → NUMA/lcore → RSS/rte_flowP2 libmtcp（7）：mTCP 论文精读 → mTCP 源码架构 → 内核 TCP 状态机对照 → libmtcp-v3 设计 → 实现（上）RX/TX → 实现（下）状态机与 RTO → 调优实录P3 OVS+SAI（6）：OVS 数据面 → 调优实战 → SONiC 链路 → SAI 头文件 → sai-dpdk-mini → host_if/BGPP4 PCIe（3）：Config Space/BAR → MSI-X → 从 0 写内核驱动P5 DPU 核心（6）：DMA/IOVA → VFIO 源码 → virtio/vhost → vDPA → rte_flow offload → 厂商调研P6 收口（3）：DPU 架构设计 → 面试题库 20 题 → 本篇（39 篇全部就位；总表与状态见 blog/README.md。）回头看：三个问题的答案① 给我 100G 网卡，能写单核线速数据面吗？ 能。而且我知道为什么能：mempool 预分配消灭逐包分配（P1-02）、ring 的 CAS+tail 发布消灭锁（P1-03）、PMD 轮询消灭中断（P1-05）、对称 RSS 保证 per-core 免锁表（P1-07）——168 cycles/pkt 的预算（P6-01 算过）就是靠这四件事省出来的。② 给我 DPU，能设计数据面架构吗？ 能。fast/slow path 划界、HW/FW/SW 三层卸载判据、SR-IOV/SF/vDPA 三种多租户隔离、PCIe 带宽与 PPS/时延预算模型（P6-01）——P5 的 PCIe/VFIO/vDPA/offload 四块积木拼起来就是答案。③ 给我 SONiC，能让它跑在纯 DPDK 软件转发上吗？ 能。APPL_DB → ASIC_DB → sairedis → syncd 的链路读透了（P3-03/P3-04），sai-dpdk-mini 把 15 个 SAI API 翻译成 rte_hash/rte_lpm/rte_flow，host_if 用 TAP 桥接让 FRR/BGP 建邻居（P3-05/P3-06）。三个问题，39 篇博客，546 个勾选框。这就是"会调 API"和"能设计系统"之间的距离。🔧 行动清单（对应母本 Day 456-546，W66-W78）W66 (456-462)：项目盘点四选一（libmtcp-v3 / sai-dpdk-mini / dpdk-lb / ddos-clean）→ P6/project-eval.md；W68-69 (470-483)：v1.0 release + CI + benchmark 套件 + Docker 化；W70-72 (484-504)：三篇引爆博客各一周——第三篇的选题就是母本 Day 498 的"18 个月从 DPDK 用户到 DPU 架构师"，即本篇的公开版；W73 (505-511)：简历定稿三版本（大厂版/DPU 厂商版/安全版），每个项目改成"动词+数字+技术"格式；W74-75 (512-525)：题库 200 题——Day 515 的内核对照 20 题即 P6-02，Day 522 的 DPU 架构 20 题种子在 P6-01；W76-78 (526-546)：系统设计 3 题（CDN/清洗中心/智能网卡卸载）+ 两轮模拟面试 + 投递跟进 + 总复盘（Day 542 万字复盘，Day 546 收官答辩）。18 个月很长，但日子是一天一天过的。 不用每一天都完美执行，但每天都必须有一个可见的产出物。当回头看 Day 1 到 Day 546 的勾选状态时，你的实力会比任何一份简历都更有说服力。— 起算日 2026-06-29，目标交付日 2027-12-27。我们 546 天后见。下一篇：全系列完结。 谢谢阅读，评论区见。

P6-02 · 面试题库精选：内核 vs DPDK 对照 20 题，每题答案都指向源码行 对应路线图：Phase 6 (Day 169-196) ｜ 母本任务 Day 515（"内核 vs DPDK"对照题 20 道）出处：source/dpdk-stable-24.11.6/ 与 source/linux-stable/（v6.6）及 source/sonic-sairedis/，行号全部逐条核对过上一篇：P6-01 自研 DPU 架构 ｜ 下一篇：P6-03 总结篇一句话定位对照题是面试题库里性价比最高的一类：一道题考两套体系，答出来等于同时证明你懂内核和懂 DPDK。与 P1 七篇的自测题不重复——P1 考"是什么、在哪一行"，这 20 题考"两套设计为什么不同"。主题 1 · skb vs mbuf（Q1-3）Q1. 为什么 DPDK 不直接复用 struct sk_buff？sk_buff 要服务通用内核栈：引用计数共享（clone）、非线性 frag 页、四个协议头指针、drop reason 跟踪，结构臃肿（include/linux/skbuff.h:843 起）。mbuf 是"为线速转发重新设计"：双 cache line 布局，热字段（data_off/refcnt/nb_segs/port）打包进 8 字节 rearm_data 一次 store 复位（lib/mbuf/rte_mbuf_core.h:467, 488-514，P1-04 已读）。差异根源：skb 服务"任意 socket"，mbuf 服务"单一转发路径"。Q2. 为什么 skb 释放不能直接回池，mbuf 可以？skb 释放要过引用计数：skb_release_data（net/core/skbuff.c:962）检查 dataref、逐个释放 frag 页——因为 skb 可能被 clone 共享。mbuf 回池是 O(1)：rte_pktmbuf_free（lib/mbuf/rte_mbuf.h:1415）塞回 per-lcore cache。本质：skb 数据被多方持有，mbuf 生命周期由应用显式管理。Q3. 两边的"零拷贝"手段各是什么？skb 侧靠 frag 列表：数据放 page，skb_shared_info 挂 nr_frags，复制只复制 skb 头。mbuf 侧两招：chain（next 串多段）和 attach 外部 buffer——rte_pktmbuf_attach（lib/mbuf/rte_mbuf.h:1165）让多个 mbuf 指向同一 extbuf。skb 的 frag 面向协议栈收包，mbuf 的 attach 面向应用层零拷贝（隧道封装/广播）。主题 2 · NAPI vs PMD（Q4-6）Q4. 内核收包路径 vs DPDK 收包路径，中间差了什么？内核：硬中断 → NAPI 调度（napi_poll，net/core/dev.c:6707）→ 软中断预算内轮询 → GRO → 协议栈 → socket 拷贝+唤醒。DPDK：应用直接 rte_eth_rx_burst → PMD 轮询描述符（ixgbe_recv_pkts，drivers/net/ixgbe/ixgbe_rxtx.c:1784）→ mbuf 交给应用。少的四样：中断上下文切换、软中断调度、GRO/socket 两层拷贝、进程唤醒。Q5. NAPI 的 budget/weight 解决什么问题？DPDK 为什么没有？每轮 poll 最多收 NAPI_POLL_WEIGHT=64 个包（include/linux/netdevice.h:2633），net_rx_action（net/core/dev.c:6816）还有总预算和 2ms 时间片——防止软中断饿死其他任务。DPDK lcore 独占，无预算，burst 上限由应用定（ixgbe_rxtx.c:1812 的 while (nb_rx < nb_pkts)）——用 100% CPU 换确定性。Q6. 内核驱动的"中断合并"（interrupt moderation）是干什么的？DPDK 有吗？低负载靠中断省 CPU，高负载自动转轮询：ixgbe_update_itr（drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:2517）按流量动态调 EITR 寄存器。DPDK 没有这个概念——中断直接关掉永远全速轮询，代价是 CPU 常驻 100%。这题答的是"两种哲学"：自适应 vs 确定性。主题 3 · slub vs mempool（Q7-8）Q7. slub 的 per-CPU cache 和 mempool 的 per-lcore cache 是不是一回事？思想相同（本地缓存摊薄全局锁），结构不同。slub：cpu_slab->freelist 单对象栈，本地空了走 partial 链表跨 CPU 补货（get_partial，mm/slub.c:2408）。mempool：批量数组 + 1.5 倍 flushthresh 水位（struct rte_mempool_cache，lib/mempool/rte_mempool.h:90），一次从共享 ring 补货 cache_size 个。___slab_alloc（mm/slub.c:3107）与 rte_mempool_do_generic_get 的三级路径结构同构——这是 P1-02 对照的升级考法。Q8. 内核为什么不干脆把所有 skb 预分配好？三个约束：① skb 数据区大小按 MTU/协议变化，对象尺寸不固定；② 全局数量不可预知（任意 socket 都在产生包）；③ 内核必须承受内存回收压力。DPDK 场景三个都反过来：固定大小、固定网卡、启动时申请全部大页，之后零分配——所以 mempool 敢预分配。主题 4 · kfifo vs rte_ring（Q9-10）Q9. kfifo 声称"无锁"，和 rte_ring 的无锁是同一回事吗？不是。kfifo 的免锁前提苛刻：单生产者单消费者，且 in/out 下标各归一方独占写（__kfifo_in，lib/kfifo.c:113），连 CAS 都不用。rte_ring 支持 MP/MC：__rte_ring_do_enqueue_elem（lib/ring/rte_ring_elem_pvt.h:321-336）里生产者先 CAS 抢 head 区间（:329），数据写完 tail 才发布（:336）——多生产者免锁靠的是"先占位、后发布"。Q10. 为什么内核队列普遍要求 2 的幂大小？kfifo 用 roundup_pow_of_two（lib/kfifo.c:31）强制对齐，把回绕后的重新线性化变成位与操作；in-out 计数用 unsigned 回绕溢出，天然区分满/空。rte_ring 同理：head/tail 用 uint32 允许回绕 + mask 索引（P1-03 Q3 已证模 2^32 减法）。同一个数学技巧，两套代码都在用。主题 5 · tc flower vs rte_flow（Q11-13）Q11. 一条 tc flower 规则在内核里怎么生效？tc 命令 → netlink 下发 → 收包路径 fl_classify（net/sched/cls_flower.c:313）逐字段提取 fl_flow_key 与规则 mask 比对，命中执行 action（mirred 转发/丢弃）。全软件：每个包都要花 CPU 查表——这就是为什么 OVS 要有 EMC/dpcls 两级缓存（P3-01）。Q12. rte_flow 的 pattern/action 模型强在哪？rte_flow_create（lib/ethdev/rte_flow.c:406）的 pattern/action/attr 三元组：group 分级、priority 定序、ingress/egress 定方向。规则可直接下网卡硬件（TCAM/哈希），匹配在硬件完成；同一套 API 可软可硬、跨厂商。tc flower 做不到这个抽象高度——它的语义绑定内核转发平面。Q13. 内核也有 flow offload，和 DPDK 的差别？内核 flow_block 机制（tcf_block_offload_init，net/sched/cls_api.c:747）把 flower 规则回调给驱动下硬件，但 offload 失败要回退软件、要兼容 tc 语义。DPDK 的 rte_flow 设计第一天就面向卸载：语义即硬件语义，没有回退包袱。答出"回退负担"这个点，面试官就知道你真读过（P5-05 实测过 SW/HW 对比）。主题 6 · netlink vs sairedis（Q14-15）Q14. 内核怎么把"添加 IP 地址"这类配置下到内核？netlink：rtnetlink_rcv_msg（net/core/rtnetlink.c:6368）按消息类型分派到 do 函数，如 rtnl_newlink（net/core/rtnetlink.c:3744）直接改内核数据结构。消息即状态，全系统只有这一条通道。Q15. SONiC 为什么不用 netlink，要造 sairedis + Redis？netlink 绑定单一内核实例。SONiC 要跨容器、跨进程、厂商无关：sairedis 把 SAI API 调用序列化后写 Redis——ClientSai.cpp:488（source/sonic-sairedis/lib/）的 m_communicationChannel->set(key, entry, REDIS_ASIC_STATE_COMMAND_CREATE)，syncd 订阅后翻译成硬件操作。多 ASIC、热重启、多进程协作全靠这个解耦通道。代价：多一跳 Redis，时延换灵活性。主题 7 · RPS/RFS vs 硬件分流（Q16-17）Q16. RFS 的 rps_sock_flow_table 想解决什么？DPDK 需要吗？RPS 把流分到 CPU，但应用可能在别的核上收。RFS 的全局表（rps_sock_flow_table，net/core/dev.c:4591）记住流上次被哪个 CPU 的 recvmsg 消费，收包优先送那个核——减少跨核唤醒。DPDK 不需要：轮询核就是应用核，RSS 保证同流同核（P1-07）。这题考的是"为什么 DPDK 的模型天然简化了问题"。Q17. XDP_REDIRECT 的 cpumap 和 DPDK 跨核 pipeline 的对应关系？xdp_do_redirect（net/core/filter.c:4479）把包从驱动核重定向到指定 CPU 的 per-CPU 队列——对应 DPDK pipeline 模型里 lcore 间用 rte_ring 传 mbuf。差别：内核要软中断驱动、排队在 backlog（enqueue_to_backlog，net/core/dev.c:4882），DPDK 直接批量入 ring，还免了中断唤醒。主题 8 · VFIO / vDPA（Q18-20）Q18. VFIO 做到"安全直通"靠哪三件事？① IOMMU 把设备 DMA 关进 IOVA 范围（DMA 隔离）；② mmap BAR 到用户态（寄存器访问）；③ 中断经 eventfd 送到用户态。vfio_pci_core_ioctl（drivers/vfio/pci/vfio_pci_core.c:1452）分发这三类请求；DPDK 侧入口是 rte_vfio_enable（lib/eal/linux/eal_vfio.c:1081）。P5-02 深读过，这里要能三句话收口。Q19. 内核 vDPA framework 和 DPDK vDPA 各干什么？内核负责控制面：__vdpa_alloc_device / vdpa_register_device（drivers/vdpa/vdpa.c:157, 265）提供抽象设备 + config_ops 回调，virtio_vdpa 把它包装成 VM 眼中的标准 virtio 设备。DPDK 负责数据面：rte_vdpa_register_device（lib/vhost/vdpa.c:74）——virtqueue 直接映射进硬件 DMA，数据搬运不经过 Host CPU（P5-04）。Q20. DPDK 早期用 UIO，为什么现在一律 VFIO？UIO 只有 mmap（uio_mmap，drivers/uio/uio.c:762），没有 IOMMU 隔离——故障/恶意设备可 DMA 任意内存，中断也不能安全路由。VFIO 有完整 IOMMU + 中断 + 生态。生产环境合规（多租户/云）是决定性理由。答这题记得补一句：UIO 至今还在内核里，只是 DPDK 新代码默认 VFIO。面试 3 问（如果只背 3 题，背这三题）Q4：能画出内核 8 步 vs DPDK 3 步的两条收包链；Q9：kfifo 与 rte_ring 的"免锁"边界（SPSC vs CAS 占位发布）；Q18：VFIO 三件事——IOMMU、mmap BAR、中断。🔧 行动清单（对应母本 Day 456-546）把这 20 题并入 career/qa-kernel.md（母本 Day 515 任务），每题答案下面贴一行源码引用；Day 522 DPU 架构题 20 道写作时，以 Q18/Q19 为种子扩写 vDPA/多租户；Day 530-531 模拟面试前全文过一遍，每道题控制在 60 秒内答完要点 + 背出两个行号；面试官追问"你确定？"时，把对应源码文件当场调出来对——这就是行号式答案的底气。下一篇：P6-03 · 总结篇：18 个月，从 DPDK 用户到 DPU 架构师

P6-01 · 自研 DPU 数据面架构设计（精华版）：一张图装下 fast path、三层卸载与多租户 对应路线图：Phase 6 (Day 169-196) ｜ 母本收口 Phase P6 (Day 456-546)设计文档本体：code/dpu-arch-design/（六章骨架，正文随 Day 435-441 任务补完）｜ DPDK 24.11.6 LTS ｜ 内核对照 v6.6上一篇：P5-06 DPU 厂商调研 ｜ 下一篇：P6-02 面试题库精选一句话定位把前 196 天学的东西——PMD 轮询、mempool、PCIe/VFIO、vDPA、rte_flow offload——收敛成一份能拿去 DPU 面试的架构设计。本文是 30 页设计文档的精华版：先说结论，再给推导。文档现状（先说实话）code/dpu-arch-design/chapters/ 下已有六章骨架：motivation / dataplane / offload / controlplane / multitenant / performance，与路线图 W63（Day 435-441）的写作任务一一对应。本文先发精华版，30 页完整版随这些 Day 任务逐章补完——这就是 P6 收口阶段"先提炼、后展开"的打法。Ch.1 Motivation：云厂商为什么要 DPU三个痛点，一个都不难讲：CPU 被网络吃掉。公有云上虚拟网络（隧道封装/加解密/防火墙）吃掉的 CPU 是"卖不出去的算力"，AccelNet（NSDI'18，P5 已读）的出发点就是把网络从租户 CPU 剥离。租户隔离。纯软件交换的隔离性依赖内核正确性，邻居打流会影响你的时延——性能不可预测。按量计费需要确定性。P99 时延才是云厂商卖的东西，抖动比吞吐更致命。卸载原则一句话：高频机械动作卸载，有状态低频动作留 CPU。L2/L3 查表、隧道封装、ACL 匹配是机械动作；首包学习、异常处理、TCP 状态机不是。这个"原则"不是拍脑袋：P1 读过 PMD 轮询（高频动作交给硬件 DMA+DD 位协议，P1-05）、P5 实测过 rte_flow offload 的 SW/HW 路径差异（P5-05）——每一层"该不该卸"的判断都有源码和实测数据垫底。Ch.2 数据面：fast path / slow path 的边界这是 OVS upcall 模式的硬件版（P3-01 OVS-DPDK 已经打过底）：slow path（SW 层）：首包、异常包、BGP 控制包上送 ARM 核上的 DPDK 数据面，学习出完整转发决策；fast path（HW 层）：学习结果编译成流表条目下发硬件，后续包在 ASIC 里完成 L2/L3/VXLAN/ACL/NAT，零 CPU 参与；流表有容量上限 → 老化/驱逐由 FW 层上报，SW 层决策。母本 uNOS 设计里"RSS + Graph Pipeline + per-core 流缓存"（uNOS_DESIGN_SPEC.md 2.2 节）就是 SW 层数据面的现成实现——DPU 的 slow path 就是一台浓缩的 uNOS。Ch.3 卸载分层：HW / FW / SW 三层各干什么层载体职责判据HWASIC（TCAM/LPM/counter/meter）线速匹配与改写确定性高、容量足、高频FWFirmware流表编排、DMA 引擎、计数器/老化上报HW 与 SW 之间的机械桥梁SWARM cores（DPDK/OVS）首包/异常/协议状态机、控制代理可编程、低频、有状态判断"什么该卸载"问自己三个问题：这条路径上每个包都要做吗？容量够吗？语义稳定吗？ 三个都是"是"就下硬件。内核侧的同类接口是 devlink（卸载配置通道，母本 W63 Day 436 对照任务）——DPU 的控制面接口就是它的加强版。Ch.4 控制面接口：借鉴 SONiC SAI 的思路编排器（云平台）→ 北向 gRPC/Netconf → 控制代理（SW 层进程）→ 南向翻译成 HW/FW 规则。关键设计：统一抽象、厂商无关：SAI 的思路（P3-04 已读）——控制代理之上只有对象模型，之下适配各家 DPU SDK；WARM 式热重启：规则全部可重建，重启控制代理不丢数据面状态；事件上报：计数器、流表满、链路事件经控制代理回推编排器——sairedis 的 Pub/Sub 模式（P6-02 Q15 详讲）。Ch.5 多租户隔离：SR-IOV / SF / vDPA 三选一方案隔离边界性能数量/迁移VF 直通（SR-IOV）IOMMU 页表级最好（裸金属级）VF 数量受限、热迁移难SF（Scalable Function）软硬协同的轻量 PF接近直通数量多，BlueField 主推vDPA 半虚拟化virtqueue + IOMMU好（virtqueue 卸载进硬件）可热迁移（P5-04 vDPA）选择逻辑：要隔离和极致性能 → VF；要密度 → SF；要云化运维（迁移/快照）→ vDPA。三个都是"Host CPU 零参与数据面"。多租户不只是"分得开"，还要"分得稳"：VF 之间的 P2P 攻击靠 ACS 挡（P4 PCIe 扩展能力已读），DMA 越界靠 IOMMU 页表挡（P5-02 VFIO）——隔离边界最终落在硬件上，这是 DPU 架构答辩的高频追问点。Ch.6 性能预算模型：PPS / 带宽 / 时延怎么算① PPS 换算：以太网 64B 小包上线上是 84B（8B 前导 + 12B 帧间隔），所以 10G 线速 = 10e9 / (84×8) ≈ 14.88 Mpps；100G = 148.8 Mpps。附录 B 的单核目标就是这么来的。② 每包 CPU 预算：单核 2.5GHz / 14.88 Mpps ≈ 168 cycles/pkt（10G）；100G 分 8 核 → 148.8/8 ≈ 18.6 Mpps/核 ≈ 134 cycles/pkt。超过这个预算就掉速——所有热路径优化（预取、批量、免锁）都是在省这个预算。反过来推就是"我要卸掉多少才能保住线速"：软件查一次 cuckoo hash ≈ 几十 cycle，查两次就吃掉 1/3 预算，所以 L3 查表必须下硬件。③ 时延预算（三项相加）：时延 ≈ 轮询粒度 + PCIe 往返 + 查表排队 轮询粒度 = burst 大小 / 线速 = 32 包 / 14.88 Mpps ≈ 2.15μs PCIe 往返（DMA 读描述符 + 写数据）≈ 1μs fast path 目标 < 10μs；slow path 首包 10-100μs 可接受（只发生一次）④ PCIe 带宽：100G 网卡双向 200G 流量 + 描述符/元数据开销。Gen3 x16 可用 ≈126 Gbps——不够；Gen4 x16 ≈252 Gbps——够，但别在 DPU 上再挂 200G NVMe。带宽预算是 DPU 板卡设计的第一道闸，这个结论在 P5-01（DMA/IOVA）就埋过伏笔。面试 3 问什么该卸载到 DPU，什么不该？ → 高频机械动作（查表/封装/ACL/计量）卸载；首包/异常/协议状态机留 CPU。判据三问：每个包都做吗？容量够吗？语义稳定吗？fast path 和 slow path 边界怎么划？ → 首包/异常上送 SW 学习，下发硬件流表，后续包硬件线速；流表满/老化由 FW 上报 SW 决策——OVS upcall 模式的硬件版。100G 卡配什么 PCIe 才跑得满？ → 双向 200G > Gen3 x16 的 ~126G，需 Gen4 x16（~252G）；顺带报出 148.8 Mpps 与 134 cycles/pkt 两个预算数。🔧 行动清单（对应母本 Day 456-546）把 code/dpu-arch-design/ 六章骨架补完至 30 页，每章配图（W63 Day 435-441 任务）；做 slides + 答辩稿，找同行评审 + 两轮模拟面试（W64 Day 442-448）；性能预算全部数字与母本附录 B 基线对表，实测数据落 perf-data/；抽出 20 道 DPU 架构题并入面试题库（Day 522 任务），本文的"面试 3 问"是种子题。下一篇：P6-02 · 面试题库精选：内核 vs DPDK 对照 20 题

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 源码深读：把设备安全地交给用户态

P4-03 · 从 0 写一个最小 PCIe 内核驱动：24 行 probe 一切，然后逐行升级 对应路线图：Phase 4 (Day 120-140) ｜ 内核 v6.6 ｜ 实验代码：code/dpu_dev/01_pci/，引用均标 文件:行号上一篇：P4-02 MSI-X ｜ 下一篇：P5-01 DMA/IOMMU一句话定位PCIe 驱动的最小骨架不是操作寄存器，而是参与内核的"设备-驱动匹配协议"：填一张 pci_device_id 表 + 一个 probe 回调，driver core 就会在设备出现时替你调它。code/dpu_dev/01_pci/pci_scan.c 全文件只有 24 行，却能 probe 整条总线上的所有设备——这是每个网卡驱动（ixgbe、mlx5）的同款起点。真实源码精读① 全文件带读：code/dpu_dev/01_pci/pci_scan.c:1-24#include <linux/module.h> #include <linux/pci.h> static int probe(struct pci_dev *pdev, const struct pci_device_id *id) { printk("pci_scan: %04x:%04x (rev %02x) BAR0=%llx IRQ=%d\n", pdev->vendor, pdev->device, pdev->revision, pci_resource_start(pdev, 0), pdev->irq); return 0; } static struct pci_device_id ids[] = { { PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 }, { 0, } }; MODULE_DEVICE_TABLE(pci, ids); static struct pci_driver drv = { .name = "pci_scan", .id_table = ids, .probe = probe, }; module_pci_driver(drv); MODULE_LICENSE("GPL");逐行拆：probe 回调（:4-10）：签名 (struct pci_dev *, const struct pci_device_id *) 是 PCI 子系统的硬约定。这里读的 vendor/device/revision 正是 P4-01 里 pci_scan_device 从 Config Space 填进 pci_dev 的（probe.c:2507-2508）；pci_resource_start(pdev, 0) 是 BAR0 物理地址（宏定义 pci.h:2107）；pdev->irq 是内核分配的 IRQ 号（pci.h:420）。返回 0 = "这个设备我接管了"。ids 表（:12-16）：全 PCI_ANY_ID 表示匹配所有设备——所以本模块会 probe 系统里每一个 PCI 设备，只能在学习机上玩。真正的驱动用 PCI_DEVICE(0x8086, 0x10fb) 这类精确匹配（宏在 pci.h:962）。表项结构在 mod_devicetable.h:44-50：vendor/device/subvendor/subdevice/class/class_mask 六维过滤 + driver_data 私有数据。module_pci_driver(drv)（:23）：展开成 module_driver(drv, pci_register_driver, pci_unregister_driver)（pci.h:1598-1599），自动生成 init/exit，替换手写 module_init/module_exit 的样板代码。② 匹配与 probe 触发：struct pci_driver 与 driver core（pci.h:928-943）struct pci_driver { struct list_head node; const char *name; const struct pci_device_id *id_table; /* Must be non-NULL for probe to be called */ int (*probe)(struct pci_dev *dev, const struct pci_device_id *id); /* New device inserted */ void (*remove)(struct pci_dev *dev); /* Device removed (NULL if not a hot-plug capable driver) */ // ...省略 suspend/resume/shutdown/sriov/err_handler ... struct device_driver driver; // ... };id_table 注释说得很直白：没有它 probe 就不会被调用。注册入口 __pci_register_driver（pci-driver.c:1451-1467）只做一件事：填 drv->driver.bus = &pci_bus_type 然后 driver_register()——后面就是通用设备模型的 match → probe 机器了。设备侧由 pci_device_probe（pci-driver.c:444-467）接棒：static int pci_device_probe(struct device *dev) { int error; struct pci_dev *pci_dev = to_pci_dev(dev); struct pci_driver *drv = to_pci_driver(dev->driver); // ... pci_assign_irq(pci_dev); error = pcibios_alloc_irq(pci_dev); // ... pci_dev_get(pci_dev); error = __pci_device_probe(drv, pci_dev); // ... }注意顺序：先 pci_assign_irq 分配 IRQ，再进驱动的 probe——所以 probe 里 pdev->irq 一定已经有值。③ remove 与卸载：内核兜底（pci-driver.c:469-510 节选）static void pci_device_remove(struct device *dev) { struct pci_dev *pci_dev = to_pci_dev(dev); struct pci_driver *drv = pci_dev->driver; if (drv->remove) { // ... runtime PM barrier ... drv->remove(pci_dev); // ... } pcibios_free_irq(pci_dev); pci_dev->driver = NULL; // ... }drv->remove 是驱动自己的清理窗口（放走 IRQ、unmap、还资源）；窗口之外的事内核兜底：pcibios_free_irq 收尾 IRQ（:486）、解绑 driver = NULL（:487）。rmmod 会经 pci_unregister_driver（pci-driver.c:1480）对每个被该驱动接管的设备各调一次 remove。④ 升级路线：把"只读"变成"拥有"pci_scan.c 只读不占，等于借设备看了一眼。要真正"拥有"一个 BAR（比如网卡的 MMIO 寄存器区），probe 里按序做四件事（API 均已核实存在）：步骤API位置作用1pci_enable_device(pdev)pci.c:2191打开 IO/MEM decode，唤醒设备2pci_request_regions(pdev, name)pci.c:4273声明 resource 所有权（/proc/iomem 可见）3pci_ioremap_bar(pdev, bar)pci.c:252映射 BAR 到内核虚拟地址4request_irq(pci_irq_vector(pdev, 0), handler, ...)interrupt.h:165挂中断（配合 P4-02 的 MSI-X）remove 里严格逆序：free_irq（interrupt.h:196）→ iounmap → pci_release_regions（pci.c:4254）→ pci_disable_device（pci.c:2379）。🐧 内核机制对照：驱动协议 vs 用户态"野路子"环节内核驱动（本模块）DPDK 用户态（bus/pci）设备发现driver core 匹配 id_table → probe自己扫 /sys/bus/pci/devices/"接管"动作probe 返回 0，设备归属本驱动bind 到 vfio-pci/uio 驱动后拿 fdBAR 访问ioremap → 内核虚拟地址mmap，pci_common_uio.c:178-179中断request_irq + 上半部/NAPI轮询或 epoll 中断线程资源冲突防护pci_request_regions 互斥依赖内核驱动让位（bound to VFIO）DPDK 不是"没有驱动协议"，而是把协议放进了用户态：内核里那个 vfio-pci 驱动替它完成了 probe/接管，用户态只负责 mmap 和轮询。面试 3 问probe 什么时候被调用？ → 设备注册或驱动注册后 driver core 完成 match 即调；前提是 id_table 非 NULL（pci.h:931 注释）；入口 pci_device_probe（pci-driver.c:444）先 pci_assign_irq 再调驱动的 probe（pci-driver.c:453-460）。PCI_ANY_ID 表项的风险？ → 匹配所有设备（pci_scan.c:12-13），probe 返回 0 会接管每一个设备（pci_scan.c:9），真实驱动必须用 PCI_DEVICE 精确匹配（pci.h:962-964）。remove 里不释放资源会怎样？ → IRQ 方面内核会兜底 pcibios_free_irq（pci-driver.c:486），但 ioremap 的地址和 request_regions 占用的 resource 泄漏，再加载驱动会 EBUSY——所以 remove 必须逆序归还（见上表）。🔧 动手实验cd code/dpu_dev/01_pci make # Makefile:1-2，obj-m += pci_scan.o sudo insmod pci_scan.ko dmesg | tail -30 # 每个 PCI 设备一行：vendor:device rev BAR0 IRQ sudo rmmod pci_scan升级练习（在实验机上，不要在主力机上）：给 probe 加 pci_enable_device + pci_request_regions，验证 /proc/iomem 里出现 pci_scan 名字段；再试 pci_ioremap_bar 读 4 字节网卡寄存器与 lspci -xxxx 对拍。数据落点 perf-data/P4/03-pci-scan-dmesg.txt（dmesg 原文 + iomem 段 + 升级版对比）。下一篇：P5-01 · DMA/IOVA/IOMMU：设备怎么看到内存

P4-02 · MSI-X 中断机制：Table 在哪、怎么触发，一个内存写就够了 对应路线图：Phase 4 (Day 120-140) ｜ 内核 v6.6 ｜ 代码出处 source/linux-stable/drivers/pci/msi/ ｜ 上一篇：P4-01 Config Space 与 BAR ｜ 下一篇：P4-03 最小 PCIe 驱动一句话定位MSI-X 把"中断线"变成了"内存写事务"：设备想打断 CPU 时，往一个特殊地址写一个 16 位数据，根复合体（RC）把它翻译成中断投递。每个向量在 MSI-X Table 里有一张 16 字节的表项，存着自己的"地址+数据"。所以问题拆成两个：Table 在哪（Capability 链 → BAR 内偏移），谁写表项（内核用 ioremap 后的 MMIO 直接写）。真实源码精读① 表在哪：从 Capability 链到 BAR 内偏移（msi.c:561-580）static void __iomem *msix_map_region(struct pci_dev *dev, unsigned int nr_entries) { resource_size_t phys_addr; u32 table_offset; u8 bir; pci_read_config_dword(dev, dev->msix_cap + PCI_MSIX_TABLE, &table_offset); bir = (u8)(table_offset & PCI_MSIX_TABLE_BIR); // ...省略（pci_resource_flags 检查，:572-574） table_offset &= PCI_MSIX_TABLE_OFFSET; phys_addr = pci_resource_start(dev, bir) + table_offset; return ioremap(phys_addr, nr_entries * PCI_MSIX_ENTRY_SIZE); }找 Capability：内核沿 Capability 链表（起点 PCI_CAPABILITY_LIST，pci_regs.h:121）找到 ID 为 PCI_CAP_ID_MSIX = 0x11（pci_regs.h:226）的能力结构，缓存偏移到 dev->msix_cap（pci.h:359）；读 Table dword：PCI_MSIX_TABLE（能力内偏移 4，pci_regs.h:327）低 3 位是 BIR（PCI_MSIX_TABLE_BIR，pci_regs.h:328），高 29 位是 BAR 内偏移（PCI_MSIX_TABLE_OFFSET，pci_regs.h:329）；BAR 基址 + 偏移 → ioremap：pci_resource_start(dev, bir) 拿到 P4-01 里解析好的 BAR 物理地址，加偏移直接映射。MSI-X 表项数与 PCI_MSIX_FLAGS（pci_regs.h:323）里的 QSIZE 相关：msi.h:6 定义 msix_table_size(flags) = (flags & PCI_MSIX_FLAGS_QSIZE) + 1——QSIZE 存的是"个数减 1"。② 表项布局与触发：16 字节一张"名片"（pci_regs.h:336-342）/* MSI-X Table entry format (in memory mapped by a BAR) */ #define PCI_MSIX_ENTRY_SIZE 16 #define PCI_MSIX_ENTRY_LOWER_ADDR 0x0 /* Message Address */ #define PCI_MSIX_ENTRY_UPPER_ADDR 0x4 /* Message Upper Address */ #define PCI_MSIX_ENTRY_DATA 0x8 /* Message Data */ #define PCI_MSIX_ENTRY_VECTOR_CTRL 0xc /* Vector Control */ #define PCI_MSIX_ENTRY_CTRL_MASKBIT 0x00000001中断触发不需要任何"电平拉低"：设备做一次 Memory Write TLP，写地址 = 表项里的 address、数据 = data，RC/IOMMU 拦截后路由到本地 APIC/ITS，最终给 CPU 一个向量号。INTx 是物理线共享，MSI-X 是每个向量独享一张名片——这就是多队列网卡每队列一个中断还互不打扰的原因。③ 内核怎么写表项：先 mask 再改（msi.c:205-227，pci_write_msg_msix 节选） /* * The specification mandates that the entry is masked * when the message is modified: * * "If software changes the Address or Data value of an * entry while the entry is unmasked, the result is * undefined." */ if (unmasked) pci_msix_write_vector_ctrl(desc, ctrl | PCI_MSIX_ENTRY_CTRL_MASKBIT); writel(msg->address_lo, base + PCI_MSIX_ENTRY_LOWER_ADDR); writel(msg->address_hi, base + PCI_MSIX_ENTRY_UPPER_ADDR); writel(msg->data, base + PCI_MSIX_ENTRY_DATA);写完 address/data 再解除 mask，并用一次读强制写可见（:231-232）。消息本身来自 msi_desc.msg（msi.h:193），由中断子系统（x86 上多为 irq_matrix / MSI domain）分配。④ 使能全流程：mask 一切，再逐步放开（msi.c:712-766，msix_capability_init 节选） /* * Some devices require MSI-X to be enabled before the MSI-X * registers can be accessed. Mask all the vectors to prevent * interrupts coming in before they're fully set up. */ pci_msix_clear_and_set_ctrl(dev, 0, PCI_MSIX_FLAGS_MASKALL | PCI_MSIX_FLAGS_ENABLE); // ...省略（msix_enabled=1、读 control、msix_table_size） dev->msix_base = msix_map_region(dev, tsize); // ... /* Disable INTX */ pci_intx_for_msi(dev, 0); // ...省略（Marvell 设备 quirk 注释） msix_mask_all(dev->msix_base, tsize); pci_msix_clear_and_set_ctrl(dev, PCI_MSIX_FLAGS_MASKALL, 0);顺序是防御性的：先置 MASKALL+ENABLE（防止设置期间漏进中断）→ map Table → 分配描述符 → 关 INTx（避免与 MSI-X 并存导致双份中断）→ mask 全部表项 → 解除 MASKALL。全部搞定后驱动才逐个 unmask 自己的向量。⑤ 驱动侧入口：MSI-X 优先的 fallback 链（api.c:254-298） if (flags & PCI_IRQ_MSIX) { nvecs = __pci_enable_msix_range(dev, NULL, min_vecs, max_vecs, affd, flags); if (nvecs > 0) return nvecs; } if (flags & PCI_IRQ_MSI) { nvecs = __pci_enable_msi_range(dev, min_vecs, max_vecs, affd); // ... } /* use legacy IRQ if allowed */ if (flags & PCI_IRQ_LEGACY) { if (min_vecs == 1 && dev->irq) { // ... pci_intx(dev, 1); return 1; } }驱动传 PCI_IRQ_MSIX | PCI_IRQ_MSI | PCI_IRQ_LEGACY（pci.h:1076-1078）时，有多少本事用多少：MSI-X 不够换 MSI，再不行退回共享的 INTx。成功之后用 pci_irq_vector(dev, nr)（api.c:313）把"设备侧向量号"翻译成 Linux IRQ 号传给 request_irq。🐧 内核机制对照：INTx vs MSI vs MSI-X维度INTx（PCI_INTERRUPT_PIN）MSIMSI-X载体物理线 INTA#-INTD#，多设备共享内存写 TLP内存写 TLP向量数1（共享）1/2/4/8/16/32最多 2048（QSIZE+1）每向量独立地址/数据无共享一份每表项一份内核路径传统 irq domainMSI domain（msi.c:270-279）Table ioremap（msi.c:579）亲和性由 APIC 路由每向量可绑核每向量可绑核对 DPDK 的意义：多队列网卡每队列一个 MSI-X 向量，是"每队列独立中断源"的硬件基础；PMD 不想要中断时把 mask 位一置即可。面试 3 问MSI-X Table 在物理内存的哪个位置？ → Capability 链找到 PCI_CAP_ID_MSIX（pci_regs.h:226），读 PCI_MSIX_TABLE dword（pci_regs.h:327）拆出 BIR（pci_regs.h:328）与偏移（pci_regs.h:329），BAR 基址加偏移 ioremap（msi.c:569-579）。为什么改表项前必须 mask？ → PCI 规范原文：unmasked 状态下改 Address/Data 结果 undefined，内核在 msi.c:213-222 引用并遵守。QSIZE 为什么加 1？ → QSIZE 编码的是"表项数 - 1"，msix_table_size 统一加 1（msi/msi.h:6），读表项数走 pci_msix_vec_count（api.c:71-80）。🔧 动手实验lspci -vvv -s 01:00.0 | grep -A5 MSI-X # 记下 "Capabilities: [70] MSI-X" 的能力偏移 sudo lspci -xxxx -s 01:00.0 | grep -A4 '^70:' # 手工解析 Table/BIR dword sudo setpci -s 01:00.0 0x72.L # Message Control: QSIZE / Enable / MaskAll 位对照任务：把 0x72.L 读出的 QSIZE 与 lspci -v 的 "Count=xx" 互验；流量打满时观察 /proc/interrupts 各队列分布是否均匀（RSS 生效则各队列计数接近）。数据落点 perf-data/P4/02-msix.txt。下一篇：P4-03 · 从 0 写一个最小 PCIe 内核驱动

P4-01 · PCIe Configuration Space 与 BAR 解码：写全 1 读回来，才知道设备多大 对应路线图：Phase 4 (Day 120-140) ｜ 内核 v6.6 ｜ 代码出处：source/linux-stable/drivers/pci/，引用均标 文件:行号上一篇：P3-06 host_if ｜ 下一篇：P4-02 MSI-X一句话定位Config Space 是设备与软件之间的"注册表"：软件通过它知道设备是谁（Vendor/Device ID）、有什么能力（Capability 链）、占多大地址（BAR）。而 BAR 解码的玄机在于——BAR 寄存器同时承担"地址寄存器"和"尺寸寄存器"两个身份，内核用"写全 1 读回"让它现出原形。真实源码精读① 64 字节头部：偏移定义在 include/uapi/linux/pci_regs.h:38-125#define PCI_VENDOR_ID 0x00 /* 16 bits */ #define PCI_DEVICE_ID 0x02 /* 16 bits */ #define PCI_COMMAND 0x04 /* 16 bits */ // ...省略（STATUS 0x06、REVISION_ID 0x08、CLASS_DEVICE 0x0a ...） #define PCI_BASE_ADDRESS_0 0x10 /* 32 bits */ // ...省略（BASE_ADDRESS_1..5 依次 0x14/0x18/0x1c/0x20/0x24，pci_regs.h:96-100） #define PCI_CAPABILITY_LIST 0x34 /* Offset of first capability list entry */ #define PCI_INTERRUPT_LINE 0x3c /* 8 bits */ #define PCI_INTERRUPT_PIN 0x3d /* 8 bits */BAR 寄存器的位布局（pci_regs.h:101-110）：bit0 区分空间（1=I/O, 0=Memory）、bit1-2 编码类型（PCI_BASE_ADDRESS_MEM_TYPE_64 = 0x04 表示 64 位 BAR 占两个寄存器）、bit3 是否 prefetchable，其余位才是地址。② 枚举第一步：读 Vendor/Device ID 判断设备是否存在（probe.c:2494-2517）static struct pci_dev *pci_scan_device(struct pci_bus *bus, int devfn) { struct pci_dev *dev; u32 l; if (!pci_bus_read_dev_vendor_id(bus, devfn, &l, 60*1000)) return NULL; dev = pci_alloc_dev(bus); if (!dev) return NULL; dev->devfn = devfn; dev->vendor = l & 0xffff; dev->device = (l >> 16) & 0xffff; if (pci_setup_device(dev)) { // ... return NULL; } // ... }一次 dword 读偏移 0x00 就完成"设备在不在"判断：全 0xffffffff 表示该 devfn 悬空。存在则 pci_setup_device（probe.c:1867）继续读 header type、class 等并解析 BAR。③ BAR 尺寸探测：写全 1 读回（probe.c:176-247，__pci_read_base 节选） mask = type ? PCI_ROM_ADDRESS_MASK : ~0; // ... pci_read_config_dword(dev, pos, &l); pci_write_config_dword(dev, pos, l | mask); pci_read_config_dword(dev, pos, &sz); pci_write_config_dword(dev, pos, l); /* * All bits set in sz means the device isn't working properly. * If the BAR isn't implemented, all bits must be 0. If it's a * memory BAR or a ROM, bit 0 must be clear; if it's an io BAR, bit * 1 must be clear. */ if (PCI_POSSIBLE_ERROR(sz)) sz = 0; // ... if (res->flags & IORESOURCE_MEM_64) { pci_read_config_dword(dev, pos + 4, &l); pci_write_config_dword(dev, pos + 4, ~0); pci_read_config_dword(dev, pos + 4, &sz); pci_write_config_dword(dev, pos + 4, l); // ... }四步协议：读原值 → 写全 1 → 读回 → 还原。读回值中低 N 位被硬件"钉死"为 0，N 就是尺寸的对数——设备应答 0xfff00000 说明它是 1MB 的 BAR。注意写全 1 前内核先关掉 decode（probe.c:189-193），防止探测期间把配置写当成正常访问。64 位 BAR 占两个寄存器，第二个寄存器在 pos + 4 重复一遍（probe.c:239-243）。④ 树形枚举：pci_scan_bus → pci_scan_slot → pci_device_addpci_scan_bus（probe.c:3308）挂上 ioport/iomem/busn 三类资源后创建根总线，调 pci_scan_child_bus 深度扫描。pci_scan_slot（probe.c:2745-2770）按 function 递增探测：fn 0 不存在且不在 hypervisor 透传环境就 break——Fn 0 是一个 slot 的"存在性锚点"。每个设备最终进 pci_device_add（probe.c:2609），挂到 bus->devices 链表（:2642）后由 driver core 触发匹配和 probe。🐧 内核机制对照：同一份 BAR 信息，两种消费方式环节内核（drivers/pci/）DPDK（drivers/bus/pci/）枚举入口pci_scan_bus probe.c:3308用户态读 /sys/bus/pci/devices/存在性判断读 offset 0x00 dword，probe.c:2499sysfs vendor/device 文件BAR 尺寸写全 1 读回，probe.c:198-201直接读 sysfs resource 文件BAR 映射ioremap（内核态地址）mmap，pci_common_uio.c:178-179空 BAR 跳过尺寸 0 则 fail，probe.c:253-254phys_addr == 0 continue，pci_common_uio.c:120-121本质区别：内核替所有驱动把 BAR 解析好、放进 pci_dev.resource[]（pci.h:421）；DPDK 在用户态只能拿到已分配好的物理地址，用 mmap 直接映射设备寄存器——这也是 DPDK 不写内核驱动就能操作网卡的前提。面试 3 问内核怎么测 BAR 尺寸？ → 写全 1 读回（probe.c:198-201），读回值取反加一即尺寸；写之前先关 decode 防误访问（probe.c:189-193）；64 位 BAR 在 pos+4 再做一遍（probe.c:239-243）。BAR 低 4 位为什么不是地址？ → bit0 空间类型（pci_regs.h:101）、bit1-2 类型编码含 64 位标志（pci_regs.h:104-107）、bit3 prefetch（pci_regs.h:108），掩码 PCI_BASE_ADDRESS_MEM_MASK = ~0x0f（pci_regs.h:109）。扫描时如何避免误判"幽灵设备"？ → 悬空 devfn 读回 0xffffffff，pci_scan_device 直接返回 NULL（probe.c:2499-2500）；读回全 1 也用于识别坏设备（probe.c:203-210 注释）。🔧 动手实验用真实 NIC（如 ixgbe 网卡）做一次"手写 __pci_read_base"：lspci -nn -v -s 01:00.0 # 记录 BAR0 地址与尺寸（如 64-bit, 4MB） sudo lspci -xxxx -s 01:00.0 | head # 前 64 字节逐字节对表解码 sudo setpci -s 01:00.0 0x10.L # 读 BAR0 原值 sudo setpci -s 01:00.0 0x10.L=0xffffffff sudo setpci -s 01:00.0 0x10.L # 读回：低 N 位为 0，验证尺寸 sudo setpci -s 01:00.0 0x10.L=<原值> # 必须还原！不还原设备可能失效同时 insmod code/dpu_dev/01_pci/pci_scan.ko 看内核侧 pci_resource_start(pdev, 0) 给出的 BAR0 值是否与 lspci 一致。数据落点 perf-data/P4/01-config-space.txt（lspci 原文 + 手工解码过程 + setpci 三次读数）。下一篇：P4-02 · MSI-X 中断机制：Table 在哪、怎么触发

P3-06 · host_if 打通：让 FRR/BGP 跑在纯软件转发上 对应路线图：Phase 3 (Day 92-119) ｜ DPDK 24.11.6 LTS ｜ 内核对照 v6.6上一篇：P3-05 sai-dpdk-mini ｜ 下一篇：P4-01 PCIe一句话定位交换机光会转发没用，BGP/OSPF 这些协议要能收发包。SAI 为此定义了一整套 hostif（host interface）抽象：控制面报文（BGP 的 TCP 179、ARP、ICMP）从数据面 trap 上 CPU，控制面要发的包经 hostif 送回数据面——这就是把 FRR 接进纯软件转发的最后一公里。hostif 三件套：类型、创建、收发① 三种通道类型（saihostif.h:848-859）typedef enum _sai_hostif_type_t { /** Netdevice */ SAI_HOSTIF_TYPE_NETDEV, /** File descriptor */ SAI_HOSTIF_TYPE_FD, /** Generic netlink */ SAI_HOSTIF_TYPE_GENETLINK } sai_hostif_type_t;三种类型的语义差异：NETDEV 让 SAI 实现去创建一个 Linux 网卡（hostif 就是"内核能看到的那张卡"）；FD 用文件描述符收发包（最高效，syncd 直接读 socket）；GENETLINK 走 generic netlink family。创建时的 SAI_HOSTIF_ATTR_TYPE 是 MANDATORY_ON_CREATE（saihostif.h:906-908）： /** * @brief Host interface type * * @type sai_hostif_type_t * @flags MANDATORY_ON_CREATE | CREATE_ONLY */ SAI_HOSTIF_ATTR_TYPE = SAI_HOSTIF_ATTR_START,② 创建与收发（saihostif.h:1003-1007、1442-1447、1385-1390）typedef sai_status_t (*sai_create_hostif_fn)( _Out_ sai_object_id_t *hostif_id, _In_ sai_object_id_t switch_id, _In_ uint32_t attr_count, _In_ const sai_attribute_t *attr_list); typedef void (*sai_packet_event_notification_fn)( _In_ sai_object_id_t switch_id, _In_ sai_size_t buffer_size, _In_ const void *buffer, _In_ uint32_t attr_count, _In_ const sai_attribute_t *attr_list);（sai_send_hostif_packet_fn 与回调同构，只是返回值是 sai_status_t。）收包靠回调（packet_event 挂在 switch 属性上，saiswitch.h:1970-1972 注释），发包靠 send_hostif_packet_fn，全套在 sai_hostif_api_t（saihostif.h:1452 起）。端到端：一个 BGP 报文的旅程进（BGP 邻居 → FRR）：数据面收到 TCP 179 报文 → 查表 miss（不是转发流量）→ 命中 trap 规则 → 沿 packet_event 回调进 syncd → syncd 经 NETDEV 写进 Linux 内核协议栈 → FRR 的 zebra/bgpd socket 收到。出（FRR → BGP 邻居）：bgpd 发 TCP 179 报文 → 内核路由表把流量指向 hostif 网卡 → SAI 实现的 ndo_start_xmit（NETDEV 型）或 syncd 读 FD → 调 send_hostif_packet_fn → 数据面封装后从物理口发出。对比：内核 tun 的同一位置（drivers/net/tun.c:1251-1262）：static const struct net_device_ops tun_netdev_ops = { .ndo_init = tun_net_init, .ndo_uninit = tun_net_uninit, .ndo_open = tun_net_open, .ndo_stop = tun_net_close, .ndo_start_xmit = tun_net_xmit, // ... };NETDEV 型 hostif 本质就是一个"SAI 实现的 tun"：内核侧是标准网卡，驱动侧不是 DMA 而是 send_hostif_packet_fn。这是理解 hostif 最快的类比。设计取舍：NETDEV vs FD vs GENETLINK NETDEVFDGENETLINK内核集成原生（就是网卡）无，syncd 自己读需要 family 注册性能中（内核协议栈必经）高（绕过内核）低（netlink 序列化）实现复杂度低（tun 参考现成）中高适用快速打通 FRR生产数据面工具类通道学习路线选 NETDEV：sai-dpdk-mini 阶段第一目标是把 FRR 跑起来，NETDEV 让 BGP 报文"看起来像普通网卡流量"，内核协议栈、FRR 全都不动。等 perf 数据显示 hostif 成为瓶颈，再切 FD 型绕内核。🐧 内核对照：tun 的收包路径tun_get_user（drivers/net/tun.c:1750）是字符设备读写的核心——应用写 /dev/net/tun 就进这里（节选）：static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile, void *msg_control, struct iov_iter *from, int noblock, bool more) { struct tun_pi pi = { 0, cpu_to_be16(ETH_P_IP) }; struct sk_buff *skb; // ... if (!(tun->flags & IFF_NO_PI)) { if (len < sizeof(pi)) return -EINVAL; len -= sizeof(pi); if (!copy_from_iter_full(&pi, sizeof(pi), from)) return -EFAULT; } // ...（IFF_TAP 时校验 ETH_HLEN 等，省略）...环节tun 驱动SAI hostif (NETDEV)内核侧对象/dev/net/tun 字符设备标准 net_device发包进"网卡"写 char dev → tun_get_userndo_start_xmit → send_hostif_packet_fn收包出"网卡"tun_net_xmit → skb 进协议栈packet_event 回调 → 内核协议栈数据面另一端用户态进程读 fdSAI 数据面（硬件或 DPDK）方向正好相反：tun 的"网线那头"是用户态进程，hostif 的"网线那头"是交换机数据面。同一份 net_device_ops 机制，两端换了个位置。面试 3 问三种 hostif 类型的区别？ → NETDEV 创建 Linux 网卡、FD 用文件描述符、GENETLINK 走 generic netlink（saihostif.h:848-859）；学习期选 NETDEV 最快打通 FRR。BGP 报文怎么从数据面到 FRR？ → trap 命中 → packet_event 回调（saihostif.h:1442）→ syncd 经 NETDEV 入内核协议栈 → bgpd socket。hostif 和 tun 是什么关系？ → NETDEV 型 hostif 就是"SAI 实现的 tun"：内核侧同一套 net_device_ops（tun.c:1251-1262 对照），驱动侧从"读写 fd"换成 SAI 收发函数。🔧 动手实验ip tuntap add dev bgp0 mode tap 建一个真 tun，跑 FRR 邻居建连，抓包看 TCP 179 的路径（先在内核侧建立直觉）；在 sai-dpdk-mini 里实现 create_hostif + send_hostif_packet 的 NETDEV 桩，ip link 能看到这张"SAI 网卡"；FRR zebra 把 10.0.0.0/24 路由注入，观察路由经 APPL_DB → ASIC_DB 最终变成 rte_lpm_add（衔接 P3-03/05）；端到端验证：BGP 邻居建连 + 数据面转发 + ping 通。产出 perf-data/P3/06-hostif-frr.md（邻居建连日志 + route 注入链路截图 + 转发吞吐）。下一篇：P4-01 · PCIe Configuration Space 与 BAR 解码（Phase 4 学到时发布）

P3-05 · sai-dpdk-mini：用 DPDK 实现 SAI 最小适配器 对应路线图：Phase 3 (Day 92-119) ｜ DPDK 24.11.6 LTS ｜ 内核对照 v6.6代码出处：code/sai-dpdk-mini/（当前实际内容）与 source/dpdk-stable-24.11.6/lib/，引用均标 文件:行号上一篇：P3-04 SAI 头文件全景 ｜ 下一篇：P3-06 host_if 打通一句话定位sai-dpdk-mini 回答一个问题：不买 ASIC，纯 DPDK 软件能不能当 SAI 的一个"厂商实现"？ 能——把 SAI 的 L2/L3/ACL 语义逐条映射到 rte_hash/rte_lpm/rte_flow 上，SONiC 全家桶就能跑在 x86 软件交换机上。如实交代现状：截至写这篇博客，code/sai-dpdk-mini/ 里只有一份 CMake 骨架和空目录——所以这篇是"接口映射设计 + 骨架精读"，每个映射目标都给出 DPDK 侧真实行号，实现代码随学习进度补。现状：骨架的真实内容code/sai-dpdk-mini/CMakeLists.txt（全文，当前唯一文件）：cmake_minimum_required(VERSION 3.16) project(sai-dpdk-mini C) set(CMAKE_C_STANDARD 11) add_library(sai-dpdk SHARED src/sai_switch.c src/sai_port.c src/sai_fdb.c src/sai_route.c src/sai_neighbor.c) target_include_directories(sai-dpdk PRIVATE include ${CMAKE_SOURCE_DIR}/../../references/sai-headers/inc)这份骨架已经锁定了三个关键决策：产物是共享库 libsai-dpdk.so——它扮演厂商 SDK 的角色，syncd 加载它就像加载 libsai-brcm；模块划分 = SAI 模块划分：switch/port/fdb/route/neighbor 五个 .c，每个导出一张 SAI API 表（对应 P3-04 的 sai_switch_api_t 等）；直接 include 真实 SAI 头文件（references/sai-headers/inc）——API 签名零翻译、零自造，sai_api_query 换表流程原样可用（sai.h:252）。src/、include/、test/ 目录已建但为空——按学习节奏逐模块填充，这是刻意的：先定接口契约，再写实现。映射设计：SAI 语义 → DPDK 原语① L2 FDB → rte_hash（哈希表）SAI 的 sai_fdb_entry_t（MAC+VLAN+port，saifdb.h:357 的 key 参数）天然是哈希 key。DPDK 侧的真实接口（lib/hash/rte_hash.h）：// rte_hash.h:146 struct rte_hash * rte_hash_create(const struct rte_hash_parameters *params); // rte_hash.h:246 int rte_hash_add_key_data(const struct rte_hash *h, const void *key, void *data); // rte_hash.h:454 int rte_hash_lookup_data(const struct rte_hash *h, const void *key, void **data);设计要点：key 用 12 字节结构 {mac[6], vlan_id[2], port_id[4]} 对齐填零；data 存出端口号；rte_hash_add_key_data 把"查表→拿值"合成一步。学习型 FDB 的洪泛逻辑（查不到就广播）在 SAI 层用 create_fdb_entry 的删除回调 + 超时实现，与内核 br_fdb_update 的职责对照（内核版见 net/bridge/br_fdb.c:863）。② L3 路由 → rte_lpm（DIR-24-8 最长前缀匹配）SAI 的 sai_route_entry_t（sairoute.h:180 的 destination 前缀）对应 DPDK 的真实 LPM 接口（lib/lpm/rte_lpm.h）：// rte_lpm.h:162-164 struct rte_lpm * rte_lpm_create(const char *name, int socket_id, const struct rte_lpm_config *config); // rte_lpm.h:221 int rte_lpm_add(struct rte_lpm *lpm, uint32_t ip, uint8_t depth, uint32_t next_hop); // rte_lpm.h:279 static inline int rte_lpm_lookup(const struct rte_lpm *lpm, uint32_t ip, uint32_t *next_hop)next_hop 参数直接挂 sai_next_hop_t 的 OID 低 32 位（P3-04：OID 是 64 位句柄，高位编码类型）。DIR-24-8 算法本身就是"软件交换机的最佳路由表实现"——这也是 P3-01 里 OVS dpcls 和内核 fib_trie 之外的第三条路线（内核对照：net/ipv4/fib_trie.c:1425 的 fib_table_lookup 用 level-compressed trie）。③ ARP 邻接 → rte_hashsai_neighbor_entry_t（IP+rif，saineighbor.h:206）同样进哈希，key 是 {ip[4], rif_oid[8]}，data 是 {mac[6], 出口}。它和 FDB 共用同一份 rte_hash 初始化代码——两个 SAI 模块映射到同一个 DPDK 原语，这就是适配层的乐趣。④ ACL → rte_flowSAI 的 create_acl_table（saiacl.h:3713）+ entry 匹配动作，翻译成 DPDK 的 flow 规则（lib/ethdev/rte_flow.h）：// rte_flow.h:89 struct rte_flow_attr { uint32_t group; uint32_t priority; /**< Rule priority level within group. */ uint32_t ingress:1; uint32_t egress:1; // ... }; // rte_flow.h:4695 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);映射规则：SAI ACL table → rte_flow_attr.group；SAI 规则优先级 → priority；匹配字段翻译成 pattern（ETH/IPV4/5-tuple）；动作翻译成 actions（DROP/COUNT/redirect）。如果 NIC 不支持 offload，DPDK 会退软件 fallback——sai-dpdk-mini 的 ACL 一开始就走软件路径，等价于一张每核免锁的精确匹配表（P3-01 的 EMC 思路复用）。⑤ port/switch → ethdevcreate_port（saiport.h:4296）→ rte_eth_dev_info_get/rte_eth_dev_configure；set_port_attribute（saiport.h:4320）的 admin state → rte_eth_dev_start/stop。switch 属性（saiswitch.h:4263 表）落在全局配置结构里。🐧 内核对照：这三张表在内核长什么样SAI 语义DPDK 原语内核对应FDB entryrte_hash_add_key_data（rte_hash.h:246）br_fdb_update（net/bridge/br_fdb.c:863）route entryrte_lpm_add（rte_lpm.h:221）fib_table_insert（net/ipv4/fib_trie.c:1199）neighborrte_hash_add_key_dataneigh_update（ARP 表）ACLrte_flow_create（rte_flow.h:4695）tc cls flower + net/sched/hostif 发包sai_send_hostif_packet_fn（saihostif.h:1385）tun_net_xmit（drivers/net/tun.c:1256）注意 DPDK 和内核的查表数据结构选择完全一致：哈希表做精确匹配（FDB/邻居），trie/LPM 做前缀匹配（路由）。区别在于 DPDK 的表是用户态预分配、每核可私有、批量查询（rte_lpm_lookup_bulk）；内核表要扛 RCU 和路由事件通知。sai-dpdk-mini 就是把这个对照写成代码。面试 3 问sai-dpdk-mini 的产物为什么是共享库？ → 它扮演厂商 SDK：syncd 通过 sai_api_query 换表（sai.h:252），CMake 骨架 add_library(sai-dpdk SHARED ...) 已定；模块按 SAI 模块切 .c 文件（CMakeLists 的 5 个源文件）。FDB 和 neighbor 为什么都用 rte_hash 而不是各自的表？ → 两者都是精确匹配语义，key 结构不同（{MAC,VLAN,port} vs {IP,rif}）但原语相同；SAI 层两个模块、DPDK 层一个原语。SAI ACL 怎么映射 rte_flow？ → table → rte_flow_attr.group，优先级 → priority（rte_flow.h:89-101），匹配字段 → pattern，动作 → actions，rte_flow_create（rte_flow.h:4695）下发；软件 fallback 时等价 per-core 精确匹配表。🔧 动手实验cmake -B build 验证骨架可配置（src 为空时先补桩函数）；实现 sai_fdb.c 的第一版：create_fdb_entry 用 rte_hash_add_key_data，写 gdb 断点验证 key 布局（P0-06 的 gdb 功夫）；实现 sai_route.c 用 rte_lpm_add，和 fib_trie.c:1199 的插入路径对照读；跑通 sai_api_query 换表 → create_switch(INIT_SWITCH=false) 的最小 demo。产出 perf-data/P3/05-sai-dpdk-mini.md（三张表插入/查询的单核 OPS 曲线）。下一篇：P3-06 · host_if 打通：让 FRR/BGP 跑在纯软件转发上

P3-04 · SAI 头文件全景：15 个 MVP API 矩阵 对应路线图：Phase 3 (Day 92-119) ｜ DPDK 24.11.6 LTS ｜ 内核对照 v6.6代码出处：references/sai-headers/inc/（真实 SAI 头文件），引用均标 文件:行号上一篇：P3-03 SONiC 控制面链路 ｜ 下一篇：P3-05 sai-dpdk-mini一句话定位SAI（Switch Abstraction Interface）是一套纯 C 函数指针 API 集合：所有对象共用一个 sai_object_id_t 句柄，所有属性共用一个 sai_attribute_t 结构，所有能力通过 sai_api_query 按模块换函数表。看完头文件你会发现：它比内核的 net_device_ops 还要"接口化"——连对象都不是结构体，而是 ID。三个地基类型① OID：64 位不透明句柄（saitypes.h:131）typedef uint64_t sai_object_id_t;端口、VLAN、路由表项、交换机本身……万物皆 64 位。对象类型枚举（saitypes.h:188-227 节选）：typedef enum _sai_object_type_t { SAI_OBJECT_TYPE_NULL = 0, /**< invalid object type */ // ... SAI_OBJECT_TYPE_ROUTE_ENTRY = 37, // ...OID 的高位编码对象类型、低位编码索引，所以 sai_object_type_query() 能从一个 OID 反查类型（sai.h:286）。对比内核：内核每种对象是一个 struct（net_device/fib_info），SAI 统一成一个整数——因为厂商 SDK 在进程边界之外，句柄比指针跨得了界。② attribute：id + union（saitypes.h:1815-1822）typedef struct _sai_attribute_t { /** @passparam meta */ sai_attr_id_t id; /** @passparam meta */ sai_attribute_value_t value; } sai_attribute_t;value 是个大 union（bool/u8/u16/u32/u64/oid/指针全塞里面）。所有 API 的参数都是 attr_count + attr_list——新增属性不破坏二进制接口，这是 SAI 能兼容十多家 ASIC 厂商的协议基础。③ API 表：每个模块一张函数指针表sai_switch_api_t（saiswitch.h:4261-4279）节选：typedef struct _sai_switch_api_t { sai_create_switch_fn create_switch; sai_remove_switch_fn remove_switch; sai_set_switch_attribute_fn set_switch_attribute; sai_get_switch_attribute_fn get_switch_attribute; sai_get_switch_stats_fn get_switch_stats; // ... } sai_switch_api_t;应用启动时 sai_api_query(SAI_API_SWITCH, ...) 换出这张表，剩下全是函数指针间接调用。没有虚函数、没有对象模型、没有 ABI 版本地狱——C ABI 是跨厂商 SDK 的唯一公约数。15 个 MVP API 矩阵#API签名位置作用1sai_create_switch_fnsaiswitch.h:4113创建/连接交换机2sai_create_port_fnsaiport.h:4296创建端口3sai_set_port_attribute_fnsaiport.h:4320端口 admin up/down4sai_create_vlan_fnsaivlan.h:563创建 VLAN5sai_create_fdb_entry_fnsaifdb.h:357静态 MAC 表项6sai_create_route_entry_fnsairoute.h:195L3 路由7sai_create_neighbor_entry_fnsaineighbor.h:219ARP 邻接8sai_create_next_hop_fnsainexthop.h:297下一跳对象9sai_create_acl_table_fnsaiacl.h:3713ACL 表10sai_create_hostif_fnsaihostif.h:1003上送 CPU 的 host 接口11sai_send_hostif_packet_fnsaihostif.h:1385从 CPU 发包12sai_packet_event_notification_fnsaihostif.h:1442收包回调（RX trap）13set_switch_attribute（switch 级属性）saiswitch.h:4265switch 级属性14sai_api_query 换表 + sai_remove_* 删除族sai.h:252 ／ 同名文件相邻行全生命周期读两个有代表性的完整定义：saifdb.h:357-360：typedef sai_status_t (*sai_create_fdb_entry_fn)( _In_ const sai_fdb_entry_t *fdb_entry, _In_ uint32_t attr_count, _In_ const sai_attribute_t *attr_list);saihostif.h:1385-1390：typedef sai_status_t (*sai_send_hostif_packet_fn)( _In_ sai_object_id_t hostif_id, _In_ sai_size_t buffer_size, _In_ const void *buffer, _In_ uint32_t attr_count, _In_ const sai_attribute_t *attr_list);套路完全一致：entry 结构描述 key（sai_fdb_entry_t 是 MAC+VLAN+port，sai_route_entry_t 是 prefix，saineighbor.h:206 的 neighbor 是 IP+rif），属性列表描述 value。把 key 和 value 分开是 SAI 和内核 API 最大的风格差异。🐧 内核对照：net_device_ops 的"每对象一张表"内核把操作挂在对象自身上（include/linux/netdevice.h:1410 起），tun 驱动实例（drivers/net/tun.c:1251-1262）：static const struct net_device_ops tun_netdev_ops = { .ndo_init = tun_net_init, .ndo_uninit = tun_net_uninit, .ndo_open = tun_net_open, .ndo_stop = tun_net_close, .ndo_start_xmit = tun_net_xmit, // ... };维度内核 net_deviceSAI对象表示struct net_device（结构体+指针）sai_object_id_t（64 位句柄）操作接口net_device_ops 挂在对象里每模块一张全局 API 表属性访问内核态直接读写字段set/get_attribute（id+union）表项对象fib_info/neighbour 结构体entry 结构体（key 值分离）跨进程不可（内核态）可（序列化成 Redis/grpc）热插拔实现指针直接替换换 API 表指针SAI 是为"控制面和数据面分属不同进程/不同厂商"设计的——它的每个设计决策（句柄、属性 union、函数指针表）都在为进程边界和二进制兼容让路。这正好解释 P3-03 里 orchagent 和 syncd 为什么能隔着 Redis 工作。面试 3 问SAI 为什么不把属性做成结构体字段？ → sai_attribute_t = id + union（saitypes.h:1815-1822），增删属性不改 ABI；对比内核直接访问 net_device 字段，SAI 必须保证跨厂商 SDK 的二进制兼容。sai_fdb_entry_t 和 attribute 怎么分工？ → entry 描述 key（MAC/VLAN/port，saifdb.h:357 参数），attr_list 描述 value（如端口绑定）——和内核把 key、value 都塞进一个结构体的习惯不同。为什么 OID 用 64 位整数而不是指针？ → 对象在厂商 SDK 进程里，跨进程只能传句柄（saitypes.h:131）；类型编码进 OID 高位，sai_object_type_query 反查（sai.h:286）。🔧 动手实验把 references/sai-headers/inc/ 下 10 个头文件的 typedef sai_status_t (*sai_create_* 全部 grep 出来，做一张"对象 × 模块"对照表。写一个只含 sai_api_query 换表 + create_switch（INIT_SWITCH=false）的最小程序链接 sairedis。产出 perf-data/P3/04-sai-api-matrix.md。下一篇：P3-05 · sai-dpdk-mini：用 DPDK 实现 SAI 最小适配器