百度智能云为虚拟交换机 BvS 研发的新一代数据面 Sonata 入选 NSDI’27。论文回答的问题是：当网卡来自多个厂商、横跨多个代际时，云网络数据面如何持续保持高性能与稳定。

Sonata 的选择是不与任何一类网卡深度绑定，只用各类网卡共有的标准接口卸载稳定流量，把复杂多变的部分留在软件，即论文所称「以软件为中心」（Software-Centric）的数据面。生产环境中，它将软件 CPS 提升 2.13 至 2.51 倍，开启硬件卸载后进一步提升 4.3 至 11.5 倍，规则更新与版本热升级的抖动影响控制在微秒级；相关设计已在数十万台服务器上稳定运行多年。

---

恭喜百度智能云网络团队与中国科学院计算机网络信息中心合作完成的论文《Towards a Predictable Software-Centric vSwitch Data Plane in Large-Scale Heterogeneous Cloud Networks》被 NSDI’27 正式录用。

NSDI 与 ACM SIGCOMM 并称计算机网络领域两大顶会（CCF-A 类），以强调真实系统的实现与验证著称。本次 Spring 审稿周期投稿 355 篇，录用 60 篇，录用率 16.9%。

论文的核心，是百度智能云在云网络数据面上作出的一次路线选择：不与任何一类网卡深度绑定，稳定的流量交给硬件，复杂多变的流量交给软件。正是这一选择，让 Sonata 以同一套数据面适配多厂商、多代际并存的硬件环境，并持续交付可预期的性能、鲁棒性与隔离能力。

虚拟交换机（vSwitch）是云网络数据面的核心组件，云上虚拟机的流量普遍要经过它完成连通、ACL、限速与 QoS 等策略。它的性能上限就是云网络的上限，它的抖动与升级中断，会直接波及数百万个活跃实例。

随着网卡带宽迈向 400Gbps，把报文处理卸载到网卡已是行业共识；分歧在于怎么卸。业界主要有两条路线：一条让软硬件协同处理同一条转发路径，对每一个数据包的处理过程有更强的掌控力，但要针对某一类网卡深度定制，隐含前提是硬件同质且稳定；另一条让软硬件路径各自独立、各管各的流量。

百度智能云的网卡来自多个厂商、横跨多个代际，架构与接口各不相同，每项深度定制能力都要逐一重新适配。团队为自研 DPU 实现一项 VLAN 功能，开发用了一个月，全量上线用了近六个月。硬件多样性不是意外，而是大规模公有云的结构性事实。既然如此，与其和每一类硬件深度绑定，不如让软硬件路径彼此独立、各司其职：这正是 BvS（Baidu virtual Switch）的选择，论文将其概括为「以软件为中心」（Software-Centric）的数据面。

Sonata 是 BvS 的新一代数据平面，也是这条路线的生产级实现：只用各类网卡都具备的标准化接口卸载稳定、简单的长稳流量，把短连接、复杂逻辑与一致性这些真正困难的部分留在高性能软件路径上。数据面对单一硬件平台的依赖由此大幅降低；随之而来的，是对性能、鲁棒性与隔离的全新考验。

在生产环境中，Sonata 将 BvS 的软件 CPS（每秒新建连接数）提升 2.13 至 2.51 倍，达到业界先进 OVS 数据面的 2.37 至2.75 倍；开启硬件卸载后进一步提升 4.3 至 11.5 倍。规则更新与版本热升级这两类过去容易带来抖动的操作，影响也被控制在微秒级范围内。这些结果来自真实生产场景、典型业务负载与线上案例的验证：Sonata 已部署于数十万台服务器，其中线程级热升级机制已在线运行超过八年。

1. 选择软件为中心，就要接下三道难题

选定这条路线，性能与鲁棒性就更多地压在软件路径上，隔离则要在能力参差的网卡上稳定落地。而百度智能云的负载特征，恰好让这三件事各自都不容易。

第一道是性能：考验来自海量短连接。长稳流量可以卸载，而直播、P2P 下载、Serverless 等业务持续产生的短连接生命周期极短、状态多变，网卡难以承接，只能落在软件路径上。它们会迅速撑大软件会话表，实测会话表规模每上升一个量级，转发性能就明显下降。CPS 的上限，最终由软件在 CPU 上的处理能力决定。

第二道是鲁棒性：变更太频繁。仅单个 region 平均每天就有数百万次网络更新，而一次更新通常只影响不到 1% 的流，传统的 flush-all 做法每次都会清空、重建整张硬件流表，让全部流量回落到软件路径，重新学习流表，引发 upcall 风暴。此外，静态对比方案难以处理有状态连接，绑定专有硬件的方案又难以扩展到多厂商、多代际的网卡。版本升级同样无法回避，2025 年 BvS 在线上升级了 57 次。主备进程方案要从零重建所有网卡端口并与固件重新协商，中断时间随虚拟设备数量线性增长，动辄毫秒乃至秒级；而 400Gbps 带宽下，毫秒级中断已足以造成严重丢包。

