高性能网络 SIG 月度动态：联合 IBM 就 SMC v2.1 协议升级达成一致，ANCK 率先完成支持 原创

高性能网络 SIG（Special Interest Group） ：在云计算时代，软硬件高速发展，云原生、微服务等新的应用形态兴起，让更多的数据在进程之间流动，而网络则成为了这些数据流的载体，在整个云时代扮演着前所未有的重要角色。在这个万物互联的时代，云上的网络通信效率对各种服务至关重要，高性能网络兴趣组致力于利用 XDP、RDMA、VIRTIO 等新高效通信技术，结合软硬件一体化的思想，打造高性能网络协议栈，提升云计算时代数据中心应用的网络的性能。

01 SIG 整体进展

本月高性能网络 SIG 的主要工作聚焦在 ANCK 内核网络、SMC 和 virtio 上。

本月关键进展：

• SIG 本月与 IBM SMC 团队就 SMCv2.1 协议的关键特性达成一致。SMCv2.1 较 SMCv1 具有更强的可拓展性，是 SMC 社区的未来发展趋势。SMCv2.1 相较 SMCv2 的主要差异是引入了 SIG 提出的：

a) LGR 支持单 Link。b) LGR 支持协商最大连接数。c) 支持 RDMA write with immediate。d) 支持 vendor 特定特性等内容。

• SIG 本月发起的 [Proposal] Relationship between XDP and rx-csum in virtio-net 提案解决了 virtio-net 支持 XDP 和 rx checksum 存在冲突的问题，实现了两者的共存。

02 ANCK 内核网络

修复

修复了网卡多队列、大深度场景下发生 cpu stall 的问题：bugzilla 链接 https://bugzilla.openanolis.cn/show_bug.cgi?id=5383。

安全

本月网络方向共计修复 6 个 CVE，覆盖 wifi/net_sched/mpls/netfilter 等模块，CVE 列表：CVE-2022-47929, CVE-2023-32233, CVE-2023-1075, CVE-2023-26545, CVE-2023-28466, CVE-2023-1380。

03 SMC

本月工作主要聚焦在新版本龙蜥内核（ANCK）的开发工作，众多 SMC 关键特性预计将在 ANCK 5.10-015 (7 月发布) 中可用，稳定性也得到更充分的验证。这个版本 ANCK 的 SMC 网络栈具备取代 TCP，默认启用并加速应用通信的能力。用户不再担心回退或短链接等场景劣化网络性能。同时 SMC 可观测性和运维能力也得到了增强。

基于 eBPF 的策略协商

SMC 的连接建立依赖于 TCP 握手交换双方信息，并创建 RDMA QP（如需）和 MR 等，理论上建立连接的开销较大。对于某些类型的应用，频繁创建和释放连接的场景下，SMC 并不具有优势甚至性能下降。我们在最新的 ANCK 内核中引入了基于 eBPF 策略协商机制，当 eBPF 程序探测到用户频繁创建和释放连接时，将会自动切换至 TCP 模式。对于长链接，则会优先使用 SMC 加速应用通信。

首次支持并启用 SMCv2.1

龙蜥社区和 IBM 在 SMC 上保持密切的合作，当前我们提出的 SMC 协议关键特性，都会体现在 SMC 协议规范中。SMCv1 协议由于扩展性差等原因，所有的协议扩展将合并至 SMCv2 的扩展协议 v2.1 中，并提供向下兼容。龙蜥 ANCK 是社区中首个支持 SMCv2.1 协议的内核，我们在此版本默认启用 v2.1 协议，并进行了充分的测试，发现了多个 v2 的隐藏问题并已经修复合入到 ANCK 和上游社区版本。

RDMA write with immediate（WI） 支持

当前 SMC-R 每个请求会通过一次 RDMA_SEND 和一次 RDMA_WRITE 将数据和描述信息发送给对端，对应至少需要两个数据包。对于云上的场景小包的场景，意味着会增加一倍的数据包，而云上虚拟机往往 PPS 会根据实例规格会有限制，导致在数据包很多且大部分都是小包的场景，如 Redis 很容易打到 PPS 的限速影响性能。

针对此问题与解决方案，龙蜥社区高性能网络 SIG 和 IBM SMC 团队经过多轮沟通基本达成一致，SMC 协议将会引入 WI 特性的支持优化此问题。

其他特性

本次版本还包括众多关键特性，我们也将在龙蜥社区持续分享：

• AF_INET 协议族下的 SMC 协议实现，将 SMC 回退 TCP 的开销缩小在 2% 以内。配合 eBPF 策略协商可以提供近乎透明的网络加速体验。
• SMC 内存资源限制，当收发缓冲区达到上限时，将自动回退到 TCP，对于内存受限的小规格容器更友好。
• 全面支持 SMCv2.1 协议，除 SMC WI 外，还提供了 LGR 协商，单 link 支持和 vendor 扩展支持。

