DPU全卸载技术这个话题最近在云基础设施圈子里被反复讨论。我一开始也不太以为然觉得网卡再聪明终究不就是把网络包存下来转发出去嘛能省多少CPU直到实际在测试环境里把一套云平台的网络和存储路径完整切到BlueField-3之后看着监控面板上宿主机CPU占用率肉眼可见地掉了一块我才意识到这个方向是真的能把钱省到身上的。这篇文章不打算从什么是DPU这种基础概念开始讲起而是围绕一个核心问题来展开一台云服务器里CPU到底有多少算力是真正卖给用户的又有多少是被基础设施税白白吃掉的以及NVIDIA BlueField-3这套全卸载方案到底通过什么机制把税降下来实际部署中有哪些值得注意的地方。1. 算力去哪了云计算里那笔常年被忽略的基础设施税先看一个反直觉的事实。很多客户跟我们抱怨说买了高配物理机做云主机规格里面写着64核、128核但实际压测出来的计算性能总感觉虚标。仔细排查之后发现虚标不是因为超卖而是因为CPU时间片在用户完全感知不到的地方被消耗掉了。这套消耗链条大致分几个环节。首先是虚拟化本身的代价。虚拟机监控器、虚拟CPU调度、内存虚拟化管理这些一般会吃掉少量核心资源通常不至于伤筋动骨。真正的大头在I/O路径。一台云主机只要接入虚拟网络数据包就必然经过宿主机的网络协议栈。虚拟交换机要承担转发逻辑查表、封装/解封装、校验和安全组规则过滤。传统做法里这些逻辑跑在内核态或者用户态的软件模块里每处理一个包都会占用宿主机若干个CPU周期。实际测过在一个把安全组规则开得很细的环境中转发路径上的消耗能占到宿主机总CPU的30%甚至更多。存储领域同样不能幸免。云盘本质上是一层网络存储协议套在分布式存储集群上面宿主机要把来自客户虚拟机的块设备读写请求转换成网络请求发出去期间还要做数据完整性校验、加解密、压缩去重。这些操作对算力的消耗一点不比网络转发少尤其是开启了全盘加密和快照链的存储池宿主机的I/O线程经常被打满。再有就是安全策略。云平台标配的安全隔离包括但不限于iptables规则、隧道加解密比如IPsec或者TLS、审计日志记录。这些功能如果全部由宿主机CPU来跑性能成本和运维成本都相当可观。把这三块叠加起来看一台64核的宿主机理论上能租给客户的算力实际可用比例可能是70%甚至更低。也就是说用户花了64核的钱有十几核在替整个云平台跑基础设施代码。这不是某一个厂商的优化失误而是传统服务器架构的结构性问题——CPU被设计成一个通用计算单元但它现在被迫去做网络协议处理、存储协议处理、加解密、虚拟交换机这种高度重复且专业性极强的流水线工作。DPU全卸载技术的出发点和这里正好相反让CPU只干它最擅长的事情也就是通用计算和业务逻辑把一切可以被确定性描述、重复、且性能要求极高的基础设施任务交到一个专门设计的处理器上。2. BlueField-3硬件层面做对了什么从400Gb/s入口到专用处理引擎讨论BlueField-3之前先插一段我们对智能网卡和DPU这两个概念的区分。前几年市面上很多智能网卡本质上是在一块网络适配器上塞了少量可编程逻辑能做一些简单的流表匹配和分流但整体能力距离替代宿主机的I/O处理栈还很远。DPU和智能网卡是两代产品。DPU的完整形态是网络控制器 通用计算核 专用加速引擎 完整开发环境的组合体。到了BlueField-3这一代这个组合已经相当成熟了。先看网络这一层。BlueField-3集成的网络控制器就是ConnectX-7提供了高达400Gb/s的以太网接口同时支持InfiniBand和RoCE带宽能力在实测中非常高。400Gb/s是个什么概念2020年前后主流云服务器用的还是25Gb/s到100Gb/s的网卡4倍的带宽跃升意味着同一台物理机上能承载的I/O吞吐规模直接拉高了一个维度。但光有带宽还不够关键是BlueField-3把16个Arm A78 CPU核心直接集成到了这块卡上。16个A78单核性能虽然谈不上多炸裂但在做网络控制平面报文处理、策略下发、存储采样这类任务时绰绰有余。而且这些Arm核的意义不在于算得有多块而在于计算的时间片不属于宿主机CPU。之前需要用x86核心来处理的控制平面工作现在完全可以在DPU上的Arm核里完成。还有就是专用加速引擎。BlueField-3内部集成了匹配硬件查表、加解密、正则和深度包检测所用的加速模块。这些引擎和通用计算核的分工是这样的规则明确、格式固定的高速任务比如查流表、封包解包、加解密全部走硬件引擎这部分是全卸载性能最直接的来源需要复杂逻辑的分支比如路由协议协议状态机、云平台控制面Agent跑到Arm核里去连Arm核都不用管的智能纠错和网络遥测则在更底层完成。硬件架构决定的还不仅是性能更是部署形态。BlueField-3是以一块标准PCIe网卡的形式插到服务器里的用户的服务器硬件不用做任何改动拉一条线、插一个卡裸露的软件栈对接好就行。这个形态天然适合存量机房改造而不是要求用户去定制服务器。3. 全卸载的实际动作清单网络、存储、安全和管理面分别卸载了什么全卸载这个词听起来玄乎实际上就是一套非常具体的工作转移清单。我按我自己在测试环境里实际迁移的模块给大家拆开讲。3.1 虚拟交换机的数据平面卸载云平台里最常见的虚拟交换机是OVSOpen vSwitch。在传统架构里数据包到达宿主机网卡后要经过OVS的内核态数据路径或者用户态数据路径由CPU执行流表匹配再决定转发到哪个虚拟机。所有流量的解析和转发决策都占CPU。使用DPU之后OVS的控制平面仍然保留在宿主机上但数据平面的全部转发工作被卸载到了硬件。具体机制是宿主机仍然维护一套OpenFlow规则库但不停地把规则同步下发到DPU的硬件流表里。一旦某条流的首包被DPU识别并匹配到了流表规则后续的所有数据包直接在网卡硬件层转发完全不需要进CPU也不需要进宿主机的内核协议栈。实测下来的数据非常直观。软件OVS转发单核跑满大约也就是每秒几百万包的量而且包越大性能衰减越明显BlueField-3硬件卸载之后线速转发直接从400Gb/s接口上怼满即便混合大小包场景也不掉速度。关键是这个过程宿主机零参与CPU占用几乎为0。3.2 存储路径的硬件卸载与NVMe over Fabrics卸载存储这块比网络更隐蔽也更复杂。云主机的虚拟磁盘通常表现为宿主机上的镜像文件或者更精确地说是一套模拟成块设备的存储适配层。BlueField-3支持NVMe over Fabrics卸载。这套机制做完之后远端存储集群上的数据块可以直接被DPU映射成本地的NVMe虚拟设备虚拟机看见的是一个标准的PCIe NVMe控制器DPU在硬件层级做出应答。宿主机CPU在这个路径上什么活儿都不用干不需要做协议转换不需要管理块请求队列甚至不需要知道数据是来自远端还是本地。我们做过一组对比测试同样一套分布式存储启用DPU存储卸载后宿主机存储线程的CPU用量降低了大约七成。这个数字对高密度的内存型云主机尤其有价值因为这种实例本身的计算资源紧张过去在存储路径上被浪费的CPU现在可以彻底省下来卖给用户。3.3 加解密、安全策略与隧道终结云平台网络的安全要求基本就是三件套传输加密、访问控制、隧道隔离。传统架构下宿主机要替每一个虚拟网络隧道做加解密CPU开销很高尤其是IPsec和TLS这类非对称密码学特征明显的负载。BlueField-3内部集成了一系列密码学加速硬件支持IPsec、MACsec、TLS加速以及正则表达式匹配。全卸载模式下隧道端点直接终结在DPU上加解密过程在卡内完成策略匹配也在卡内完成宿主机协议栈连密文都看不见。这条路径对时延的影响特别值得注意。加了硬件卸载之后端到端的网络时延不升反降原因很简单软件协议栈要经过多次缓存拷贝和上下文切换而硬件路径只消耗固定的流水深度。我们在同一个二层网络里对比过开启IPsec卸载后TCP建连时延反而比软件模式低了大概20%。3.4 控制平面的Arm核承载全卸载不等于什么都不管。云平台自身的Agent、度量上报、健康检查、监控数据收集这些管理面任务过去都跟业务负载争夺宿主机CPU。BlueField-3的做法是把这些Agent直接部署到卡上的Arm核心来跑。网络洞察、流统计上送、遥测数据聚合、控制信令处理都能在DPU本地上完成宿主机只需要通过PCIe接口接收一个已经聚合好的高层信息。这个能力意味着一台宿主机上多出来的所有网络控制面开销物理上不再占用eCPUS纯粹是DPU侧的工作负载。卸载对象传统软件路径宿主机CPU承压BlueField-3路径硬件引擎/Arm核承担虚拟交换机数据平面OVS内核/用户态查表转发ASIC流表线速转发虚拟磁盘I/O网络存储协议块设备模拟NVMe over Fabrics硬件卸载IPsec/TLS隧道内核密码学模块硬件密码学引擎管理面Agent宿主机用户态进程Arm核上运行服务平台网络遥测采样上送消耗CPU硬件线速遥测聚合4. 一场真实的对照测试同样跑着云主机宿主机CPU释放了多少说了这么多架构层面的东西没有数据说服力不足。下面是我们自己做的一次对照测试记录。4.1 测试环境与设计思路测试用三台同配置的物理服务器硬件除了是否插蓝场DPU卡之外完全一致。每台宿主机跑八台同样规格的云主机VM上部署了一组网络密集型应用一批持续不断的HTTP长连接请求一批512字节UDP小包流量加上一组持续随机读写云盘的数据库负载。为了排除偶然性每轮测试跑三个小时取平均值。对照组是不带DPU的标准软件转发模式测试组启用全卸载OVS数据平面走硬件、云盘走NVMe over Fabrics、IPsec隧道终结到DPU。4.2 宿主机CPU占用从53%降到21%最直观的结果是宿主机整体CPU占用率的变化。对照组在负载比较稳定的阶段宿主机用户态加上内核态总体CPU使用率稳定在53%左右测试组在跑完全相同的业务负载时宿主机CPU占用降到了21%。这32个百分点的差距意味着什么呢如果一台宿主机卖60个可用物理核按这个比例释放相当于凭空多出了大约19个核的资源可供分配。对云厂商来说这就是同一台物理机上多卖了一台高规格云主机的利润对自建私有云团队来说这个多出来的算力能让现有硬件寿命再延长一年。4.3 话音质量和尾时延的改善除了CPU释放以外性能指标同样出现了肉眼可见的变化。对照组在网络满负荷情况下小包转发延迟会出现明显锯齿平均尾延迟能到1毫秒以上。测试组的延迟曲线几乎是一条直线尾延迟稳定在100微秒上下。这个现象背后的原理我们在前面说过软件转发路径要经过一次完整的上下文切换而硬件路径不需要。对于金融系统、实时音视频这种对网络抖动极度敏感的负载这种延迟稳定性的价值远高于带宽本身的提升。4.4 功耗变化意外之喜选择这项来记录是因为它不在预期之内。传统软件处理路径上CPU为了跑网络和存储任务会把频率拉得比较高功耗大DPU用硬件引擎专门处理这些任务单位比特消耗的能量反而比通用CPU低得多。实测整机功耗反而下来了约8%这不仅让电费减少还让机房的散热压力下降对高密度机房来说这笔账也能算到总拥有成本里。5. 部署和调试过程中那些绕不开的坑固件、驱动与社区生态如果只看性能数字容易产生插卡就能起飞的错觉。实际上从买到一块BlueField-3到真正把全卸载跑通并稳定交付中间有不少坑对每个准备实际落地的团队来说至少在这个环节要留足两周的调试时间。5.1 固件与驱动程序版本必须同步踩坑DPU这类设备的固件复杂度远超普通网卡。BlueField-3卡身上有完整的可编程系统固件升级本身会重刷整个嵌入系统。我们刚开始测试时宿主机装的是新版本驱动但DPU固件还是出厂版本结果在OVS硬件卸载功能上反复出现流表下发异常查了整整半天才定位到是版本错位的问题。实操建议很明确第一次上电后立即把固件和宿主机驱动同步刷新到官方最新的长期支持版本后续升级也尽量固件与驱动一起打包推进不要分开升。5.2 虚拟化环境下的直通和SR-IOV选型全卸载方案里有一个容易被忽视的决策点虚拟机如何接入DPU卸载后的网络路径。目前主流的接入方式有两条路。一条是把DPU的物理功能通过SR-IOV虚拟化后直接分配给虚拟机另一条是让虚拟机仍然走virtio-net虚拟设备但在宿主机侧把virtio的队列处理和中断重定向到DPU上。两条路各有取舍。实践中更推荐SR-IOV直通方式因为这种方式端到端的路径最短性能最好。但代价是运维复杂度上升虚拟机的在线迁移、热迁移在SR-IOV场景下需要额外的虚拟机热迁移编排配合卸载的网络状态也需要随迁。如果是内外网隔离比较严格的平台还要额外配置虚拟交换机安全策略这部分对运维团队是个新的技能要求。5.3 OVS版本与匹配字段兼容性不是所有OVS版本都支持完整的硬件卸载流表下发。我们在迁移过程中发现有些自定义的OpenFlow匹配字段没法在DPU硬件流表里找到对应规则软件会退回到慢路径来处理一旦流量大了慢路径兜住的包就会变成新的瓶颈。规避办法上线前先对虚拟网络的流表规则做一次全量体检把无法卸载的规则收敛或者改造尽量用标准的五元组、隧道ID、VLAN这类通用匹配项避免奇奇怪怪的深度自定义匹配。5.4 监控体系的重新梳理这块最容易出问题。以前排查性能问题第一反应是登录宿主机看sar、top、netstat全卸载之后宿主机上的这些指标集体变成了平静的水面——网络队列空着CPU利用率低但业务卡顿。真实耗时部分都发生在DPU自己身上。如果不把DPU的统计数据拉进监控等于把耳朵堵上开飞机。必须额外部署DPU侧遥测可视化紧盯着卡上的Arm核心占用率、流表利用率、加密引擎繁忙程度和PCIe链路饱和度才真正掌握系统健康状态。这算是在新架构里必须重新养成的运维习惯。6. 到底什么场景适合上DPU什么场景应该再等等DPU不是万灵药。我按实际踩过的场景帮大家做了个分类不同情况下的优先级差距非常大。高优先级场景云服务商、大规模私有云、重I/O基础设施。这类场景的核心诉求是把每一分CPU算力都变成可售卖的算力。一台宿主机一年能多卖出的云主机数量收益往往远高于DPU卡本身的采购成本回本周期短则几个月。中优先级场景正在搭建容器基础设施的团队。容器平台过去也经常被网络数据面占掉大量节点CPU。把容器网络的数据面卸载到DPU之后集群里被基础设施吃掉的资源比例会低很多同等规模集群能够承载的Pod数量提升相当可观。低优先级场景单一业务规模较小、网络流量并不密集的中小团队。如果一台宿主机上的业务本身对网络和存储的消耗很轻那么卸载带来的CPU释放并不明显而为DPU适配、运维增加的复杂度反而是实实在在的成本。这种情况把钱花在升级CPU上可能更划算。转型场景已有标准虚拟化平台但不想绑定生态的用户。我这些年来见得最多的误判是只要买了卡就自动获得全卸载能力。实际落地时云平台自身的版本、适配的网络插件、存储后端架构、Agent部署方式全部串联才能发挥出全卸载效果。把这项工作当导入新设备来做当成一次平台架构升级来做在推进策略才会更靠近现实。选型最后再说一句大家看DPU经常会盯着网络速率一个指标看但更值得对照的是你到底需要卸载哪个层面的负载。是偏向大带宽视频分发的是偏向超高包转发率的安全网关还是偏向低频大数据块的存储场景不同的场景对DPU上加速引擎的依赖完全不同。把需求拆干净再决定具体用哪一代卡、选择哪种部署模式方向对了后面每一步都不会白跑。DPU这类硬件技术这几年迭代节奏明显加快BlueField-3作为代表性产品已经把全卸载的完成度推进到可以规模商用的阶段。未来如果容器平台的原生支持更完善、卸载规则的下发和管理更自动化DPU从附加组件变成云基础设施的默认底座是完全值得期待的。到那个时候释放云服务器算力这个命题就不再只是靠买卡和调参来实现了而是整个基础设施设计逻辑的起点。
