高性能网络 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 提出的问题引起的，即 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/msg00…）的提案。龙蜥社区在其中提出了四种可能的解决方案：
- 不让 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@r…
[2] virtio-net: fail XDP set if guest csum is negotiated：https://lore.kernel.org/all/20181122063631.14452-2-jasowang@r…
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/msg00…
—— 完 ——