去年有一段时间我被拉去参加一个内部技术评审会议室里坐着三拨人做虚拟化平台的、做分布式存储的、做安全网关的。议题只有一个——要不要在下一代的节点规格里引入 SmartNIC也就是这几年被反复提起的 DPU。需求写得很漂亮把主机上那些又重又乱的基础设施功能挪到卡上去释放主机算力。讨论到第四十分钟有人问了一句那具体卸什么会议室安静了三秒然后三拨人给出了三个完全不同的答案。这个场景我后来反复遇到。SmartNIC 和 DPU 这两个词在过去几年被用得越来越泛宣传材料里它们几乎无所不能虚拟交换、overlay 封装、存储前端、加解密、遥测采集、容器网络最好还能顺手跑点业务逻辑。但真正决定一个项目成不成往往不是卡本身有多少个核、多少 G 带宽而是你到底把什么东西搬了上去、搬上去之后还有没有能力把它看住、出问题的时候能不能退回来。这篇东西不讲产品对比也不做选型推荐只讲技术方向上的判断逻辑。适合三类人看正在评估要不要引入这类硬件的架构同学已经买了卡但卸载率上不去的运维同学以及被卸载这个词忽悠过一次、想搞清楚边界在哪的开发同学。下面所有的经验和数字都来自公开可查的通用架构常识和常见工程实践涉及具体环节的地方我会说明这是基于常见做法的合理推演。1. 先把智能网卡和DPU这两个词的边界划清楚1.1 从网卡加功能到独立计算域的三级跳很多人以为智能网卡和 DPU 是同义词只是叫法不同。实际工程里这两个词指向的能力差距非常大混着用会直接导致需求写错、验收标准定错。第一级是大家最熟悉的普通网卡做物理层和链路层配合驱动完成收发卸载一些无状态的杂活比如校验和计算、分段与合并、中断聚合。这些东西的共同点是不需要跨包记忆状态每个包来了独立处理硬件实现起来便宜、稳定、不会出错。这一级的价值很实在但它不改变主机的软件架构。第二级是带可编程能力的智能网卡在网卡上加入一块可编程的包处理流水线或者干脆塞几个通用核。这时候它开始能承接有状态的工作比如虚拟交换转发、隧道封装解封装、访问控制列表匹配、连接跟踪。关键在于可编程三个字——同样的硬件换个程序就能干不同的活不用等下一代芯片。这一级的分水岭是主机上少了一个 CPU 密集的转发进程多了一个需要独立管理的固件与程序生命周期。第三级才是 DPU 想表达的东西卡上有独立的通用计算域、独立的内存、独立的操作系统、独立的管理面通过 PCIe 挂到主机上但对主机来说它更像一台插在总线上的小服务器。它不只处理网络包还能跑存储前端、跑安全策略、跑遥测聚合、跑轻量编排代理。这一级的本质变化是运维边界的扩张你多了一批需要打补丁、需要监控、需要做容量规划的节点只不过它们没有机箱。我在实际项目里见过最典型的翻车是把第二级的需求按第三级的预算买了卡结果发现需要的容器网络策略引擎根本跑不上去也见过反过来为了跑一个简单的隧道封装上了第三级的硬件最后多出来的管理复杂度把运维拖垮。判断标准其实很简单你要卸载的东西里有多少是包级别的、流水线友好的有多少是需要通用编程环境、需要访问文件系统、需要跑完整协议栈的。前者二级就够后者才需要三级。1.2 命名混乱带来的三个选型误区第一个误区是把卸载能力等同于性能提升。卸载的真正价值在三个地方释放主机核、缩短数据路径、把功能做成多租户可编排的基础设施。如果你的瓶颈本来就在别处比如应用层锁竞争或者磁盘 IO那卡再强也没用。我见过一个团队把转发面卸载之后主机 CPU 确实降了 30%但整体吞吐只涨了 6%因为瓶颈搬到了 PCIe 和卡上的内存带宽上。第二个误区是忽略谁来写那个程序。可编程不等于零成本P4 也好、eBPF 也好、厂商 SDK 也好都需要有人能读懂包处理逻辑、能调试流水线、能做性能剖析。这个技能栈在多数团队里是稀缺的而它又不像普通后端开发那样能在短期内补上——很多问题只有真机才能复现。第三个误区是拿实验室的单流数据做决策。几乎所有厂商给的性能曲线都是单流、大包、理想配置下的结果而生产环境是几万条短连接、混合包长、大量小包和重传。这两者的差距有时能到三四倍后面第 5 章会专门讲这个。2. 一块卡内部到底装了什么分层拆解2.1 控制面、数据面、加速面的三域划分不管哪家的方案卡内部的逻辑基本都能切成三块理解这三块的分工比记住参数表重要得多。数据面是包处理的主干负责从物理口收包、解析、匹配、执行动作、转发出去。它的设计目标是确定性给定输入延迟和吞吐要可预测最好能做到线速无阻塞。数据面里通常还会挂一批硬件加速器做加解密、做正则匹配、做压缩、做校验这些单元的存在意义是用固定电路替代通用核的循环。控制面负责配置下发、表项维护、状态同步。比如虚拟交换的转发表、访问控制的规则集、隧道的端点和密钥都是控制面在管。控制面用通用核实现更合适因为它的负载特点是低频、复杂、需要协议栈。很多项目的性能问题其实出在控制面表项更新太慢、规则变更要重建整条流水线、控制面和主机侧控制器的心跳超时。加速面我更愿意叫它服务面是第三级 DPU 才真正具备的部分存储协议前端、安全协议卸载、遥测数据聚合、甚至跑一些贴近网络的业务逻辑。这块的负载特征和主机上的普通进程没本质区别只是位置更靠近网络。三域之间靠内部总线和内存连通。这里有个容易忽视的事实三域共享同一块板载内存和同一条到主机的 PCIe 通路任何一域的突发流量都会挤占另外两域。设计的时候必须给数据面留出硬性的带宽和缓存配额否则一个跑在卡上的日志代理就能把转发延迟拉高。2.2 包处理引擎的三条技术路线这是技术方向上分歧最大的地方也是选型时最该盯住的一点。路线典型实现思路优势代价适用场景固定流水线硬件固化各级处理只开放有限配置性能最确定、功耗最低、成本最低无法新增协议功能受制于芯片版本纯转发、纯加解密等成熟功能可编程流水线领域专用语言描述解析与匹配动作编译到硬件线速下有灵活性延迟确定编程门槛高表项容量与逻辑复杂度互相挤占隧道封装、可编程 ACL、多租户网络通用多核一组通用核跑用户态转发程序生态成熟调试方便什么都能干小包性能差功耗高延迟抖动大需要复杂状态机、协议栈的卸载我自己的经验是小包性能是区分这三条路线的照妖镜。算一笔账就清楚了。以 100Gbps 线速、64 字节小包为例加上前导码和帧间隙实际每个包在线路上占 84 字节包速率大约是 100e9 ÷ (84×8) ≈ 148.8 Mpps。假设卡上的通用核主频 2.5GHz8 个核满打满算 20G 周期每秒平均每个包只能分到 20e9 ÷ 148.8e6 ≈ 134 个周期。这 134 个周期里要完成收包描述符、解析、查表、执行动作、重新入队任何一次内存访问的缓存未命中就可能吃掉几十个周期。所以纯通用核方案在 100G 小包场景下基本不可能做到线速跑到三分之一就已经是很优秀的实现了。可编程流水线方案把大部分工作放在硬件里并行做每个包的处理是流水化的吞吐靠增加并行度而不是靠提高主频这就是它能在小包上顶住的根本原因。代价是逻辑复杂度受限于流水线的级数和每级的表项容量写程序的时候要时刻想着这条规则会不会把某一级撑爆。有个反直觉的点可编程流水线的容量约束常常比性能约束更早成为瓶颈。实际项目里撞到表项放不下了的概率远高于包转发跑不到线速。2.3 内存带宽与 PCIe 通路才是真正的天花板很多人评估一块卡的时候盯着核数和端口速率但真正决定上限的往往是两个更底层的东西。先看 PCIe。以 100Gbps 网络为例单向数据量是 12.5GB/s。但卸载场景下的实际流量通常不止一份包从物理口进来可能要先经 PCIe 送到主机侧的应用主机返回结果再经 PCIe 送回卡上发出一来一回就是两倍多。再加上 DMA 描述符、头部开销、TLP 包头实际占用可能是线速数据量的 2 到 2.5 倍也就是 2531GB/s。PCIe Gen4 x16 的单向理论带宽约 32GB/s实际有效带宽打个八九折也就是 2628GB/s——刚好卡在临界点上。这就是为什么很多第一代方案在 100G 双口满载的时候会出现偶发丢包换到 Gen5 x16单向约 64GB/s就宽裕了。再看板载内存。一颗 DDR4-3200 单通道的理论带宽是 25.6GB/s双通道 51.2GB/s。如果转发路径上每个包要做三到四次内存访问读描述符、读包体、查表、写队列100G 小包下内存带宽很容易被打满。这也是为什么很多高端的卡在包处理路径上尽量不碰 DDR而是用片上 SRAM 或者紧耦合的缓存来承载热表项和包缓冲DDR 只用来放冷数据和跑通用核上的服务。实操建议评估任何一块卡先让对方给出满载小包 全功能开启场景下的 PCIe 利用率和内存带宽占用。这两个数字如果接近 70%你就该考虑下一代接口或者削减卸载范围了。3. 卸载策略哪些活该搬上去哪些搬上去是灾难3.1 用每包成本和状态位置两把尺子做判断我判断一个功能该不该卸载习惯用两个维度打分比拍脑袋靠谱得多。每包成本这个功能在主机上每处理一个包要烧多少 CPU。计算方法很朴素——抓一段真实流量用性能剖析工具看这个功能占了多少周期除以包数。成本高的优先卸载因为它带来的收益最直接。典型的低成本项是打标记计数这种卸载了也省不了多少。典型的高成本项是加解密、正则匹配、多层隧道封装、连接跟踪。状态位置这个功能的关键状态存在哪里卸载之后状态怎么同步。这一维度决定成败。如果状态是每连接一份、由主机侧应用独占卸载就很麻烦因为卡上要维护一份镜像两边不一致的时候谁说了算如果状态天然可以下沉比如转发表、邻居表、策略规则那卸载就顺畅。两把尺子交叉一下会得到一个很实用的四象限每包成本高且状态可下沉的优先卸载每包成本高但状态强绑主机应用的谨慎评估通常只做部分加速而不做整体迁移每包成本低但状态可下沉的属于顺手做掉能减少主机上的常驻进程两头都不占的别碰。3.2 虚拟交换的卸载收益边界虚拟交换卸载是最常见的入口场景也是最容易被过度承诺的地方。它把主机内核或用户态的转发进程整体搬到卡上好处很明确主机不再需要为每个包做一次上下文切换和内存拷贝转发路径从应用 → 内核协议栈 → 虚拟交换 → 驱动 → 网卡缩短到应用 → 虚拟功能 → 卡。收益边界在哪里我的观察是三点。第一连接密度比吞吐更影响收益。当单机上跑着几千个容器、每个容器几十条连接的时候主机侧转发的开销主要来自表项查找和连接跟踪这些正好是可编程流水线擅长的收益会非常明显。而如果只是几条大流量长连接主机侧的转发开销本来就不高卸载带来的提升有限反倒增加了排障难度。第二规则变更频率决定控制面压力。容器环境里服务在不停地扩缩容转发表项每分钟可能变化上百次。如果控制面下发一条规则要几十毫秒累积起来就会造成短暂的转发黑洞。这一点在压测里基本看不出来只有在真实编排环境里才会暴露。第三overlay 的封装层级要和硬件能力对齐。两层隧道比如外层再套一层在软件里实现很自然在硬件流水线里就是级数和表项容量的额外开销。有些方案第一层隧道能线速两层就要降速这个必须提前压测。3.3 存储与安全卸载看起来最美坑最深存储前端卸载把远端块设备的协议处理放到卡上是 DPU 最吸引人的场景之一因为它能同时释放主机 CPU 和降低 IO 延迟。但这里的坑非常实际。坑一在故障语义。主机上的存储客户端出问题你看主机日志就行。卸载到卡上之后链路抖动、卡上固件重启、板载内存耗尽这些故障的呈现方式完全不同而且很可能表现为主机侧看到 IO 超时这种极其模糊的症状。做这个场景之前必须先把卡侧的错误码、日志、遥测通道打通否则排障会变成玄学。坑二在一致性。卡上的缓存放了一份元数据主机侧的文件系统也有一份两边靠什么保证不打架常见做法是把卡上的缓存做成只读或者直写语义牺牲一部分性能换正确性但这个取舍必须在设计阶段就定下来不能等上线再改。安全卸载协议加解密、访问控制的坑在密钥与策略的归属。密钥放在卡上还是主机上如果放卡上怎么保证它不被主机侧读取如果放主机上每次会话建立都要和卡通信那卸载的收益还剩多少访问控制也一样规则由谁编排、由谁审计、卡上的规则命中记录怎么回传给主机的审计系统——这些问题在方案文档里经常被一句由管理面统一配置带过实际上是最花时间的地方。3.4 卸载失败之后必须有回退路径这条是我认为最重要的工程原则。任何卸载都必须设计成可以关掉而且关掉之后系统能正常跑只是性能下降。具体做法在配置层面保留一份纯软件实现作为备份路径在启动流程里做一次自检卡不可用或者固件版本不匹配的时候自动降级在监控里把卸载是否生效作为一个显式指标暴露出来而不是靠人去看板卡日志。我见过一个集群因为一次固件升级不兼容所有节点的卸载全部静默失效主机 CPU 被打满但没有任何告警——因为所有人都以为卸载是装好就一直生效的。灰度顺序建议先把非关键业务放到卡上跑两周观察错误率和延迟分位数再逐步扩到一个可用区最后才考虑全量。千万别在网络控制面这种一出问题就全挂的路径上做首发。4. 编程模型的四条路线与各自适用面4.1 领域专用流水线能力最强门槛最高用领域专用语言描述解析 → 匹配 → 动作的流程然后编译到底层硬件这是可编程网络芯片的主流做法。它的好处是抽象层次正好落在包处理这个粒度上程序员不用操心线程调度和内存管理只需要想清楚协议结构和匹配逻辑。难点在于思维方式的转换。写普通程序你可以随时申请内存、随时循环、随时调用库函数写流水线程序你必须先想清楚包头的固定布局所有匹配只能在有限的表项空间里做循环不被允许状态只能通过有限的寄存器或计数器来维护。这种约束对做了多年应用开发的人是一种折磨但一旦适应写出来的东西性能非常可预测。我建议的上手路径是先在软件模拟环境里把逻辑跑通用真实抓包做回归确认每条规则的命中行为符合预期再上真机。直接上真机调试的代价太大一次编译动辄几分钟而且错误信息往往只告诉你某一级资源不足不告诉你是哪条规则导致的。4.2 内核态可编程与旁路协同另一条路线是把可编程能力做在操作系统层面用内核里已有的钩子机制挂载自定义逻辑再把热点路径下沉到硬件。这条路线最大的优势是生态——现成的工具链、现成的调试手段、现成的开发者。它的边界在于内核里的钩子终究要经过主机 CPU卸载的是部分动作而不是整条路径。所以它适合做策略类的卸载比如在包的早收阶段就做丢弃决策避免包进入协议栈之后再被丢掉不适合做整条转发路径的迁移。实际项目里最常见的是混合模型控制逻辑用内核态程序写热路径的具体执行交给卡上的流水线两边通过共享的表结构同步。这种模型的复杂度在于版本对齐——内核侧程序的字节码版本、卡上的固件版本、主机内核版本三者必须匹配任何一方升级都可能打破平衡。第 5 章会专门讲这个。4.3 通用多核方案的价值不在性能跑在卡上通用核里的用户态转发程序性能上确实打不过硬件流水线尤其在小包上。但它有两个不可替代的价值。一是复杂协议栈的承载能力。有些卸载场景需要完整的 TCP 状态机、需要处理分片重组、需要做应用层协议识别这些在流水线里做会非常痛苦在通用核上就是普通的 socket 编程。二是生态复用。主机上跑的成熟开源组件改一改就能搬到卡上开发成本低得多。所以我的判断是通用多核方案应该定位在控制面 复杂服务面而不是高频数据面。把需要复杂状态机的部分放这里把每包都要做的机械动作放流水线里两者配合才是合理的用法。把所有东西都塞进通用核最后一定是小包性能惨不忍睹然后被迫加核、加功耗、加成本。4.4 主机侧抽象层决定这套东西好不好用最后一层容易被忽略但极其影响体验主机侧看到的接口形态。常见的有三种——直通模式主机直接看到卡的物理功能、虚拟功能模式通过 SR-IOV 切分出多个虚拟功能给虚机或容器、以及抽象设备模式主机看到的是一个标准化的虚拟设备具体实现被隐藏。直通模式性能最好但牺牲了可迁移性和热插拔能力。虚拟功能模式是当前主流兼顾性能和一定程度的隔离。抽象设备模式最灵活虚拟机可以在不同节点之间迁移而感知不到底层硬件差异代价是数据路径上多了一次翻译。选择哪一种本质是在性能和运维灵活性之间做取舍。我的经验是面向多租户的云环境优先考虑抽象设备模式面向性能敏感的裸金属业务优先直通或虚拟功能。中间地带可以按业务分级不必全集群统一。5. 落地时会真实遇到的几个坑5.1 虚拟化环境下的透传与热迁移矛盾把卡的功能透传给虚拟机是性能最优解但它和热迁移天然冲突——虚拟机的内存可以搬到另一台物理机卡上的硬件状态搬不走。常见补救方案有三种迁移前把卸载功能临时切回软件路径、迁移后重新建立硬件状态、或者干脆禁止带卡虚机的热迁移。第一种方案最优雅但实现最难因为切换过程中连接会短暂中断对有状态的长连接业务比如数据库是致命的。第二种方案对无状态业务友好对有状态业务基本不可行。第三种最粗暴但在很多实际部署里就是最后的选择。我在一个项目里踩过的具体坑是迁移窗口内新建立的连接被建在了软件路径上迁移完成后没有自动切回硬件路径结果这部分连接的转发性能一直是降级状态直到节点重启才恢复。这个问题在监控上看不出来因为总吞吐没有明显变化只是 CPU 悄悄高了一截。后来我们的做法是加一个定时巡检对比活跃连接数和硬件表项数差值超过阈值就告警。5.2 固件、驱动、主机内核的三方版本对齐这是最枯燥但最消耗时间的问题。一块卡的可工作状态依赖三个东西的版本互相兼容卡上的固件、主机上的驱动、主机内核。三者任何一个升级都可能打破兼容。常见的翻车形态内核小版本升级导致驱动的某个接口签名变化驱动加载失败卡完全不可用固件升级后默认配置变了原来能跑的流水线程序加载报错驱动和固件版本不匹配时不一定报错而是某些功能静默失效。我的建议是把这三者的版本组合当成一个整体的发行版来管理维护一张兼容矩阵表任何一方要动都要查表。在自动化部署里把这个组合写进镜像或者配置管理而不是靠装最新版这种思路。出问题的组合典型表现排查手段固件升级、驱动未升级程序加载失败或部分功能静默失效对比固件与驱动的接口版本号查兼容矩阵驱动升级、内核未升级驱动加载失败卡不识别看内核日志检查符号依赖内核升级、驱动与固件未动网卡收发包异常或中断亲和错乱检查中断分配与 NUMA 绑定5.3 卸载之后看不见了是最要命的问题主机上的转发进程有现成的监控进程 CPU、连接数、队列长度、丢包计数。卸载到卡上之后这些指标大部分消失了取而代之的是一堆需要专门工具去读的硬件计数器。如果没有提前把观测性做起来排障时会陷入知道有问题但完全不知道问题在哪的困境。必须提前打通的观测项至少包括卡上数据面的每队列收发计数与丢包原因分类、控制面的表项数量与更新频率、板载内存与缓存的使用率、到主机的 PCIe 带宽利用率、卡上通用核的负载与延迟分位数。这些数据要能进到和主机指标同一个监控体系里而不是分散在几个不同的工具里。一个实用技巧在流水线程序里预留几个影子计数器专门统计那些被规则命中的包数。上线初期这些数字能帮你确认规则是否生效出问题时能快速定位是哪条规则吃掉了流量。5.4 性能测试里的三种假象第一种假象是单流大包。实验室里跑一条 TCP 流、包长 1500 字节轻松线速换成几万条并发短连接、平均包长 200 字节性能掉一半。原因在小包处理和表项查找的缓存局部性上。第二种假象是空载控制面。压测的时候转发表是静态的控制面几乎不动生产环境里表项每分钟变上百次每次变更可能触发流水线重编译或者表项同步这些开销在压测里完全看不到。要测就得用带编排的压测环境让服务实例不断地起停。第三种假象是忽略尾部延迟。平均延迟看起来很好但 P99 可能是平均值的三倍。卸载方案的尾部延迟往往来自控制面的同步操作和板载内存的突发争用这些在平均值上被稀释掉了。验收指标必须写 P99 甚至 P999。6. 技术方向的判断未来两三年看什么6.1 从纯卸载走向卸载 就近计算早期方案的定位很纯粹把主机上的活搬到卡上省 CPU。现在的趋势是让卡上多出来的这些算力做点额外的事——就近做流量采样与聚合、就近做日志预处理、就近做轻量的推理和规则评估。逻辑很简单数据在卡上过一次顺手就把统计做完了比送到主机再算一遍划算得多。这个方向的实际价值取决于就近计算的结果有多少需要回传。如果只是聚合后的指标回传量很小收益明显如果要把原始数据样本全回传那和送到主机处理没本质区别。评估这类方案时问的第一个问题应该是计算结果的数据量相对原始流量是多少6.2 内存语义变化带来的变量主机与加速卡之间的内存访问模型一直是瓶颈。当前主流还是显式的数据搬运包在卡上要处理就得搬到主机或者反过来。如果两边能共享一致性的内存视图很多搬运就变成了访问数据路径会短很多。这也是为什么业界都在关注新的互联标准。方向上值得留意的是三点卡上内存能不能被主机侧以接近本地内存的延迟访问、能不能做细粒度的缓存一致性、以及这种共享对隔离性的影响。第三点尤其关键多租户环境下共享内存语义意味着更复杂的权限和清理逻辑做不好就是信息泄露的源头。短期内不要指望这个变化立刻改变架构但它会逐渐侵蚀为什么要把数据搬来搬去这个前提。做架构设计的时候把数据搬运层做成可替换的抽象未来切换的代价就小。6.3 多租户隔离与可信启动会成为硬门槛一块卡被多个租户共享的时候隔离的粒度决定了它能用在什么场景。当前的隔离主要靠硬件分区和地址空间隔离但卡上跑的是完整的软件栈固件、驱动、管理代理任何一个环节出问题都可能突破边界。我判断这个方向会成为选型的硬门槛原因是监管和合规的要求在收紧谁能证明卡上的代码是可信的、谁能证明租户 A 的数据不会被租户 B 读到、谁能证明固件没有被篡改这些会逐渐从加分项变成准入项。技术上对应的能力包括度量启动、固件签名验证、运行时的内存隔离审计、以及可验证的清理流程一块卡从租户 A 转给租户 B 时怎么证明上一份数据清干净了。6.4 什么团队现在就该下场什么团队可以再等等我的判断标准很朴素看你主机上有没有一个持续占用大量 CPU、且逻辑相对固定的基础设施功能。该现在下场的单机容器密度很高、虚拟交换开销已经占到主机 CPU 两三成以上的有明确的加解密或安全策略需求且流量规模已经让主机吃不消的存储访问密集、IO 路径上的协议处理明显拖慢应用的。这几类场景收益直接、可量化做完就能看到数字变化。可以再等等的业务本身还在快速迭代、网络策略几乎每周都在改的团队里没有人能接手卡上程序开发和调试的规模还很小、主机 CPU 利用率长期在 30% 以下的。这几种情况下引入这块硬件增加的管理成本大概率超过省下的算力。最后分享一个我自己的做法。每次评估这类方案我都会先做一件事在现有主机上把要卸载的那个功能单独拎出来用性能剖析工具量出它到底占了多少 CPU 周期、处理每个包花多少时间、关键状态存在哪里。这三个数字拿到手再去和方案的能力参数对照很多宣传话术会立刻失去说服力。这个动作花不了两天但能省下几个月的返工。另外一个体会是卸载这件事的收益从来不是线性的。前 30% 的卸载量能拿到 70% 的收益再往上每增加一点管理复杂度和排障难度的上升速度都远快于收益的增长。找到那个拐点然后停下来比追求全部卸载要明智得多。