04 virtio

virtio-net 支持 AF_XDP zerocopy

AF_XDP 是一个 bypass 内核协议栈的新收发包框架。它可以把驱动的收包直接传递到用户态, 也可以把包直接从用户态传递到驱动发送出去。它的性能相比于内核的 UDP 协议栈可以提升 3-7 倍 PPS。

Anolis 社区目前正在和 virtio 社区合作，积极推进 virtio 针对 AF_XDP 的标准化的支持。这个工作分成几个部分, 本月主要推进 “virtio core 支持 DMA premapped”

本月和 virtio 社区完成多轮沟通，目前已经转向了一些实现的细节问题, 主要关注的点在于 virtio 对于 premapped 的支持是 desc chain 粒度不是 vq 粒度的。

• desc chain 粒度地, 要增加一些运行态的状态记录, 增加内存使用, 可能引入一些 cache line 相关的问题。
• vq 粒度, 可以不用引入每一个 desc chain 粒度的纪录, 但是在回收这方面会带来一些麻烦。

目前讨论的结果是向 vq 粒度转移, 这要对 virtio core 进行一些改造, 增加一些新的 helper。

virtio-net 支持 XDP 和数据包 checksum offloading 共存

目前，virtio-net 支持 XDP 和 rx checksum 存在冲突，这是由[1][2]提出的问题引起的，即 XDP 可能会修改/覆盖 Partial CheckSum 相关的信息，导致协议栈验证校验和失败而丢包。但是，这也直接导致了我们不能享受 Unnecessary CheckSum offloading 节省软件 cpu 资源的能力。注意，rx CHECKSUM_PARTIAL 主要存在于虚拟化环境中，因此非虚拟化的硬件网卡没有此问题。

龙蜥社区的目标是实现 XDP 和 VIRTIO_NET_F_GUEST_CSUM 的共存，并发起了 [Proposal] Relationship between XDP and rx-csum in virtio-net（https://lists.oasis-open.org/archives/virtio-dev/202305/msg00291.html） 的提案。龙蜥社区在其中提出了四种可能的解决方案：

• 不让 virtio-net 驱动收到被标记为 VIRTIO_NET_HDR_F_NEEDS_CSUM 的数据包（partial checkSum ），此可以通过在 virtio specification 规范中添加新的特性完成。
• 修改 XDP 加载框架，新增一种标记 XDP 程序为只读的标记。XDP 的重要应用方向之一是作为监控/防火墙，其并不会修改数据包。此时我们可以为只读 XDP 的加载打开 rx checksum offloading。
• 直接打开 VIRTIO_NET_F_GUEST_CSUM。这取决于我们信任虚拟化环境是可靠的，并且数据包进入协议栈后可能不会被转发。
• 对经过 XDP 修改的 partial checksum 数据包进行流解析，以获取 transport/ip 头的信息重置 csum_{start, offset} 的信息，并重新计算伪头部校验和。

目前，上游社区认可此问题的存在，并且已经基本和上游社区达成一致，即优先尝试第四种入侵最小的解决方案。

[1] virtio-net: disable guest csum during XDP set：https://lore.kernel.org/all/20181122063631.14452-1-jasowang@redhat.com/

[2] virtio-net: fail XDP set if guest csum is negotiated：https://lore.kernel.org/all/20181122063631.14452-2-jasowang@redhat.com/

virtio-net 支持 inner header hash

隧道协议分为两种，一种是没有传输头的 legacy 协议，例如 GRE (RFC 2784, RFC 2890)，IPIP (RFC 2003)，这种隧道协议由于没有外部端口号，因此在 RSS 队列选择时会因为缺乏熵而导致队列分布不散，进而影响收包性能；另外一种是有传输头的 modern 协议，例如 VXLAN (RFC 7348), GENEVE (RFC 8926), NVGRE (RFC 7637) 等，这种隧道协议虽然可能根据外部端口号可以获取熵，但是他们没有稳定可靠的方法通过外头部标识同一条 flow。

龙蜥社区发起的 inner header hash 的提案，本月和 virtio 社区经过 v13->v15 的讨论，针对兼容未来 modern 协议的扩展性问题和硬编码协议类型的缺陷，上游社区推荐引入一个选项来使用 outer source UDP port 来做达到可能的对称哈希的需求，原因是各个隧道协议 RFC 都隐含/推荐的表示了 outer souce UDP port 需要标识一条流，社区的代码实现中也使用了一致性哈希保证了这点。

相关链接：

高性能网络 SIG 主页：https://openanolis.cn/sig/high-perf-network

inner header hash提案：https://lists.oasis-open.org/archives/virtio-dev/202306/msg00027.html

—— 完 ——