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 题