简介:这份PDF由字节跳动应用研究中心负责人张扬分享,系统梳理从智能网卡(Smart NIC)到DPU的发展历程与技术动因,面向云计算、网络虚拟化、数据中心基础架构方向的开发者和架构师,适合快速建立对DPU演进和落地的整体认知。资源共包含1个PDF文件,压缩包大小约1.84MB,内容密度高,便于下载后直接阅读。目前已有446人学习下载。报告从基础网卡的性能边界讲起,分析多租户带来的网络性能/隔离要求,以及Overlay网络、VxLAN、虚拟交换机、安全隔离等让数据平面复杂度剧增的挑战;随后对比DPDK+OVS、SR-IOV早期方案,拆解Smart NIC的完全卸载、可编程性、生态兼容要求与典型硬件架构。在此基础上,进一步说明DPU作为Smart NIC超集在弹性裸金属、虚拟化并池、IO加速、热迁移/热升级等场景的支撑能力,并结合字节跳动落地实践,展示通过DPU卡对接VPC网络、分布式存储,以及用统一hypervisor(ByteVisor)支撑虚拟机、容器、安全容器的工程方案,兼具原理讲解与工程参考价值。
1. 从CPU的疲惫到专用硬件的觉醒
1.1 服务器CPU为什么越来越不堪重负
先从一个大家可能都经历过的场景说起。深夜两点,公司核心业务流量上来,你盯着监控面板,CPU占用率已经冲到95%,业务却还在报超时。让人最膈应的是——你的数据库、应用进程,哪个都没吃那么多CPU,真正把CPU耗干的是网络数据包。
处理网络数据包的每一步,从接收队列到中断处理,再到协议栈解析、内存拷贝、上下文切换,都是CPU在硬扛。你要知道,CPU那点缓存和乱序执行能力,本是用来跑业务逻辑的,结果大量算力都被“搬数据”这种体力活吃掉了。尤其在万兆乃至更高带宽的网卡普及后,纯靠CPU处理网络IO已经完全不现实,光一个内核态协议栈就能耗掉几个核。
这相当于什么呢?你请了一位顶尖的大厨,结果他每天都在洗菜、切配、刷盘子,根本没时间掌勺。服务器CPU的处境,就是这么尴尬。于是大家开始琢磨,能不能把网络、存储、安全这类基础设施层面的脏活累活,单独交出去做?
1.2 DPU到底是什么,和SmartNIC是什么关系
DPU(Data Processing Unit)之所以能在2019年前后正式成为独立品类,核心推动力不是网卡厂商,而是云厂商自己先扛不住了。
当时云计算已经普及,虚拟机、容器、SDN这些技术把网络变得无比灵活,但代价是服务器CPU被虚拟网络、虚拟存储、安全组这些基础组件吃掉了大量算力。AWS在2014年前后收购Annapurna Labs,自己做起了Nitro智能网卡;VMware当时也在做类似的事情,通过把虚拟化网络功能从CPU卸载到专用硬件上,把CPU还给租户业务。
等到NVIDIA在2020年提出“DPU”这个概念时,市面上已经有了不少“SmartNIC”形态的产品。SmartNIC字面意思就是智能网卡,带处理器的网卡,可以干一些加速、卸载的活。DPU和SmartNIC的边界时至今日仍然有争论,我个人的理解是:SmartNIC更像“网卡+可编程处理器”,主要优化网络数据路径;DPU则是“基础设施级处理器”,除了网络,还覆盖存储、安全、虚拟化下沉,并且有独立的应用编程环境。
认真讲,对一个不搞底层硬件的开发者来说,没必要在名词定义上死磕。你只需要记住一个判断标准:这块卡能不能把CPU里面那些基础设施软件的开销卸载掉?能,它就是干DPU这个活儿的。
1.3 DPU的三大核心能力:卸载、加速、隔离
很多首次接触DPU的同学,容易把它理解成“高级点儿的网卡”,这个认知偏差要纠正。DPU的完整价值,是围绕“卸载、加速、隔离”三个词展开的。
先说卸载。虚拟化场景里,虚拟交换机、防火墙、负载均衡这些网络功能原本都跑在宿主机CPU上。DPU介入后,这些数据通路完全在网卡侧完成,CPU这边基本感知不到。我在生产环境里做过对比,开启部分卸载功能后,同规格虚拟机的网络PPS性能提升了接近一倍,宿主机CPU使用率从70%掉到30%以下。
再说加速。存储场景很典型,NVMe over TCP或者NVMe over RDMA这类协议,对数据搬运动作的吞吐和延迟要求极高。DPU里有专门的DMA引擎和加密引擎,可以把数据的复制、校验、加密解密全部流水线化处理。一次数据从磁盘读到网络发出,CPU只在起点和终点各碰一下,中间全程不经过内核。
最后是隔离。这个能力在大规模云平台里利用率极高,说的直白点,就是让租户之间彻底隔开。网络策略、存储访问控制、密钥管理,全部由DPU这块独立硬件承载。就算宿主机的操作系统被攻破了,攻击者想横向移动去访问其他租户的资源,也过不了DPU这层隔离。
2. 为什么需要DPU:数据中心里的三个现实问题
2.1 存储网络的数据搬运之痛
很多人觉得存储就是把数据写到磁盘里,但分布式存储系统真正最耗CPU的其实是网络收发。你写一份数据,副本要复制到另外两台机器,每台机器都要完成一次完整的收包、校验、写入、应答流程。
传统模式下,这份工作由CPU和内存系统配合完成。网卡收到数据,先放进内核缓冲区,CPU拷贝到用户态,再交给存储进程,存储进程做完副本分发之后,还要走一次内核网络栈发出去。这一趟下来,内存总线被多次搬运,CPU晶振被大量浪费掉。
DPU能做的,是把这份数据搬运整个卸载到DPU子卡上面。DPU去访问存储节点的内存,直接通过高速总线拿到要传输的数据,经过RDMA协议封装、加密后,直接从网口发给对端。存储软件在主CPU上只需要做控制面的协调,数据面一块字节都不用碰。
有一个参数值得记住:传统TCP服务端在8核CPU上,跑到60Gbps带宽时CPU基本饱和。换RDMA跑同样的业务,80Gbps带宽下CPU使用率甚至都低于10%。差距就是这样残酷,CPU确实做不了数据搬运这种高吞吐低价值的动作。
2.2 虚拟化网络的安全与性能困境
只要是做过OpenStack、KVM这类虚拟化环境的人,应该都见过这几个现象:宿主机的OVS进程CPU飙到100%,迁移虚拟机时网络抖动到掉线,安全组规则一多网络吞吐骤降。
为什么会这样?因为虚拟机之间通信,原本是一张虚拟交换机在宿主机里做二层转发,每个数据包都要经过宿主机内核的Bridge或者OVS模块。一旦有加密隧道、SDN控制、安全组防火墙的规则叠加,每个包经过的检查点会成倍增加,碰到大流量时CPU直接成为瓶颈。
DPU在处理这类业务时的最大优势是近线速处理:数据从物理网口进来,在DPU芯片内部的硬件流水线里完成VXLAN封装解封装、转发决策、访问控制列表匹配,全程不需要把数据发到系统内存走一圈。这才是硬件卸载的核心逻辑,数据处理路径上尽量少的CPU干预,让数据面彻底脱离通用处理器。
当然,也不是所有场景都适合把网络功能下沉到DPU上。如果是小流量、延迟敏感的控制消息,走DPU转发反而会增加一跳。做架构设计时,得清楚哪些流量走数据面硬件卸载,哪些流量保留在CPU物理网卡路径,不能一概而论。
2.3 分布式应用的“快慢之争”:RDMA的价值
分布式数据库、高性能计算、AI训练集群里,节点间的通信延迟和带宽,直接决定上层能不能跑起来。DPU的另一大用途就是让分布式应用享受到RDMA通信的高性能。
RDMA,远程直接内存访问,字面意思是允许一台机器的网卡直接读写另一台机器内存里的一段缓冲区,不需要双方操作系统参与收发过程。这背后省掉的是中断、上下文切换、内存拷贝这些开销,延迟可以做到微秒级,带宽也能直接吃满网卡线速。
但RDMA早期的最大问题,是组网复杂、成本高,还需要专用的交换机来配合无损网络配置。DPU的加入把这个门槛降了不少:DPU可以以硬件方式承载复杂的RDMA协议处理,不用应用程序自己管理队列和缓冲区;同时DPU侧可以配合软件的拥塞控制、重传机制,让整个集群在普通以太网上就能获得接近无损网络的效果。
所以现在很多AI训练集群的组网方案,已经是CPU配一个DPU,DPU对外走RoCEv2链路。墙上的话不多说了,DPU在AI基础设施里的角色,已经从一个可选配件,变成了事实上的标配组件。
3. DPU的产业生态与选型指南
3.1 主流玩家和产品格局
截至现在,DPU这个赛道里玩家不算多,但每一家都有自己明确的定位和打法。
NVIDIA BlueField系列是目前认知度最高的产品线。从BlueField-2到BlueField-3,再到BlueField-4,它集成了Arm处理器核心、RDMA网卡、可编程数据路径,并与NVIDIA自家的DOCA软件框架深度绑定。好处是整个生态成熟、文档丰富、案例多;代价是你要从NVIDIA的GPU生态捆绑去考虑成本,单卡价格不便宜。
Intel的IPU产品线(基础设施处理器)思路和DPU类似但定位更宽。Intel的优势在于它有自己完整的服务器平台,IPU和Xeon处理器之间的PCIe、CXL互连路径可以做深度优化。如果你对Intel熟,上手IPU的体验会相对平滑。
AMD在收购Pensando之后,用Pensando El Dorado系列进入到这个市场,主打听从软件定义网络到安全加密、存储加速的一体化方案。Pensando的产品底层采用P4可编程流水线,灵活性很高,中信银行、中科大这类用户也有公开案例,在金融政企领域算有一席之地。
国内厂商的进度同样值得关注。中科驭数、大禹智芯等公司都有DPU产品定义和落地案例,整体的生态还在快速完善中。对于国内团队来说,选择国产品牌的优势是本地化支持响应快、合规风险低。
3.2 选型时最值得盯住的四个参数
我折腾过几块不同厂商的DPU卡,踩过不少坑。如果要给一个刚接触DPU选型的人建议,优先盯四个参数就够了。
第一,接口类型和速率。DPU卡有多种速率版本,25GbE、100GbE、400GbE,对应不同规模的业务。一般要求预留未来三年的带宽需求,买高不买低,换卡是件非常折腾的事。
第二,可编程数据路径能力。有些卡固定功能做得很好,但你要自定义一个新的转发规则时,发现硬件流水线根本不能改。如果你是在做云计算、SDN这类业务,尽量选择用P4或者C语言可编程的DPU芯片。
第三,内存和计算资源。DPU自身也带CPU核心和内存,这部分资源的规格直接决定了你在卡上跑复杂存算逻辑的能力上限。例如数据压缩、加密卸载这类工作,对DDR容量的消耗远高于你的预期。
第四,软件生态成熟度。硬件强但驱动半残的产品,买回来就是给自己挖坑。调研时重点看三件事:官方有没有活跃的社区论坛、有没有当前内核版本的驱动、文档里能不能找到生产环境部署案例。
3.3 从P4到DOCA:生态成熟度的分水岭
判断DPU生态成熟不成熟,就看一件事:上层应用开发和底层数据面编程到底隔了几层。
不完全可编程的DPU,你只能用厂商提供好的套件,比如加解密的命令、转发模板,改不了数据面逻辑。这种卡退化成“增强网卡”都算好的,更麻烦的是当业务逻辑有特殊诉求时,你根本没有实现的入口。
而真正可编程的DPU,会让你用P4语言定义数据包处理流水线,或者用C/C++直接跑在DPU侧的CPU核心上,配合SDK里提供的硬件抽象层去访问加速引擎。NVIDIA DOCA套件就是最典型的一套体系,它把底层差异化全部封装成API,开发者只需要按框架写业务逻辑。
选型时我个人建议优先看那条“软硬件协同”的完备度:有没有成熟的中间件库,有没有现成的负载均衡或存储网关参考实现,有没有从示例代码到生产运维的完整闭环。如果一套生态还需要你怎么做SDK的二次打包才能上手,那说实话,现阶段的生产环境适配成本会很高。
4. 从了解到实践:几个接地气的小经验
4.1 性能测试别只看带宽
DPU的性能指标,网络上铺天盖地都在讲带宽。你得清楚,带宽只是吞吐量的一种表达方式,真正影响用户体验的是PPS(每秒处理数据包数)和在不同包大小下的实际转发能力。
我见过某款DPU标称100Gbps,结果在64B小包场景下,PPS只能跑到标称值的六成。原因很简单,MCAM查找、包头处理这些流水线逻辑在小包场景下消耗的资源更多。而数据中心里音乐游戏为主的业务恰恰就是小包居多,像QUIC、DNS、缓存请求这类数据包很少有大包的情况。
做选型对比时,最好按小包、中包、大包和混合包四类典型业务流量,分别打一轮基准测试。同时务必要把DPU卸载的数据面流量和CPU的UNDP控制面流量分开测,否则数据会被三层网络协议栈混在一起,根本看不出DPU的性能到底如何。
4.2 上线前过一遍自查清单
我每次准备把DPU方案放到生产环境前,都会对着这份清单过一遍,踩过太多次因为低级忽视导致的故障,这份清单已经成了团队的安全线。
- 网卡固件和HOST驱动的组合版本是否在官方兼容列表里
- DPU侧内存容量是否满足业务最大并发连接数下的队列需求
- 是否在测试环境复现过大规模数据面流表的动态增删压力场景
- 带外管理端口是否与业务网络隔离,明确管理IP规划
- 固件更新和回退机制是否经过完整演练,存储介质是否有备份
- 是否对DPU自身加载时间(重启后到业务就绪时间)做了容灾预算
除此之外,还有个容易被忽视的技术小细节:在虚拟机热迁移场景下,DPU侧同步的内存量是多少。如果迁移前后DPU上的内存映射没有做增量同步,迁移完成后整个虚拟机的网络会话会全部瞬断,这个问题非常隐蔽,排查起来极其费劲。
4.3 给新手的学习路径建议
如果你所在团队准备切DPU,但对这个领域毫无基础,建议按这个顺序入门:先看技术白皮书,理解它在基础设施领域的定位;再上手跑tinyBlueField这类低成本的模拟器,把网络卸载、存储加速这些基本逻辑跑一遍;等真正涉及真实硬件时,不要一开始就搞复杂项目,先用最基础的包转发模式把设备性和连通性验证通过;最后再叠加虚拟化、RDMA、加密这类高级功能。
这个过程至少要安排两周到一个月的时间。很多人忽略了一个事实:DPU的复杂度不在于单点硬件,而在于主机CPU、DPU芯片、控制管理面三者的协同设计。不亲自在真实项目里走一遍,你是很难形成体系化理解的。
从我前面这些经验来看,DPU的未来不在某个单一场景,而是会成为数据中心标配的基础设施处理器。一个团队如果能在这个拐点时期把技术体系建立起来,之后的收获会远超你今天的付出。
本文还有配套的精品资源,点击获取