第三道是隔离：策略需要由软件统一表达，执行又要尽量落到硬件里。限速放进网卡执行，才能降低 CPU 开销、缩短控制延迟，并管住已卸载的流量；但数据面要服务数百万条流，网卡能提供的限速器（meter）数量十分有限，逐流限速在资源上做不到，各类网卡的限速能力还参差不齐。

三道难题的侧重点不同：性能依赖软件路径和硬件卸载的配合，鲁棒性依赖软件对状态变化的主动编排，隔离则要把不同网卡的通用限速能力抽象出来。共同点是，都尽量避免绑定某一类硬件的专用实现。

2. 同一套分工：复杂多变的判断归软件，确定高效的执行归硬件

开篇的路线选择，落到设计层面是同一套分工：复杂多变的判断归软件，确定高效的执行归硬件。

这套分工之所以行得通，源自论文里的几个关键观察：大量短连接最终落到相似的处理动作上；单次控制面更新通常只影响少量流；在给定链路带宽下，真正需要限速的大象流数量远小于总流数。软件负责把这些「少数」找出来，硬件资源全部花在刀刃上。

性能上，复用「会话组」而不是单条连接。短连接的五元组瞬息万变，但处理动作高度相似，主要由通信双方的地址范围和协议类型决定；生产数据显示大量规则可聚合。聚合匹配缓存（AMC）据此把同类通信合并为会话组置于快速路径之前，数据面不再被单条短连接驱动。这也是与 OVS Megaflow 的根本区别：后者只聚合规则匹配，连接状态仍按连接维护。线上开启会话聚合后，需维持的连接数降到约五分之一。其余必须精确匹配五元组的流量，瓶颈转移到查表深度上，Sonata 的思路同样是按动作做聚合，再对搜索空间做剪枝：动作相同的规则合并处理，热点规则优先命中，在完整保留优先级语义的前提下省下大部分查找。

鲁棒性上，只更新真正受影响的流。主动状态编排（PSO）在策略变更时按资源粒度取出相关规则，复用软件转发流水线生成探测报文求得正确动作，与硬件流表逐条比对，只更新出现偏差的规则，对无关流量零干扰。

版本升级的中断则来自进程重建，优化切换流程无法把它压到微秒级，Sonata 因此把热升级下沉到线程级：利用同一进程内代码段与数据段的隔离，加载新动态库后改写全局偏移表，把函数调用重定向到新逻辑。硬件队列、大页内存与卸载上下文原地保留，无需与网卡重新协商，中断稳定在数百微秒，与虚拟机数量和硬件平台都无关；主备进程方案则是数十毫秒量级。

隔离上，用物理约束化解资源约束。各类网卡共享的标准能力是 srTCM/trTCM 令牌桶算法，HQoS 以此为积木、在标准接口上加一层适配，让 QoS 策略与硬件解耦。

至于有限的限速器如何服务数百万条流：物理带宽本身限定了并发大象流的数量，一块 200Gbps 网卡单向同时容纳约 10 条 20Gbps 以上的大象流，识别并约束它们就已足够。引擎提供流、端口、TrafficGroup、虚拟机、网络五级管控，支持保底带宽加尽力突发，并对丢包敏感的 RDMA 流量以 ECN 拥塞标记代替丢弃。

三道难题逐一化解，合起来是同一句话：无论底层是哪家厂商、哪个代际的网卡，BvS 都交付同样可预期的性能、鲁棒性与隔离。

3. 生产环境里的检验

论文在四类不同网卡平台上逐级开启各项优化，CPS 的提升趋势一致：仅开启会话聚合，软件 CPS 即提升至原来的约 2.2 倍；叠加硬件卸载后，部分平台的提升接近一个数量级。策略更新期间的转发延迟不再随会话规模恶化，热升级线上实测仅引入约 300 微秒抖动。HQoS 能准确限制大象流而不误伤其他流量，RDMA 吞吐在混跑场景下保持稳定。某短视频服务开启 PSO 与热升级后，配置变更抖动与尾延迟同步下降；会话结构历经六次跨版本演进，无需重建任何活跃会话。

4. 结语

从早年尝试硬件专用化到 Sonata 成为默认数据面，BvS 要回答的问题始终没变：当硬件、流量形态、网络策略和系统版本都在持续变化时，数据面如何保持可预期。

这个问题的答案，同样适用于其他要在异构硬件上长期演进的基础设施：硬件会不断更替，沉淀在软件里的能力则可以长期复用，一次优化的收益会沿着标准接口覆盖到每一代硬件。