对应路线图：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 三层各干什么
| 层 | 载体 | 职责 | 判据 |
|---|---|---|---|
| HW | ASIC（TCAM/LPM/counter/meter） | 线速匹配与改写 | 确定性高、容量足、高频 |
| FW | Firmware | 流表编排、DMA 引擎、计数器/老化上报 | HW 与 SW 之间的机械桥梁 |
| SW | ARM 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 问"是种子题。
评论 (0)