2. 云数据中心网络卸载需求分析

云数据中心网络卸载并不是把网卡换成“更快的网卡”这么简单。它要解决的是：当租户数量从几十增长到成千上万、当虚拟机与容器在同一物理主机上混布、当东西向流量成为主体时，主机侧软件栈（vSwitch、iptables/nftables、TLS、存储协议栈）消耗的 CPU 周期会迅速挤占业务算力。卸载的本质，是把这些“与业务无关但必须做”的网络与存储处理，从通用 CPU 迁移到具备专用数据通路的 DPU/智能网卡上，同时保持云平台原有的隔离、安全与可观测语义不变。

一、五类典型场景对卸载的真实诉求

租户隔离：多租户共享物理网络，必须保证租户 A 的流量不会进入租户 B 的虚拟网络。传统做法是 VLAN 或 VXLAN 隧道，由主机 vSwitch 封装/解封装。卸载诉求是：隧道端点（VTEP）下沉到网卡，由硬件完成 VXLAN/Geneve 封装、解封装与 VNI 查表，主机 CPU 只看到“已解封装的原始报文”。关键参数是 VNI 数量、隧道表项规模与封装后 MTU 开销（典型 VXLAN 增加 50 字节，需相应调整物理口 MTU 至 1600 以上）。

虚拟交换：同一主机上 VM、容器、裸金属共存，需要二层转发、ACL、镜像、QoS。卸载诉求是把 OVS 的流表匹配与动作（如 output、drop、mod_vlan）卸载到网卡的流表引擎，形成“慢路径在 CPU、快路径在硬件”的分层结构。判断卸载是否生效，可观察 OVS 的 dpctl dump-flows 中是否出现 offload 标记，以及主机 CPU 的 softirq 占比是否下降。

安全组：安全组是有状态防火墙，需要连接跟踪（conntrack）。卸载诉求是把已建立连接的后续报文交给硬件直接放行，仅首包上送 CPU 建流。这里必须明确边界：硬件通常只卸载“已确认状态”的流，新建连接、异常报文、需要 ALG 的协议仍由软件处理。示例参数：单主机并发连接 200 万条时，若全部由软件 conntrack 维护，内存与查表开销显著；卸载后硬件维护已建流，软件仅保留控制面状态。

负载均衡：四层 LB 需要做 DNAT/SNAT、健康检查、会话保持。卸载诉求是把 VIP→RIP 的转换与后端选择下沉，硬件按五元组哈希选路，软件只负责健康检查与控制面下发。关键判断依据是新建连接速率（CPS）与并发连接数，而非单纯带宽。

存储加速：NVMe-oF、iSCSI、NFS 等存储流量对时延敏感。卸载诉求是 TCP/卸载、校验和、NVMe-oF 的封装/解封装由网卡完成，甚至支持 NVMe-oF 的硬件发起端。示例：将 4KB 随机读的 P99 时延从软件栈的约 120μs 降至硬件路径的约 60μs（此为合理假设的示例量级，非实测值）。

二、Marvell 方案的目标定位

Marvell 的 DPU/智能网卡方案（如 OCTEON 系列）在云数据中心卸载中的目标可以概括为三点。第一，数据面全卸载：把隧道封装、流表转发、连接跟踪、四层 LB、存储协议处理等高频操作固化到硬件流水线，使主机 CPU 从网络处理中解放出来。第二，控制面保持开放：通过标准接口（如 OVS、DPDK、DOCA 类框架或厂商 SDK）让云平台继续用原有方式下发策略，避免形成新的封闭生态。第三，语义一致性：卸载后的转发、隔离、安全行为必须与纯软件实现一致，否则会出现“卸载后策略失效”的严重问题。

需要特别强调的是，卸载不是“全部交给硬件”。硬件擅长的是确定性的、高频的、状态简单的操作；软件擅长的是复杂的、低频的、需要灵活策略的操作。因此 Marvell 方案的边界是：快路径硬件化，慢路径软件化，控制面标准化。任何试图把全部逻辑塞进硬件的设计，都会在表项规模、协议兼容性和可维护性上遇到瓶颈。

三、卸载决策的量化依据

在实际项目中，是否卸载、卸载哪些场景，不能凭感觉，而要看量化指标。以下是一组可用于评估的示例参数（属于合理假设的教学示例，非实测值）：

判断卸载是否真正生效，不能只看带宽。更可靠的观察点是：主机 softirq 与 ksoftirqd 的 CPU 占比是否下降；OVS 或流表工具中是否出现 offload 标记；硬件计数器（如流表命中数、隧道封装数）是否随流量增长；以及在相同 CPU 配额下，CPS 或并发连接数是否提升。若这些指标没有变化，说明流量仍走软件路径，需要检查卸载开关、流表老化策略或硬件资源是否耗尽。

四、边界之外：哪些不该卸载

有三类操作通常不适合卸载到硬件。第一类是需要复杂状态机的应用层处理，例如需要解析 HTTP 头做七层路由、需要 ALG 处理 FTP/SIP 等协议。第二类是控制面与编排逻辑，例如租户网络创建、安全组规则下发、LB 后端健康检查，这些需要与云平台 API 交互，硬件无法替代。第三类是异常与首包处理，新建连接的首包必须上送 CPU 建立状态，硬件只接管后续已确认的流。

明确这些边界，才能避免两个极端：一是把所有流量都往硬件塞，导致表项溢出和策略不一致；二是只卸载少量流量，CPU 仍然被网络处理拖累。正确的做法是先量化软件路径的瓶颈点，再按“高频、确定、状态简单”的原则逐项卸载，并用前述指标验证效果。

综上，云数据中心网络卸载的需求分析，本质上是一次“把什么交给硬件、把什么留给软件、边界在哪里”的工程决策。租户隔离、虚拟交换、安全组、负载均衡、存储加速五类场景各有其卸载对象与约束；Marvell 方案的目标是数据面全卸载、控制面开放、语义一致，边界是快路径硬件化、慢路径软件化、控制面标准化。只有把需求、对象、边界和验证指标对齐，卸载才能真正转化为可观测的算力释放。