近期文章

RDMA 网络技术是什么？

RDMA（远程直接内存访问）是一种网络通信技术，允许计算机直接访问远端主机内存，绕过操作系统内核和CPU干预，实现超低延迟、高吞吐量的数据传输。其核心机制包括零拷贝（消除数据缓冲复制）、内核旁路（减少软件栈开销）及网络协议卸载（由网卡硬件处理通信协议）。该技术最初用于高性能计算（HPC）和存储网络，后扩展至云计算、AI训练等场景。

主流协议

图1 RDMA网络技术原理

（RDMA）技术允许设备直接读/写应用程序的内存，而无需与 CPU 或作系统交互，从而实现更高的吞吐量和更低的延迟。应用程序可以直接对网络设备进行编程，以对应用程序内存执行 DMA。

RDMA

图中，PoD1网络设备直接通过HCA（是RDMA专用的硬件组件）访问PoD2网络设备，绕过内核协议栈，实现零拷贝和低延迟。以下是RDMA三种主流协议：

InfiniBand（IB）：

原生支持RDMA，需专用InfiniBand网络设备和交换机。
提供物理层到传输层的完整协议栈。

RoCE（RDMA over Converged Ethernet）：

在以太网上运行RDMA，分为RoCEv1（基于以太网链路层（不支持3层转发）和RoCEv2（基于UDP/IP）。
依赖无损网络（通过PFC和ECN实现流量控制）。

iWARP（Internet Wide-Area RDMA Protocol）：

基于TCP/IP协议栈，支持广域网环境。
通过TOE（TCP Offload Engine）将TCP处理卸载到网卡。

三种网络传输协议的优势和劣势对比表：

协议	优势	劣势
InfiniBand	1.超低延迟：原生支持RDMA，延迟极低。 2. 高吞吐量：支持超高速传输（如EDR/HDR速率）。 3. 无损网络：基于Credit机制，无需额外流控。 4. 高扩展性：专为高性能计算（HPC）优化。	1.成本高：需专用硬件（网卡、交换机）。 2. 兼容性差：与现有以太网设施不互通。 3. 部署复杂：需独立网络架构。
RoCE	1.基于以太网：兼容现有以太网基础设施，降低成本。 2. 支持RDMA：在以太网上实现低延迟传输。 3. 灵活路由：RoCEv2支持IP层路由。	1.依赖无损网络：需PFC、ECN等流控，配置复杂。 2. 拥塞敏感：网络拥塞时性能下降明显。 3. 硬件要求：需支持RoCE的专用网卡。
iWARP	1.基于TCP/IP：兼容传统TCP网络，无需改造基础设施。 2. 抗拥塞：利用TCP可靠性机制，适应复杂网络环境。 3. 部署灵活：支持标准以太网交换机。	1.性能较低：TCP协议栈引入额外延迟和开销。 2. 吞吐量限制：相比InfiniBand和RoCE，带宽利用率较低。 3. 生态支持弱：硬件和软件支持较少。

RoCE基于以太网实现远程直接内存访问（RDMA），旨在通过绕行内核协议栈提升数据传输效率，成为高性能计算、分布式存储和AI训练场景的热门选择。然而，其核心设计依赖无损网络和特定硬件支持，导致实际部署面临显著挑战：

配置复杂性：需手动协调PFC（流量控制）、ECN（拥塞通知）和QoS策略，跨厂商设备兼容性差，运维门槛高；
网络僵化风险：PFC的逐跳反压机制可能引发广播风暴或死锁，大规模组网时稳定性存疑；
扩展性限制：RoCEv1局限于二层网络，RoCEv2虽支持三层但受限于UDP/IP的封装开销和路由延迟，跨数据中心场景性能易波动。

这些劣势促使业界探索自动化配置工具（如星融元“一键RoCE”）和软硬件协同优化方案，以平衡性能与部署成本。

星融元RoCE无损以太网

星融元通过其创新的一键RoCE功能和智能拥塞管理方案，显著简化了RoCEv2网络的配置流程并有效解决了网络拥塞导致的性能下降问题。以下是具体实现方式和优化策略：

如何通过一键RoCE简化配置流程？

1. 一键式命令封装：传统RoCEv2网络需手动配置PFC（基于优先级的流量控制）和ECN（显式拥塞通知）等复杂参数，涉及多步骤QoS策略调整。星融元的AsterNOS操作系统通过业务级命令行封装，将原子级配置整合为单条命令（如show roce），实现一键启用或关闭无损网络功能，极大降低工程师的操作复杂度。

2. 集中化配置与状态展示

全局视图管理：通过show roce命令，可集中查看全网的RoCE配置状态、队列映射、Buffer使用情况、PFC/ECN触发次数等，无需逐台设备执行多个命令。
业务级参数调优：针对不同业务场景（如HPC或存储），提供默认模板配置，同时也支持通过QoS命令行精细调整PFC和ECN参数，满足定制化需求。

3. 兼容性与易用性增强

思科风格命令行（KLISH）：AsterNOS支持传统CLI操作习惯，降低学习成本。
自动化部署工具：结合RESTful API和零接触部署（ZTP），实现网络快速上线，减少人工干预。

如何解决网络拥塞时的性能下降？

PFC工作流程

1. PFC+ECN的无损保障机制

PFC（优先级流量控制）：为存储等高优先级流量划分独立队列，当检测到队列拥塞时，触发暂停帧（Pause Frame）避免丢包。
ECN（显式拥塞通知）：在IP头部标记拥塞状态，通过CNP（拥塞通知包）反馈至发送端，动态调整流量注入速率，防止拥塞扩散。

2. 硬件与架构优化

超低时延交换机（CX-N系列）：Port-to-Port转发时延低至400ns，支持高密100G/400G端口，减少存储集群内部通信跳数（不超过3跳），降低端到端时延。
Spine-Leaf架构设计：通过扁平化组网优化流量路径，避免传统多层架构的瓶颈。

3. 可视化监控与快速排障

Prometheus集成：通过容器化监控工具roce_exporter，实时采集RoCE网络指标（如拥塞次数、CNP触发频率），实现可视化分析。
故障集中定位：使用show roce命令聚合关键调试信息，快速定位拥塞源或配置错误，缩短排障时间。

应用场景与效果

分布式存储网络：在存算分离场景中，通过RoCEv2+PFC+ECN构建零丢包、低时延的后端存储网络，加速多副本同步与数据重建。
高性能计算（HPC）：支持大规模并行计算任务，通过无损网络减少通信延迟，提升算力集群效率。
云数据中心：在混合业务负载下（存储、计算、AI），通过优先级隔离和动态拥塞控制，保障关键业务SLA。

性能测试：https://asterfusion.com/blog20241011-roce-test-report/

【参考文献】

返回资源中心

最新动态

SONiC交换机 PK IB交换机，是“越级碰瓷”还是“有点东西”？

关注星融元

聊起AI、HPC或其他无损传输网络场景，RoCE or IB 无疑是个老生常谈的话题了。关于两种协议栈的区别和联系，我们之前有写过一篇详尽的文章（请参阅：RoCE与IB协议栈对比解析）。简言之：RoCE 实际上只是将成熟的IB传输层和RDMA移植到了同样成熟的以太网和IP网络上。

IB因其是最早支持RDMA的协议，起步早，技术成熟，在一整套专用软硬件体系加持下，可提供极致的低时延传输性能，但同时也因供应商唯一，导致整体TCO较高。

与之相对的，RoCEv2在互操作性和成本上的显著优势被认为更适合大规模部署，例如今年xAI公司在美国孟菲斯建设的十万卡AI集群，便是使用400GbE以太网构建的无损高速网络。

开放网络能否平替IB？

援引Amazon高级首席工程师Brian Barret的话，AWS之所以放弃IB方案主要是因为：

“要满足资源调度和共享等一系列弹性部署的需求，专用的IB网络集群如同汪洋大海中的孤岛”

既然追求标准开放与多厂商兼容已是业界共识，以SONiC为代表的开放网络在顶级大厂云的商业化部署也有目共睹了，我们不禁要问：到了性能要求更苛刻的AI/HPC场景，支持RoCE的开放网络能否担得起 “IB平替” 的期待？

或者再进一步，开放架构的力量能否赋能更广大的数据中心建设运营者？ 比如简化受人诟病的RoCE网络部署调优，提高运维诊断能力等等…或者更多可能？

铺垫有点多了，上干货！

测试背景

我们挑选了三大典型场景下的SONiC交换机（RoCE）和IB的现场实测对比结果，涉及AI训练，HPC和分布式存储环境。测试结果保真保鲜，同时也会简要附上方法步骤，希望能对各位读者有所参考价值。

AI智算场景：E2E转发测试、NCCL-TEST、大模型训练网络测试
HPC场景：E2E转发性能、MPI、Linpack、HPC应用（WRF、LAMMPS、VASP）
分布式存储：FIO工具压测读写性能

当然，正经搞对比测试不能不讲武德，跟IB正面对垒的选手绝不能是随便淘个白盒跑跑社区版软件的野生玩家。被测RoCE交换机为星融元CX-N系列，产品采用超低时延硬件平台，搭载企业级SONiC发行版AsterNOS，全端口标配支持RoCEv2，以及EasyRoCE Toolkit。

EasyRoCE 是星融元依托开源、开放的网络架构与技术提供的一系列实用特性和小工具。从前期规划实施到日常运维监控，EasyRoCE 简化了各环节的复杂度并改善了操作体验，更提供二次开发和集成空间，供网络架构师充分利用开放网络最新技术成果。

Toolkit 更新传送门：官网详情页 | 统一监控面板（UG） | 高精度流量监控（RTR）| 一键RoCE部署（ORD）

CX-N系列型号规格如下表所示：

星融元产品

测试结论

先说结论，开放架构的星融元CX-N系列交换机（RoCE）与IB交换机的端到端性能基本持平，局部超越。

AI智算场景

1、E2E转发带宽达到网卡直连速率上限，单机转发时延低至560ns

2、双机16卡运行NCCL-test （ring算法），通过两台被测交换机测得最大总线带宽与IB交换机基本一致（约195GBps），且带宽使用率与网卡直连情况一致，已达到服务器Scale-out网络传输速率上限。

3、轨道优化拓扑下，双机16卡 Llama2-7B（样本序列长度2048）的单次训练用时与网卡直连以及IB组网的测试结果一致。

HPC 场景

1、E2E时延表现与IB交换机基本持平，差异保持在纳秒级。

2、MPI基准测试，E2E表现与IB交换机基本持平，时延差异保持在纳秒级。

3、Linpack效率与使用同规格IB交换机组网结果基本相当，差异约在0.2%。

4、HPC集群内并行运行WRF、LAMMPS和VASP应用，RoCE交换机完成一次相同计算任务的平均用时与使用IB交换机组网的用时基本相当，两者差异在0.5%~3%之内。

LAMMPS WRF

VASP

分布式存储场景

采用RoCE组网的分布式存储系统读写性能（IOPS）与采用同规格IB组网持平，部分条件下优于IB。

IOPS

HPC集群架构和通信流量特征

HPC 集群由多个联网的高速算力服务器组成，广泛使用CPU-CPU的多节点并行计算，并结合GPU、FPGA加速器的异构计算进一步提升性能。节点之间通过高速网络互联完成实时通信，并有一个集中式的管理节点来管理并行计算工作负载。HPC领域专注于解决复杂的科学问题、完成各类场景模拟等任务，与之相关的仿真和模拟技术对计算精度要求极高，通常采用双精度浮点运算（FP64）。

从方法论的角度来看，AI和HPC都是借助并行计算提高运算效率，并通过可扩展设计（Scale-up或Scale-out方向）来适应不断增加的工作负载。但对比AI集群中的大规模集合通信，HPC流量模型多为点对点的局部通信或邻居通信，传递64B-128MB的小消息，主要是对时延极其敏感——例如电磁仿真、流体动力学和汽车碰撞等计算场景高度依赖各节点间的工作协调、计算同步以及信息高速传输。

当然也有相对数据密集型的场景，如气象预报、基因测序、图形渲染和能源勘探等，计算节点在处理大量数据的同时又产生了大量中间数据，虽然也需要较高的网络吞吐量，但与AI训练不在一个量级。（🔗一文揭秘AI智算中心网络流量 – 大模型训练篇）

下表简单总结了HPC集群与AI智算集群的的联系与区别：

	HPC	AI 训练
相似点	采用并行计算和可扩展的集群设计提高效率，要求大存储和大内存资源处理数据集，计算和存储节点使用高速网络（IB/RoCE）实现互联，资源分配和作业管理系统都依赖复杂的软件栈实现
算力硬件	主要是CPU、可能包括GPU或FPGA，但使用频率低于AI训练	GPU，以及专为AI优化的TPU
运算精度	FP64高精度计算	FP32、FP16，概率性的近似计算
流量模型	点对点的局部通信或邻居通信，多传递64B-16MB的小消息	大多是大规模集合通信，传递128MB以上大消息
数据管理	结构化的、模拟数据	非结构化数据
软件栈	MPI、OpenMP、科学计算数值库	TensorFlow、PyTorch
工作负载	紧密耦合的、同步的	迭代的、异步的

无论是在AI智算还是HPC，或是二者的融合，业界已普遍采用RDMA技术的内核旁路机制大幅降低了服务器侧的I/O时延。而为了切实提高集群生产效率，应用RDMA需同时建立端到端的超低时延无损网络，目前两大主流路线是Infiniband与RoCEv2。前者为专有协议，需要专用硬件搭建专网，后者则在IB基础上改进了报文格式，使其支持在以太网上传输，关于两种协议栈的详细对比可参考（RoCE与IB对比分析（一）：协议栈层级篇）

选择IB还是RoCEv2已是老生常谈的话题了，IB因其属于是RDMA原生的协议，由Mellanox/NVIDIA独家供应的IB交换机可提供极致性能，但RoCEv2在互操作性和带宽成本上优势明显，且随着开放网络技术的快速迭代，基于SONiC的高性能以太网交换机的端到端通信效率也可做到IB相当，甚至局部超越。

HPC网络性能测试方案设计

围绕HPC业务的实际要求和当前市场关注的IB替代问题，我们构建了面向典型HPC场景的网络测试，在同一测试环境下，部署同等规格速率的Mellanox IB和星融元的RoCE交换机（32 x 100G）互为对照。测试项目包括转发测试、MPI基准测试、Linpack基准测试和HPC应用测试。

完成基础环境部署后（步骤见附录），我们在服务器Centos7.8系统下切换Mellanox InfiniBand卡的工作模式，确保两台服务器上的网卡工作模式正确对应被测交换机（IB或RoCE）

端到端转发时延测试

测试两款交换机在相同拓扑E2E（End to End）场景下的转发时延和带宽。采用Mellanox IB发包工具进行发包，测试遍历2~8388608字节。星融元交换机的E2E表现与IB交换机基本持平，带宽利用率与IB同为96%左右，两者时延差异保持在纳秒级。

MPI基准测试

MPI是一种消息传递接口，用于实现在多个计算节点之间进行并行计算和数据通信。MPI的核心思想是通过发送和接收消息进行节点间的数据交换，实现分布式计算的目标。

MPI提供了一系列的并行计算函数，如任务分发、结果收集和同步操作等，以及消息传递函数，如发送消息、接收消息和广播以实现高效的数据通信。通过合理地设计数据通信模式，可以避免数据冗余和通信瓶颈，提高计算效率。此外，MPI还提供进程管理函数来控制进程的创建、销毁、通信等。

MPI基准测试使用OSU Micro-Benchmark工具MPI run方式测试网卡直连和通过两台交换机的端到端时延。星融元RoCE交换机与IB交换机的端到端性能基本一致，时延差异保持在纳秒级。

LinPack基准测试

Linpack现在在国际上已经成为最流行的用于测试高性能计算机系统浮点性能的Benchmark，通过高斯消元法求解N元一次稠密线性代数方程组，评价HPC的浮点运算性能。算力使用效率=实际峰值/理论峰值*100%，其中理论峰值来自于服务器的规格参数，即主频率*核心数*每周期浮点运算次数。在测试环境下，星融元RoCE交换机与IB交换机的LinPack效率基本一致。

HPC 应用测试

WRF（天气研究和预报模型）、LAMMPS（大尺度原子/分子并行模拟工具）和VASP（维也纳全始计算模拟包）分别是气象预报、分子动力学、量子化学领域的专用工具。测试结果为被测设备和对照组完成一次相同计算任务所需时间，最终结果取连续进行三次测试的平均用时。

星融元RoCE交换机组网条件下完成一次相同计算任务的平均用时与使用IB交换机组网的用时基本相当，两者差异在0.5%~3%之内。

附录：基础环境配置

网卡MLNX_OFED驱动程序安装

[root@Server ~]# wget \
https://content.mellanox.com/ofed/MLNX_OFED-5.0-1.0.0.0/MLNX_OFED_LINUX-5.0-1.0.0.0-rhel7.8-x86_64.tgz
[root@Server ~]# tar -zxvf \
MLNX_OFED_LINUX-5.0-1.0.0.0-rhel7.8-x86_64.tgz
[root@Server ~]# cd MLNX_OFED_LINUX-5.0-1.0.0.0-rhel7.8-x86_64
[root@Server ~]# ./mlnx_add_kernel_support.sh -m \
/root/MLNX_OFED_LINUX-5.0-1.0.0.0-rhel7.8-x86_64 -v
[root@Server ~]# tar xzvf \
MLNX_OFED_LINUX-5.0-1.0.0.0-rhel7.8-x86_64-ext.tgz
[root@Server ~]# cd MLNX_OFED_LINUX-5.0-1.0.0.0-rhel7.8-x86_64-ext
[root@Server ~]# ./mlnxofedinstall

检查网卡及网卡驱动状态

[root@Server ~]# /etc/init.d/openibd start
[root@Server ~]# ibstatus
[root@Server ~]# systemctl start mst
[root@Server ~]# mst status

HPC基础环境



[root@Server ~]# cat /etc/hosts

[root@Server ~]# systemctl stop firewalld && systemctl disable firewalld
[root@Server ~]# iptables -F
[root@Server ~]# setenforce 0 
[root@Server ~]# ssh-keygen
[root@Server1 ~]# ssh-copy-id -i id_rsa.pub root@192.168.4.145
[root@Server2 ~]# ssh-copy-id -i id_rsa.pub root@192.168.4.144
[root@Server1 ~]# yum -y install rpcbind nfs-utils
[root@Server1 ~]# mkdir -p /data/share/
[root@Server1 ~]# chmod 755 -R /data/share/
[root@Server1 ~]# cat /etc/exports
/data/share/ *(rw,no_root_squash,no_all_squash,sync) 
[root@Server1 ~]# systemctl start rpcbind
[root@Server1 ~]# systemctl start nfs 
[root@Server2 ~]# yum -y install rpcbind
[root@Server2 ~]# showmount -e Server1
[root@Server2 ~]# mkdir /data/share  
[root@Server2 ~]# mount -t nfs Server1:/data/share /data/share

MPI Benchamarks工具安装

[root@Server ~]# yum -y install openmpi3 openmpi3-devel -y
[root@Server ~]# wget \
http://mvapich.cse.ohio-state.edu/download/mvapich/osu-micro-benchmarks-5.6.3.tar.gz
[root@Server ~]# tar zxvf osu-micro-benchmarks-5.6.3.tar.gz
[root@Server ~]# cd osu-micro-benchmarks-5.6.3
[root@Server ~]# ./configure
[root@Server ~]# make -j
[root@Server ~]# make install
[root@Server ~]# mkdir /osu
[root@Server ~]# cp -rf \
/usr/mpi/gcc/openmpi-4.0.3rc4/tests/osu-micro-benchmarks-5.3.2/* /osu

HPC 应用测试的基础环境需要在Server服务器上完成编译器的安装以及基础环境变量的配置，在Server服务器上安装第三方库以及完成zlib、libpng、mpich、jasper和netcdf软件的编译，并对依赖库进行测试。具体参考各类工具官方文档。

交换机和服务器上的配置参考

# 星融元CX-N交换机A
admin@sonic:~$sudo config vlan add 100
admin@sonic:~$sudo config vlan add 100
admin@sonic:~$sudo config vlan member add 100 Ethernet8
admin@sonic:~$sudo config interface ip add Vlan100 1.1.3.1/24
admin@sonic:~$sudo config interface ip add Ethernet0 1.1.1.1/24
admin@sonic:~$sudo config route add prefix 1.1.2.0/24 nexthop  1.1.1.2

# 星融元CX-N交换机B
admin@sonic:~$sudo config vlan add 100
admin@sonic:~$sudo config vlan member add 100 Ethernet8
admin@sonic:~$sudo config interface ip add Vlan100 1.1.2.1/24
admin@sonic:~$sudo config interface ip add Ethernet0 1.1.1.2/24
admin@sonic:~$sudo config route add prefix 1.1.3.0/24 nexthop  1.1.1.1

# Server1
[root@Server1 ~]# modprobe 8021q
[root@Server1 ~]# vconfig add ens1f0 100
[root@Server1 ~]# ifconfig ens1f0.100 1.1.3.2/24 up
[root@Server1 ~]# ifconfig ens1f1 1.1.9.9/24 up
[root@Server1 ~]# route add -net 1.1.0.0 netmask 255.255.0.0 \
gw 1.1.3.1

# Server2
[root@Server1 ~]# modprobe 8021q
[root@Server1 ~]# vconfig add ens1f0 100
[root@Server1 ~]# ifconfig ens1f0.100 1.1.3.2/24 up
[root@Server1 ~]# ifconfig ens1f1 1.1.9.9/24 up
[root@Server1 ~]# route add -net 1.1.0.0 netmask 255.255.0.0 \
gw 1.1.3.1

揭秘超以太网联盟（UEC）1.0 规范最新进展（2024Q4）

关注星融元

近期，由博通、思科、Arista、微软、Meta等国际顶级半导体、设备和云厂商牵头成立的超以太网联盟（UEC）在OCP Global Summit上对外公布其最新进展——UEC规范1.0的预览版本。让我们一睹为快吧！

UEC 1

UEC 旨在提出一种“升级版”的以太网通信协议栈用以应对AI智算、HPC等领域对RDMA网络的性能挑战——当前大规模计算节点互联场景下主要有InfiniBand和基于以太网协议的RoCE两大技术路线。有关IB和RoCE协议栈的详尽对比可参阅：

高性能网络传输：RoCE与IB协议栈对比解析

相比较为封闭的IB架构，以太网在互操作性和带宽成本上的优势已在市场层面得到了广泛认可，尤其是大规模的AI算力中心场景。当前全球TOP500的超级计算机中RoCE和IB的占比相当，以端口带宽总量计算，IB占比为39.2%，RoCE已达48.5%。

尽管IB和RoCE在高性能传输的拥塞控制、QoS皆有应对设计，但也暴露出一些缺陷。例如乱序需要重传、不够完美的负载分担、Go-back-N问题，DCQCN 部署调优复杂等等。

面向GPU Scale-out网络的UEC 1.0 规范从软件API、运输层到链路层以及网络安全和拥塞控制皆有涉及，较传统RDMA网络有了大量改进，我们将挑出重点介绍。 UEC2

什么是超级以太网系统

一个超级以太网系统的组成如下。一个集群（Cluster）由节点（Node）和网络（Fabric）组成，节点通过网卡（Fabric Interface）连接到网卡，一个网卡中可以有多个逻辑的网络端点（Fabric End Point，FEP）。网络由若干平面（Plane）组成，每个平面是多个FEP的集合，通常通过交换机互联。

UEC 3

超以太网协议栈概览

UEC4

▣ 物理层与传统以太网完全兼容，可选支持FEC（前向纠错）统计功能

▣ 链路层可选支持链路层重传（LLR），并支持包头压缩，为此扩展了LLDP的协商能力

▣ 网络层依然是IP协议，没有变化

▣ 传输层是全新的，作为UEC协议栈的核心数据包传输子层（Packet Delivery）和消息语义子层（Message Semantics）。包传输子层实现新一代拥塞控制、灵活的包顺序等功能，消息语义子层支持xCCL和MPI等消息。可选支持安全传输。另外，在网集合通信（In Network Collective，INC）也在这一层实现

▣ 软件API层。提供UEC扩展的Libfabrics 2.0

物理层

UEC 1.0规范下的物理层与传统以太网（符合IEEE802.3标准）完全兼容，支持每通道100Gbps和200Gbps速率，在此基础上实现800Gbps和更高的端口速率。

另外可选支持物理层性能指标统计功能（PHY metrics）。这些指标基于 FEC 码字进行计算，不受流量模式和链路利用率的影响。估计算法基于FEC错误计数器的数据，从而得出不可纠正错误率（UCR ）和数据包错误平均间隔（MTBPE）。这些指标衡量了物理层的传输性能和可靠性，用于上层的遥测和拥塞控制等。为了支持新的 UEC 链路层功能，UEC规范中也对协调子层（RS）进行了相应的修改。

链路层

UEC链路层最大的变化是引入了LLR（Link Level Retry）协议。它可以让以太网不依赖PFC，实现无损传输。

LLR 机制是基于帧的。每个帧都分配了一个序列号，接收端成功接收这一帧后，检查帧的序列号是否符合预期，如果正确，发送确认消息（ACK），如果发现帧乱序或者丢失，则发送否定确认消息（NACK）。发送端具有超时机制，用于保证在 NACK 丢失时重传。

传输层：UET，新一代协议栈的核心

前文提过，传统的RDMA网络传输层（包括IB和RoCE）在多路径传输、负载分担、拥塞控制以及参数调优等方面存在着不足之处。随着AI/HPC集群规模增长，网络的确定性和可预测性越来越困难，需要全新的方法来解决。

UEC传输层（UEC Transport Layer，简称UET）运行在IP和UDP协议之上, 支持实现以下几大技术目标：

▣ 支持高达 100 万个 GPU/TPU 的算力集群

▣ 往返时间低于 10μs

▣ 单接口带宽800Gbps及以上

▣ 网络利用率超过85%

选择性重传（Selective Retransmit）

传统传输协议，如TCP需要严格的传输顺序，并采用了Go-Back-N机制。而一个RDMA消息通常包含多个数据包，只要有一个数据包错误，则从这个数据包起的所有数据包都要重传。这让偶尔的传输错误被放大，加剧了网络拥塞。UEC采用选择性重传机制，仅传输错误的数据包。

乱序交付（Out-of-Order Delivery）

UET不仅支持有序传输，也支持无序传输。这是因为现代网络中通常有多路径存在，同一个流的数据包经过不同路径传输，就可能造成乱序。如果还要求严格的顺序传输，就无法利用多路径来实现负载分担。此外，选择性重传也需要无序传输的支持。为了实现无序传输，需要接收方有更大的数据包缓冲区，从而将乱序的数据包组成一个完整的RDMA消息。

UET支持四种传输方式：

▣ ROD (Reliable Ordered Delivery)

– 需要拥塞控制、有序、可靠、无重传（依旧采用Go-Back-N）

▣ RUD (Reliable Unordered Delivery)

– 需要拥塞控制、无序、可靠、无重传

▣ RUDI (RUD for Idempotent Operations)

– 可选拥塞控制、无序、可靠、重传

▣ UUD (Unreliable Unordered Delivery)

– 可选拥塞控制、无序、不可靠、重传

包喷洒（Packet Spraying）

包喷洒是一种基于包的多路径传输。由于传统传输协议不支持无序传输，同一个数据流必须按照同一个路径传输，否则就会造成乱序，引发重传。而在AI/HPC应用中，存在大量的“大象流”，它们数据量大、持续时间长，如果能使用多路径传输一个流，将显著提高整个网络的利用率。

由于支持了RUD，UET就可以将同一个流的不同包分散到多个路径上同时传输，实现包喷洒功能。这让交换机可以充分发挥ECMP甚至WCMP（Weighted Cost Multi- Pathing）路由能力，将去往同一目的地的数据包通过多条路径发送，大幅度提高网络利用率。

拥塞控制（Congestion Control）

UET 拥塞控制包含以下重要特性，由端侧硬件和交换机配合完成，有效减小了尾部延迟。

▣ Incast管理。它用于解决集合通信（Collective）中下行链路上的扇入问题。AI和HPC应用经常采用集合通信在多个节点之间同步信息，当多个发送者同时向一个接收者发送流量，就会产生Incast拥塞。

▣ 速率调整加速。现有的拥塞控制算法，在发生网络拥塞后调整速率的过程较长，而 UET 可以快速上升到线速。方法是测量端到端延迟来调节发送速率，以及根据接收方的能力通知发送方调整速率。

▣ 基于遥测。源自网络的拥塞信息可以通告拥塞的位置和原因，缩短拥塞信令路径并向终端节点提供更多信息，从而实现响应速度更快的拥塞控制。

▣ 基于包喷洒的自适应路由。当拥塞发生时，通过包喷洒技术将流量重新路由到其它路径上，绕过拥塞点。

端到端的安全

UEC在传输层内置安全。它是基于作业（Job）的，可以对整个作业的流量进行端到端的AES加密，充分利用 IPSec 和PSP（Packet Security Protocol）的能力，减小安全加密的开销，提供可扩展安全域，并且可以由硬件卸载。

在网计算（In Network Collectives）

在网计算最早应用在HPC集群，业界主要有两个思路，一是基于网卡的，二是基于交换机。

UEC V1.0 的目标是后者，即将集合操作卸载到各级交换机上完成，避免过多的收发次数，降低节点交互频率和处理时延开销，减少约一半数据传输量，从而加速All-Reduce操作。

在部署实现上，目前AI智算领域唯一大规模商用的案例仅有英伟达的SHARP（在ASIC层面实现的硬件加速），以太网设备厂家仍处在探索阶段，例如将算力内置于交换机或外接，甚至P4可编程都是可能的思路方向。

软件层：Extended Libfabrics 2.0

硬件升级：支持UEC的交换机和网卡

UEC在规范中定义了支持超级以太网交换机的架构，可以看到大体是继承了SONiC的架构。这部分的主要关注在于控制平面上支持INC和SDN控制器；数据平面升级了SAI（Switch Abstraction Interface）API调用硬件提供的INC等能力。

UEC 6

UEC同样定义了网络端点（Fabric End Point）的软硬件架构。在硬件层，网卡升级支持UEC功能。在操作系统内核态，实现网卡驱动。在用户态，基于libfabric扩展实现INC管理等功能，支持上层的xCCL/MPI/SHMEM等应用。

UEC 7

总的来说，UEC v1.0规范重构了数据中心以太网以完全替代传统的RDMA网络，用更高的性能、更低的成本实现稳定可靠、具有百万节点的AI/HPC集群。

星融元RoCE交换机与UEC

作为UEC成员单位，星融元提供的超低时延RoCE交换机（CX-N系列）全系采用高性能的标准白盒网络硬件，搭载为生产环境深度调优的企业级SONiC发行版——多项 Easy RoCE 特性，全面兼容现有规范并提供灵活、广大的升级空间，未来将平滑演进与新一代以太网标准保持同步。

RoCE与IB对比分析（二）：功能应用篇

近期文章

在上一篇中，我们对RoCE、IB的协议栈层级进行了详细的对比分析，二者本质没有不同，但基于实际应用的考量，RoCE在开放性、成本方面更胜一筹。本文我们将继续分析RoCE和IB在拥塞控制、QoS、ECMP三个关键功能中的性能表现。

拥塞控制

拥塞控制即用来减少丢包或者拥塞传播，是传输层的主要功能，但需要借助链路层和网络层的帮助。

RoCEv2 的拥塞控制机制

RoCEv2通过链路层PFC、网络层ECN、传输层DCQCN三者协同配合，实现更高效的拥塞管理，可见，RoCEv2虽然使用了IB的传输层协议，但在拥塞控制方面有所不同。

基于优先级的流量控制（PFC）

PFC在RoCEv2中被用于创建无损的以太网环境，确保RDMA流量不因链路层拥塞而丢失。核心原理是下游控制上游某个通道开启和停止发送数据包，控制方式是发送PFC Pause和Resume帧，触发时机是根据下游SW的ingress的队列数量是否达到某个阈值。

而PFC允许在一条以太网链路上创建8个虚拟通道，并为每条虚拟通道指定一个优先等级，允许单独暂停和重启其中任意一条虚拟通道，同时允许其它虚拟通道的流量无中断通过。这一方法使网络能够为单个虚拟链路创建无丢包类别的服务，使其能够与同一接口上的其它流量类型共存。

如图1所示，DeviceA发送接口分成了8个优先级队列，DeviceB接收接口有8个接收缓存（buffer），两者一一对应（报文优先级和接口队列存在着一一对应的映射关系），形成了网络中 8 个虚拟化通道，缓存大小不同使得各队列有不同的数据缓存能力。

当DeviceB的接口上某个接收缓存产生拥塞时，超过一定阈值（可设定为端口队列缓存的 1/2、3/4 等比例），DeviceB即向数据进入的方向（上游设备DeviceA）发送反压信号“STOP”，如图中第7个队列。

DeviceA接收到反压信号，会根据反压信号指示停止发送对应优先级队列的报文，并将数据存储在本地接口缓存。如果DeviceA本地接口缓存消耗超过阈值，则继续向上游反压，如此一级级反压，直到网络终端设备，从而消除网络节点因拥塞造成的丢包。

显式拥塞通知（ECN）

ECN（Explicit Congestion Notification）是一种IP头部用于的拥塞控制的标记位，允许网络设备在发生拥塞时标记数据包，而不是丢弃它们。

RoCEv2利用ECN位来标记发生拥塞的数据包，接收方在检测到ECN标记后，发送CNP（Congestion Notification Packet）给发送方，后者通过拥塞控制算法（如DCQCN）调整发送速率。

数据中心量化拥塞通知（DCQCN）

DCQCN（Data Center Quantized Congestion Notification）是一种适用于RoCEv2的拥塞控制算法，是数据中心TCP(DCTCP)和量化通知算法的结合，最初在SIGCOMM’15论文”Congestion control for large scale RDMA deployments”中提出。DC-QCN算法依赖于交换机端的ECN标记。结合了ECN和速率限制机制，工作在传输层。当接收方检测到ECN标记时，触发CNP发送给发送方，发送方根据反馈调整发送速率，从而缓解拥塞。

综上，PFC、ECN、DCQCN分别工作在链路层、网络层和传输层。在RoCEv2中，它们被组合使用，以实现更高效的拥塞管理。

PFC：防止数据包在链路层被丢弃，提供无损传输，解决一段链路的问题。
ECN/DCQCN：发送方根据拥塞标记主动调整发送速率，减轻网络负载。解决端到端网络的问题。

InfiniBand 的拥塞控制机制

InfiniBand 的拥塞控制机制可分为三个主要部分：

基于信用的流量控制

IB在链路层实现基于信用的流量控制（Credit-based Flow Control），该机制实现了无损传输，是 InfiniBand 高性能的基础。发送方根据接收方提供的信用（表示可用缓冲区空间）来控制数据包的发送，接收方在处理完数据包后发送信用给发送方，以允许继续发送新的数据包，从而避免网络拥塞和数据包丢失。

如下图所示，发送方当前可用信用值2，通过流水线传输（pipelined transfer）连续向接收方发送数据包，但此时接收方缓冲区已满，发送方会暂停发送新的数据包，直到接收方发送新的信用。

ECN机制

当网络中的交换机或其他设备检测到拥塞时，会在数据包的 IP 头中标记 ECN（Explicit Congestion Notification）。接收方的 CA（Channel Adapter）接收到带有 ECN 标记的数据包后，会生成拥塞通知包（CNP），并将其反馈给发送方，通知其网络出现拥塞需要降低传输速率。

端到端拥塞控制

发送方的 CA 在收到 CNP 后，根据 InfiniBand 拥塞控制算法调整发送速率。发送方首先降低数据发送速率以缓解拥塞，之后逐步恢复发送速率，直到再次检测到拥塞信号。这个动态调整过程帮助维持网络的稳定性和高效性。IBA没有具体定义特定的拥塞控制算法，通常由厂商定制实现。（HCA，Host Channel Adapters，or IB NIC）

RoCEv2与IB拥塞控制机制比较

两者的拥塞控制机制比较如下：

可见，RoCE与IB的拥塞控制机制基本相同，区别在于IB的拥塞控制机制集成度较高，通常由单个厂家提供从网卡到交换机的全套产品，由于厂商锁定，价格高昂。而RoCE的拥塞控制机制基于开放协议，可以由不同厂家的网卡和交换机来配合完成。

随着大规模AI训练和推理集群的扩展，集合通信流量导致了日益严重的拥塞控制问题，由此出现了一些新的拥塞控制技术，如基于In-band Network Telemetry (INT)的HPCC（High Precision Congestion Control），即通过精确的网络遥测来控制流量，以及基于Clear-to-Send (CTS)的Receiver-driven traffic admission，即通过接收方的流量准入控制来管理网络拥塞等。这些新技术在开放的以太网/IP网络上更容易实现。

QoS

在RDMA网络中，不光RDMA流量要获得优先保证。一些控制报文，如CNP、INT、CTS，也需要特别对待，以便将这些控制信号无损、优先的传输。

RoCEv2的QoS

在链路层，RoCEv2采用ETS机制，为不同的流量分配不同的优先级，为每个优先级提供带宽保证。

在网络层，RoCEv2则使用DSCP，结合PQ、WFQ等队列机制，为不同的流量分配不同的优先级和带宽，实现更精细的QoS。

InfiniBand的QoS

在链路层，IB采用SL、VL及它们之间的映射机制，将高优先级的流量分配到专门的VL，优先传输。虽然VL仲裁表 (VL Arbitration Table)能够通过分配不同的权重来影响和控制带宽的分配，但这种方式不能保证每个VL的带宽。

在网络层，IB的GRH支持8个bit的Traffic Class字段，用于在跨子网的时候提供不同的优先级，但同样无法保证带宽。

由此可见，RoCE能够为不同的流量类型提供更精细的QoS 保证和带宽控制，而 InfiniBand 只能提供优先级调度，而非带宽的明确保障。

ECMP

RoCE的ECMP

数据中心IP网络为了高可靠和可扩展性，通常采用Spine-Leaf等网络架构。它们通常在一对RoCE网卡之间提供了多条等价路径，为了实现负载平衡和提高网络拓扑的利用率，采用ECMP（Equal Cost Multiple Paths）技术。对于给定的数据包，RoCE交换机使用某些数据包字段上的哈希（Hash）值在可能的多条等价路径中进行选择。由于可靠传输的要求，同一个RDMA操作应当保持在同一个路径中，以避免由于不同路径造成的乱序问题。

在IP网络中，BGP/OSPF等协议均可以在任意拓扑上计算出等价路径，然后由交换机数据平面基于IP/UDP/TCP等头部字段（如五元组）计算哈希值并轮流转发到不同路径上。在RoCE网络中，为了进一步细分RDMA操作，可以进一步识别BTH头部中的目的QP信息，从而实施更细粒度的ECMP。

InfiniBand的ECMP

在控制平面，IB的路由基于子网管理器，在拓扑发现的基础上实现ECMP，但由于集中式的子网管理器与网络设备分离，可能无法及时感知网络拓扑的变化，进而实现动态的负载均衡。

在数据平面，IB的ECMP同样基于哈希计算和轮转机制。

总结

在拥塞控制方面，RoCE结合了PFC, ECN和DCQCN提供了一套开放的方案，IB则拥有基于Credit的一套高度集成的方案，但在应对大规模集合通信流量时均有所不足。
在QoS方面，RoCE可以实现每个优先级的带宽保证，而IB仅能实现高等级的优先转发。
在ECMP方面，两者均实现了基于Hash的负载分担。

总结来看，IB具备已验证的高性能和低延时优势，RoCEv2则在互操作性、开放性、成本效益方面更胜一筹，且从市场占比及认可度来看，RoCEv2逐渐比肩IB；但不得不承认的是，RoCE和IB在应对大规模AI训练和推理中高带宽、突发式和广播型的集合通信流量时，均有所不足，而RoCE基于其广泛的以太网生态系统，能够更快速地拥抱新技术新协议，其潜力和可塑性更胜一筹，未来有望在网络格局中扮演更重要的角色。

星融元提供一系列基于RoCE的开放网络产品与解决方案：

10G-800G的全场景互联：星融元CX-N数据中心交换机的单机转发时延（400ns）低至业界平均水平的1/4~1/5；采用BGP-EVPN、VXLAN、MC-LAG等技术构建可靠的大二层网络满足生产网络稳定性需求。
搭载开放网络操作系统：星融元AsterNOS以SONiC为内核、依托容器化的系统架构，并提供RESTful API支持第三方应用快速集成，或对接上层管理调度平台，例如OpenStack，K8s等。
EasyRoCE极简运维：支持无损网络一键部署，Prometheus + Grafana 可视化监控大屏配合专用命令行，问题快速定位解决。

参考文档：

https://zhuanlan.zhihu.com/p/643007675

https://blog.csdn.net/essencelite/article/details/135492115

https://support.huawei.com/enterprise/zh/doc/EDOC1100075566/d1e17776

https://www.researchgate.net/publication/4195833_Congestion_Control_in_InfiniBand_Networks

返回资源中心

近期文章

在 AI 算力建设中， RDMA 技术是支持高吞吐、低延迟网络通信的关键。目前，RDMA技术主要通过两种方案实现：Infiniband和RoCE（基于RDMA的以太网技术，以下简称为RoCE）。

RoCE与IB网络架构概述

RoCE和InfiniBand均是InfiniBand Trade Association（IBTA）定义的网络协议栈，其中Infiniband是一种专为RDMA设计的高性能网络，它从硬件层面确保了数据传输的可靠性，为了进一步发挥RDMA的优势，IBTA在2010年定义了RoCE。RoCE则是Infiniband与以太网技术的融合，它在保持Infiniband核心优势的同时，实现了与现有以太网基础设施的兼容性。具体来说，RoCE在链路层和网络层与Infiniband有所不同，但在传输层和RDMA协议方面，RoCE继承了Infiniband的精髓。

从市场应用占比来看，2000年，IB架构规范的1.0版本正式发布，2015年，InfiniBand技术在TOP500榜单中的占比首次超过了50%，但据最新统计，在全球TOP500的超级计算机中，RoCE和IB的占比相当。以计算机数量计算，IB占比为47.8%，RoCE占比为39%；而以端口带宽总量计算，IB占比为39.2%，RoCE为48.5%。

图1 超级计算机 500 强中 RoCE 和 InfiniBand 的利用率

图2 超级计算机 500 强中 RoCE 和 InfiniBand 的利用率

RoCE与IB报文格式对比

RoCE报文格式下图所示：

其中，RoCEv1使用了IB的全局路由头（Global Routing Header），IB BTH是IB的基本传输头（Base Transport Header），ICRC是对InfiniBand层不变字段进行校验的循环冗余校验码，FCS是以太网链路层的校验序列码。

RoCEv2中添加了IP Header和UDP Headrer，引入IP解决了扩展性问题。

图3 RoCE数据包格式

IB报文格式如下图所示：

在一个子网（Subnet）内部，只有Local Routing Header（LRH），对应OSI的链路层。在子网之间，还有一个Global Routing Header（GRH），对应OSI的网络层。在Routing Header之上，是Transport Header，提供端到端的传输服务，包括数据的分段、重组、确认和流量控制。接着就是报文的数据部分，包含应用层数据或上层协议信息。最后是不变字段和可变字段的循环冗余校验码（CRC），用于检测报文在传输过程中的错误。

图4 IB数据包格式

RoCE与IB网络层级对比

IB与RoCE协议栈在传输层以上是相同的，在链路层与网络层有所区别：

RoCEv1中，以太网替代了IB的链路层(交换机需要支持PFC等流控技术，在物理层保证可靠传输)，然而，由于RoCEv1中使用的是L2 Ethernet网络，依赖于以太网的MAC地址和VLAN标签进行通信，而不涉及网络层（IP层，即OSI模型的第三层）的路由功能，因此，RoCE v1数据包不能实现跨不同的IP子网传输，只能在同一广播域或L2子网内进行传输。

RoCEv2在RoCEv1的基础上，融合以太网网络层，IP又替代了IB的网络层，因此也称为IP routable RoCE，使得RoCE v2协议数据包可以在第3层进行路由，可扩展性更优。

图5 RoCE和IB协议栈对比

物理层

RoCE的物理层基于标准以太网，使用PAM4 (Pulse Amplitude Modulation 4)编码方式和64/66b编码。支持铜缆和光纤，接口有 SFP+、QSFP+ 、OSFP等。支持速率从 10GbE到800GbE。
IB的物理层则是专有的，采用更传统的NRZ(Non-Return-to-Zero)调制技术和64/66b编码。支持铜缆和光纤，接口通常为 QSFP、OSFP，支持速率从 10Gbps 到 400Gbps，并可以通过多通道的组合实现更高的总带宽（如 800Gbps）。

对比来看，IB采用的NRZ每个符号只有两个电平，而RoCE采用的PAM4使用 4个不同的电压电平来表示数据，也就是说RZ信号中，每个周期传输1bit的逻辑信息，PAM4每个周期可以传输2bit的信息，因此在相同的波特率下，PAM4的数据传输速率是NRZ的两倍，具有更高的带宽效率，在支持更高速率（如1.6T，3.2T）时具有潜在的优势。目前，六进制（PAM6）和八进制（PAM8）调制技术正处于实验和测试阶段，而InfiniBand（IB）也在逐渐从传统的NRZ（非归零）调制技术转型至PAM4，例如，400G光模块现已能够同时支持IB和以太网标准。相比之下，以太网在调制技术的应用上展现出更为迅速的发展势头。

图6 频域中 PAM4 与 NRZ 信号的频率内容

链路层

RoCE的链路层是标准以太网，为了在传统以太网上实现无损传输，引入了PFC（Priority-based Flow Control），由IEEE 802.1Qbb标准定义，当交换机的某个优先级队列的缓冲区接近满载时，会发送 PFC帧给上游设备，通知其暂停发送该优先级的流量，防止缓冲区溢出，避免数据包在链路层被丢弃。

此外，以太网引入了ETS(Enhanced Transmission Selection) ，它是DCB (Data Center Bridging)标准的一部分，由 IEEE 802.1Qaz 规范定义。ETS 将流量分配到不同的队列，为每个队列分配一个权重，控制每个流量队列能够使用的带宽百分比，保证高优先级的流量，如RDMA等，获得足够的带宽资源。

IB的链路层是专有的，包头称为Local Routing Header，如图所示。

其中，VL是虚拟通道 (Virtual Lanes)，SL是服务等级 (Service Level)，Source/Destination Local Identifier则是链路层地址。

它内建了对无损传输的支持，这是因为它实现了基于信用的流量控制（Credit-based Flow Control）。接收方在每个链路上提供一个信用值，表示其缓冲区能够接收的数据量。发送方根据此信用值发送数据，确保不会超过接收方的处理能力，从而避免缓冲区溢出和数据丢失。

IB链路层结合SL和VL实现QoS，SL共有16个业务等级，用于标识流量优先级，每个数据包可以根据业务需求被分配到不同的服务等级，通过SL-VL映射，将不同优先级的流量分配到不同的VL上，从而确保高优先级流量（如RDMA）不会因低优先级流量的拥塞而受到影响。

对比而言，IB的链路层由专用硬件实现，效率较高，具有超低时延的特点，而RoCE基于标准以太网硬件，时延稍长。但由于两者都达到了100ns级别，而根据UEC的最新定义，在传输RDMA时，端到端性能要求通常为10μs左右，它们的差别不大。

网络层

RoCE的网络层使用IP，可以是IPv4或IPv6。它采用成熟的BGP/OSPF等路由协议，适应任何网络拓扑并具有快速自愈能力；支持ECN（EXPLICIT CONGESTION NOTIFICATION ），用于端到端的拥塞控制；支持DSCP，替代IB的TRAFFIC CLASS，用于实现QoS。
IB的网络层借鉴了IPv6。Global Routing Header的格式与IPv6完全相同，具有128bit地址，只是字段命名不同。但它没有定义路由协议，而是采用子网管理器（Subnet Manager）来处理路由问题，这是一种集中式的服务器，每个网卡端口和交换芯片都通过由SM分配的唯一身份标识（Local ID，LID）进行识别，不具备互操作性，因此很难快速响应网络的变化。

显然，IB网络层是专有的、集中管理的，而RoCE的网络层基于标准以太网和UDP，在互联网数以十亿计算的设备上使用，技术成熟，并在持续发展中；引入SRv6等技术后，IP进一步增强了流量工程、业务链、灵活性和可扩展性等能力，非常适合组建超大规模可自愈的RDMA网络。

传输层

RoCE

RoCE采用了IB的传输层。RoCEv2协议栈虽然包含UDP，但它仅借用了UDP的封装格式，传输层的连接、重传、拥塞控制等功能由IB传输层完成。UDP层的目的端口固定分配给RDMA协议，源端口则是动态分配的，但在一个连接过程中保持固定。这样可以让网络设备通过源端口区分不同的RDMA数据流。

InfiniBand

IB的传输层采用了模块化的灵活设计，通常包含一个基本传输头BTH（Base Transport Header）和若干个（0到多个）扩展的传输头（Extended Transport Header）。

BTH（Base Transport Header）是InfiniBand传输层头部的一部分。它是InfiniBand网络协议中L4传输层的基本头部，用于描述数据包传输的控制信息。格式如下，

关键信息有：

OpCode，操作码。由8个bit组成。前3个bit代表传输服务类型，如可靠连接/不可靠连接/可靠数据报/不可靠数据报/RAW数据报等。后5个bit代表操作类型，如SEND/READ/WRITE/ACK等。
Destination QP，目的QP号（Queue Pair Number）。与TCP端口号类似，代表了RDMA连接（称为Channel）的目的端。但与TCP端口不同的是，QP由Send/Recv两个队列组成，但用同一个号码标识。
Packet Sequence Number，包序列号，简称PSN。与TCP序列号类似，用于检查数据包的传输顺序。
Partition Key，分区键。可以将一个RDMA网络分为多个逻辑分区。在RoCE中可采用新一代的VxLAN等技术替代。
ECN，显示拥塞通知。用于拥塞控制，包含Forward和Backward两个bit，分别表示在发送和返回路径上遇到了拥塞，在RoCE中被IP头部的ECN替代。

BTH帮助接收方理解该包属于哪个连接以及如何处理接收到的包，包括验证包的顺序、识别操作类型等。

在BTH之后，还有RDMA Extended Transport Header，它包含远端的虚拟地址、密钥和数据长度等信息。格式如下，

其中：

VirtualAddress，虚拟地址，代表目的端内存地址。
DMA Length，直接内存访问长度，是要读写的数据长度，以字节为单位。
Remote Key，用于访问远端内存的密钥。

IB传输层通常由RDMA网卡硬件实现，在IB中称为Channel Adapter（CA），在RoCE中称为RoCE网卡，从而提升RDMA传输的性能。在一些高级的RoCE交换机中，还可以感知IB传输层信息并对RDMA数据流做加速处理。

RDMA操作

借助RDMA扩展头，RoCE和IB的传输层对远程主机的地址进行直接的读写操作（Operation）。

RDMA写操作 (RDMA Write)

在 QP（Queue Pair） 建立后可以直接进行，允许发送方直接写入接收方的内存，不需要接收方的CPU参与，并且无需请求。这种操作方式是 RDMA 高性能和低延迟的核心特性之一。

RDMA Write 是一种单向操作。写入方在写入数据后不需要等待接收方的响应，这种操作与常规的 Send/Receive 模式不同，不需要接收方预先准备接收队列。

RDMA读操作 (RDMA Read)

允许发送方从接收方的内存中读取数据，不需要接收方CPU参与。目标地址和数据大小在发送方指定。如下图所示，在一次请求后，可以通过多次响应返回数据,提高了数据传输效率。

图7 RDMA 读操作

发送/接收操作 (Send/Receive)

这是传统的消息传递操作，数据从发送方传递到接收方的接收队列中，需要接收方预先准备接收队列。

在RoCE中，RDMA跳过操作系统的TCP/IP协议栈，直接与RoCE网卡上的传输层连接，借助DMA机制，直接访问本地和远端内存，实现了零拷贝传输，大幅度提升了性能。

同样，IB网卡在硬件上实现RDMA操作，零拷贝传输，两者的性能相当。

当然，无论在RoCE还是IB中，RDMA 连接的初始化、资源分配、队列对 (QP) 管理、以及一些控制路径上的操作（如连接建立、内存注册等）仍然依赖于软件栈。

应用层

RDMA在数据中心、HPC集群、超级计算机中获得了广泛的应用，用于承载AI训练、推理、分布式存储等数据中心内部的关键业务。

例如，在AI训练/推理时， xCCL或者MPI使用RDMA实现点对点和集合通信；在分布式存储时，NVMEoF, Ceph使用RDMA对网络存储器进行读写操作。

网络层级对比小结

在物理层，RoCE和IB都支持800G，但PAM4相比NRZ具有更强的升级潜力，以太网成本也低于IB，RoCE更胜一筹。
在链路层，两者均实现了无损传输，RoCE的ETS能够为不同优先的流量提供带宽保证，且RoCE和IB的时延均达到了100ns级别，在实际应用中差不大。
在网络层，RoCE借助IP的成熟的持续发展，更能适应大规模网络。
传输层及以上，RoCE和IB使用同样的协议，没有区别。

RoCE与IB的较量，究竟谁更胜一筹

总的来说，RoCE和InfiniBand都由IBTA定义，没有本质的不同。RoCE实际上是将成熟的IB传输层和RDMA移植到了同样成熟的以太网和IP网络上，是一种强强联合，在保持高性能的同时，降低了RDMA网络的成本，能够适应更大规模的网络。

根据亚马逊的高级首席工程师Brian Barrett，AWS之所以放弃IB方案，主要是因为：“云数据中心很多时候是要满足资源调度和共享等一系列弹性部署的需求，专用的IB网络构建的集群如同在汪洋大海中的孤岛”。

出于AI算力建设对于成本和开放性的考量，越来越多的公司已经在使用以太网交换机用于大规模AI算力中心，例如当前全球最大的AI超级集群（xAI Colossus，造价数亿美元、配备十万片NVIDIA H100 GPU），便是采用64 x 800G，51.2T以太网方案构建集群网络。

CX864E-N是星融元专为AI训练、推理、高性能计算（HPC）等场景设计的一款行业内顶尖规格的RoCE交换机，拥有51.2T的超大交换容量，助力客户用更优的投入成本，实现与IB网络相当的性能。

8 x CX864E 支持 512 个 GPU 互连，每个端口速度为 400G
192 x CX864E 支持 8192 GPU 互连，每个端口速度为 400G
192 x CX864E 支持 128k ML/AI 节点互连，每端口速度为 100G

参考文献

https://mp.weixin.qq.com/s/PZ_Q5rS5a5YJlczao9SMXw

https://support.huawei.com/enterprise/zh/doc/EDOC1100203347

https://community.fs.com/cn/article/roce-technology-in-high-performance-computing.html

https://ascentoptics.com/blog/cn/understanding-infiniband-a-comprehensive-guide/

https://blog.csdn.net/jkh920184196/article/details/141461235

https://www.servethehome.com/inside-100000-nvidia-gpu-xai-colossus-cluster-supermicro-helped-build-for-elon-musk/

返回资源中心

近期文章

什么是算力

算力即计算能力（Computing Power），狭义上指对数字问题的运算能力，而广义上指对输入信息处理后实现结果输出的一种能力。虽然处理的内容不同，但处理过程的能力都可抽象为算力。比如人类大脑、手机以及各类服务器对接收到的信息处理实际都属于算力的应用。

随着信息技术的不断发展，《中国算力白皮书（2022）》中将算力明确定义为数据中心的服务器通过对数据进行处理后实现结果输出的一种能力。当前行业中讨论的算力，狭义上可理解为CPU、GPU等芯片的计算能力，广义上可理解为芯片技术的计算能力，内存、硬盘等存储技术的存力，以及操作系统、数据库等软件技术的算法的三者集合。

算力的分类

随着数字经济时代的到来，算力发展迎来高潮，广泛应用于各个领域，其中包括但不限于日常消费领域、人工智能领域、半导体技术领域。不同应用场景对算力的需求各异，需要不同类型的算力支撑。目前算力主要分为通用算力、智能算力和超算算力。未来还会出现比传统计算更高效、更快速的新一代算力，例如量子算力等。

通用算力

通用算力主要以CPU为代表，即CPU芯片执行计算任务时所表现出的计算能力。不同架构的CPU计算能力不同，因为CPU算力受核心数量、主频、缓存大小等多种因素影响。目前可以根据DMIPS指标来衡量CPU性能。该指标表示CPU每秒能执行多少百万条Dhrystone指令。

分类	特点	引领者	优劣势
x86	复杂指令集、单核能力强	Intel、AMD、海光、兆芯	软件生态好，占有率高；指令集实现复杂，功耗高
ARM	精简指令集、追求多核、低功耗	安谋、高通、Amazon	授权厂商多，能效比高；软件生态劣于x86
MIPS	精简指令集、低功耗	龙芯	软件生态弱、市占率正在下降
Power	单核能力强、高可靠性、高成本	IBM	IBM掌控技术，应用于金融领域
RISC-V	精简指令集	RISC-V基金会、阿里巴巴、兆易创新	完全开放开源、模块化、可扩展
Alpha	精简指令集、速度快	申威	软件生态弱，市占率小

通用算力计算量小，但能够提供高效、灵活、通用的计算能力。因为CPU的架构属于少量的高性能核心结构，即核心数量少，但核心频率高，更加擅长处理复杂的逻辑判断和串行计算的单线程任务，如操作系统的管理、应用程序的执行以及各类后台服务等。而这样的设计在面对大规模并行计算任务时则显得力不从心。

智能算力

智能算力主要以GPU、FPGA、ASIC芯片为代表。每种类型的芯片具有各自的特点和优势。

GPU（Graphics Processing Unit，图形处理器）：GPU在设计之初用于图形渲染，即同时处理大量简单的计算任务。不同于CPU的少量高性能核心架构，GPU拥有大量的核心数但较小的控制单元和缓存，能够完成高度并行的计算任务。GPU主要应用在机器学习的训练阶段，因为机器学习的操作并不依赖于复杂指令，而是大规模的并行计算。

FPGA（Field Programmable Gate Array，现场可编程逻辑门阵列）：FPGA是在PAL、GAL 等可编程器件的基础上进一步发展的产物。FPGA是半定制集成电路，具有可重配置的逻辑结构。其内部的电路不是硬刻蚀的，而是可以通过HDL（硬件描述语言）编程来重新配置。这种可编程灵活性使其可以完成人工神经网络的特定计算模式，轻松升级硬件以适应AI场景中新的应用需求。除此以外，FPGA的每个组件功能在重新配置阶段都可以定制，因此在运行时无需指令，可显著降低功耗并提高整体性能。

ASIC（Application-Specific Integrated Circuit，应用特定集成电路）：ASIC是专为满足特定需求而设计的全定制集成电路芯片。ASIC的优势在于其能够针对特定任务进行深度优化，从而实现更高的性能和更低的功耗。一旦量产，其单位成本会显著降低，尤其适合于大规模生产和应用。然而，ASIC设计周期长、成本高，一旦设计完成，很难进行修改或升级以适应新的应用需求。因此，在选择使用ASIC还是FPGA时，需要根据具体的应用场景和需求进行权衡。对于需要高性能、低功耗且应用场景相对固定的系统，ASIC可能是更好的选择；而对于需要快速适应新技术和市场需求变化的应用场景，FPGA则更具优势。

GPU、FPGA、ASIC能力对比表格：

	GPU	FPGA	ASIC
并行计算能力	强大	灵活配置	高效但定制
灵活性	较低（专用于图形和计算）	高（可编程）	低（定制后固定）
功耗	高	适中	低
成本	中等	低	高（设计和制造）
整体性能	高	中等（因可重置而消耗芯片资源）	非常高（高度定制针对性强）
应用领域	图形处理、机器学习等	实时计算、原型设计等	特定应用场景（如数据中心）

超算算力

超算即超级计算，又称高性能计算 (HPC)，利用并行工作的多台计算机系统的集中式计算资源，通过专用的操作系统来处理极端复杂的或数据密集型的问题。超算算力则是由这些超级计算机等高性能计算集群所提供的算力，主要应用于尖端科研、国防军工等大科学、大工程、大系统中，是衡量一个国家或地区科技核心竞争力和综合国力的重要标志。目前，美国的Frontier以 1.206 EFlop/s的HPL性能位居全球超级计算机Top500榜第一，达到了E级计算。

中国信息通信研究院结合业内实践和设想，提出了超算参考架构，由计算系统、存储系统、网络系统、管理系统、安全系统五部分构成。

计算系统：由CPU和异构加速卡计算节点共同组成。
存储系统：采用分布式存储，可提供PB级别以上的容量来进行数据和算据存储。
网络系统：分为存储网络、业务网络以及监控网络等多个网络平面，实现超算系统间各个硬件设备以及子系统间的通信互联。
管理系统：包括资源与业务监控、告警监控、可视化等功能。
安全系统：由防火墙、负载均衡、堡垒机、抗DDoS、日志审计、漏洞扫描、DNS服务器等设备组成。

新一代算力

自人工智能加速应用后，算力需求激增，人们很难保证在未来经典计算能一直满足指数级的算力增长并应用于重大计算问题。于是在全球科技竞争加剧、数字经济快速发展以及新兴技术的推动下出现了以量子计算为代表的新一代算力。

量子计算运用量子态的叠加性，使得量子比特拥有更强的信息编码能力，并可实现多个量子比特的量子纠缠，性能上限远超经典计算。量子计算机使用亚原子粒子的物理学领域来执行复杂的并行计算，从而取代了当今计算机系统中更简单的晶体管。传统计算机中的字符，要么打开，要么关闭，要么是 1，要么是 0。而在量子比特计算中，计算单元是可以打开，关闭或之间的任何值。量子比特的“叠加态”能力，为计算方程增加了强大的功能，使量子计算机在某种数学运算中更胜一筹。

目前阿里巴巴、Google、Honeywell、IBM 、IonQ 和 Xanadu 等少数几家公司都运营着量子计算机，但仍存在退相干、噪声与误差、可扩展性等问题，处于硬件开发的早期阶段。根据专家预测，想要进入量子计算机真正有用的高保真时代，还得需要几十年。

数据中心算力组成

数据中心的计算能力主要依赖于服务器。目前CPU类型的服务器几乎部署在所有的数据中心中，而高性能算力GPU等更多的使用在AI应用场景中，小规模部署于部分数据中心中。然而随着机器学习、人工智能、无人驾驶、工业仿真等新兴技术领域的崛起，传统数据中心遭遇通用CPU在处理海量计算、海量数据时越来越多的性能瓶颈。在数据中心加快步伐部署48核以及64核心等更高核心CPU来应对激增的算力需求的同时，为了应对计算多元化的需求，越来越多的场景开始引入加速芯片，如前文提到的GPU、 FPGA、 ASIC 等。这些加速硬件承担了大部分的新算力需求。

然而实际上的数据中心是一个汇集大量服务器、存储设备及网络设备的基础设施，数据中心算力是服务器、存储及网络设备合力作用的结果，计算、存储及网络传输能力相互协同才能促使数据中心算力水平的提升。单独讨论服务器的算力水平并不能反映数据中心的实际算力水平。

总之，数据中心是人工智能、物联网、区块链等应用服务的重要载体。数据中心算力水平的提升将会在很大程度上推动全社会总体算力供给，满足各行业数字化转型过程中的算力需求。

数据中心网络设备

以实际情况来说，数据中心的算力水平不仅取决于服务器的算力，同时还会在很大程度上受到网络设备的影响，如果网络设备算力水平无法满足要求，很有可能引发“木桶效应”，拉低整个数据中心的实际算力水平。

星融元CX-N系列交换机可以帮助用户构建超低时延、灵活可靠、按需横向扩展的数据中心网络。

超低时延：所搭载的交换芯片具备业界领先的超低时延能力，最低时延达到400ns左右。
高可靠性：通过MC-LAG、EVPN Multihoming、ECMP构建无环路、高可靠、可独立升级的数据中心网络。
RoCEv2能力：全系列标配RoCEv2能力，提供PFC、ECN等一系列面向生产环境的增强网络特性。
RESTful API：支持REST架构的第三方平台和应用都能自动化地管理、调度星融元数据中心网络。

不论是在AI智算还是HPC高性能计算场景下，CX-N交换机都达到了媲美InfiniBand专用交换机的性能，以下是场景测试数据表:

表一：AIGC场景性能测试结果

	带宽	时延	备注
E2E网卡直连	392.95Gb/s	1.95us
E2E跨交换机	392.96Gb/s	2.51us	交换机时延560ns
NCCL网卡直连	371.27GB/s	/
NCCL跨交换机	368.99GB/s	/	CX-N交换机端口利用率95%。

表二：HPC应用测试（对比IB交换机）

HPC应用测试	CX-N交换机				MSB7000
HPC应用	Test1[sec]	Test2[sec]	Test3[sec]	avg[sec]	Test1[sec]	Test2[sec]	Test3[sec]	avg[sec]
WRF	1140.35	1134.64	1128.35	1134.44	1106.72	1099.36	1112.68	1106.25
LAMMPS	341.25	347.19	342.61	343.69	330.47	335.58	332.46	332.83

参考文献：

https://13115299.s21i.faiusr.com/61/1/ABUIABA9GAAgqvv2nAYowLyGBA.pdf

https://13115299.s21i.faiusr.com/61/1/ABUIABA9GAAgk4DrjQYo76ziRQ.pdf

返回资源中心

近期文章

随着AI技术的快速发展，尤其是大模型的训练和推理过程，数据量呈爆炸式增长，这也对底层基础设施提出了更高的要求，网络传输必须朝着更高带宽和更高密度的方向发展以满足需求。800G以太网在400G的基础上进行扩展，提供800Gbps的数据传输速率。

800G以太网优势何在？

高带宽与高速率：提供800Gbps的数据传输速率，远超当前主流网络标准。
高吞吐量和低延迟：显著提升数据传输的吞吐量和降低延迟。当下已推出51.2T交换芯片。
支持高密度与大规模传输：800Gps的传输速率使其能够在有限的物理空间或资源下，有效传输更多的数据，支持更广泛的网络拓扑和大规模部署。

800G以太网的技术解读

如图1所示，800G以太网实际上是一种接口技术，可以支持单个MAC以800Gb/s的速率运行。800G以太网通过集成两个400G PCS实例来实现其高速率传输。这两个400G PCS实例在数据传输过程中协同工作，共同支撑800G的带宽需求。800G-ETC-CR8/KR8规定，800G PMD子层基于IEEE 802.3ck标准的400Gb/s技术，将原来的4个并行通道扩展为8个并行通道。这就将PAM4（四电平调制）和SerDes速度从上一代的50Gbps翻倍至100Gbps，实现了网络的高带宽与高速率。

800G以太网行业现状

目前市场上的800G交换芯片主要有Broadcom Tomahawk 5、Marvell Teralynx 10和Cisco Silicon One G200，NVIDIA Spectrum-4芯片不对外售卖。它们的制作工艺大多基于5nm，吞吐量都为51.2Tb/s，在端口速率配置和一些特色功能上略有不同。比如Broadcom Tomahawk 5芯片更侧重其高效的SerDes设计降低功耗，Marvell Teralynx 10强调其业界超低延迟表现，Cisco Silicon One G200采用P4可编程并行处理器，更加灵活可定制，而NVIDIA Spectrum-4则是专注于AI网络性能的提升。下面附上芯片能力表格以便直观对比。

厂商	Broadcom	Marvell	NVIDIA	Cisco
芯片名称	Tomahawk 5	Teralynx 10	Spectrum-4	Silicon One G200
制程工艺	5nm	5nm	定制4N工艺	5nm
吞吐量	51.2Tb/s	51.2Tb/s	51.2Tb/s	51.2Tb/s
端口速率及配置	64x800Gb/s, 128x400Gb/s, 256x200Gb/s	32x1.6Tb/s, 64x800Gb/s, 128x400Gb/s	"64x800Gb/s （可做两条400Gb/s链路）"	"64x800Gb/s，128x400Gb/s， 256x200Gb/s"
特色功能	高效SerDes设计（借助多达 64 × [PM8x100] SerDes灵活配置端口）	延迟表现低至500纳秒	显著提升AI云网性能	采用P4可编程并行分组处理器，高度灵活可定制

基于这些主流的800G交换芯片已有交换机厂商率先推出800G以太网交换机，例如Arista 7060X5、edgecore AIS800-64D、Cisco Nexus 9232E、星融元Asterfusion CX864E-N等

这代表了网络硬件技术的飞跃，满足高速数据传输需求的同时推动了相关行业应用，但800G以太网技术仍未完善，所有市面上的相关产品仍旧有各自的提升空间和要面临的网络挑战。

800G以太网技术如何破局？

挑战一：误码问题

信号在高速传输的过程中受多种因素影响，例如信号衰减、反射散射和噪声抖动等。这些因素会导致信号质量下降，甚至出现比特错误，即误码。误码率指数据传输中错误比特数与总传输比特数的比例，是数字通信系统中衡量传输质量的关键指标。误码率越高，数据损耗程度越严重。然而在更高速的800G以太网中，常规的信号处理技术不足以解决误码问题，需要更复杂的方式来应对。

解决方案：

更复杂的FEC算法：FEC是一种前向纠错技术，可以在数据传输过程中添加冗余信息，以便在接收端检测和纠正错误。800G以太网目前所有通道均采用 400 Gb/s 标准支持的 RS（544,514）FEC。然而正在开发的下一代800G收发器将使每个通道的速率达到200Gbps，需要更多的冗余数据、更多的纠错机制和更复杂FEC算法来确保数据传输的可靠性。

图3：FEC工作原理

更先进的DSP技术：优化数字信号处理技术，使得DSP芯片对接收到的信号进行更精确的处理，提高信号的质量和稳定性，减少误码的发生。

挑战二：能耗问题

随着数据中心容量和密度的提升，采用传统可插拔光模块方式逐渐遇到一个困难。传统交换芯片与光模块之间有一条较长的电通道，电通道在速率提升时数据损耗越来越大，为了克服通道上的数据损耗，需要在电通道上做复杂信号处理，这些处理会显著增加系统功耗。再加上光模块本身功耗大，尽管已经进行了高效设计，但在大型数据中心中拥有数以万计的光模块，其整体功耗仍是问题。除了光模块外，SerDes的通道数量和单个通道的速率也在不断提升。在800G以太网中，SerDes的速度增加到100Gbps，芯片周围的SerDes通道数量增加到512，这都会导致功耗的上升。

解决方案

CPO光电共封装技术：OFC 2022的Workshops针对高速以太网的功耗问题提到了CPO（Co-packaged Optics）技术。该技术将交换芯片和光引擎共同装配在同一个Socketed（插槽）上，形成芯片和模组的共封装。这样的封装方式显著减小了电通道带来的能耗损失和信号干扰，为800G以太网提供更高的功效。

更高效的SerDes设计：SerDes需要支持更高的速率和更低的功耗，同时保持较小的面积和成本。

图4：CPO技术的电路板组装
优化电路板设计：采用更高效的电路设计和低功耗材料来减少功耗，提高整体能效。

800G以太网的未来

从技术创新的角度来说：交换机和光模块技术不断发展，比如100Gbps SerDes广泛应用，都为800G以太网的实现提供了技术基础，有望在未来几年实现800G以太网的大规模商用。目前一些领先的芯片制造商已经发布了支持1.6T以太网PHY解决方案的产品，这表明800G以太网将向着更高速率迈进。
从行业标准的制定来说：2022年，OIF完成了400ZR标准规范，并正在制定800G LR和ZR的规范，包括光系统参数、FEC算法、DSP技术、OTN映射等技术方面。2023年，IEEE 802.3dj项目中就800G 10km应用是否采用IMDD（强度调制和直接检测）还是其他相关技术进行了讨论。目前，IEEE 802.3正在积极推进800G及1.6T以太网接口的标准化工作。预计在未来两年内，IEEE 802.3、OIF等国际标准组织将陆续完成800G以太网物理层标准的制定，并推动其在实际应用中的开发和验证。
从市场的角度来说：5G 网络、云计算和人工智能等领域快速发展，数据中心对带宽的需求日益增长。800G以太网能够提供更高的带宽和更低的延迟，必定会投入使用，扩大市场规模。再加上目前国内外市场不断有企业在800G通信领域取得显著进展，不难看出800G以太网将成为通信市场的重要增长点。有相关机构预测，到2025年，800G以太网将占数据中心交换机端口的25%以上，表明在未来几年内，800G以太网将实现快速普及。

总结

综上，800G以太网技术是应对未来网络需求的关键解决方案，不断推动数据中心和网络基础设施的升级，满足日益增长的数据传输和处理需求。未来，随着技术的不断进步和市场的扩大，800G以太网有望在未来几年内实现更广泛的商业化和部署。

参考：https://ethernettechnologyconsortium.org/wp-content/uploads/2021/10/Ethernet-Technology-Consortium_800G-Specification_r1.1.pdf

https://bbs.huaweicloud.com/blogs/415694

返回资源中心

云化园区

网络操作系统（SONiC）

可视交换机

开放硬件平台

近期文章

RDMA 网络技术是什么？

主流协议

星融元RoCE无损以太网

如何通过一键RoCE简化配置流程？

如何解决网络拥塞时的性能下降？

应用场景与效果

最新动态

关注星融元

开放网络能否平替IB？

测试背景

测试结论

AI智算场景

HPC 场景

分布式存储场景

HPC集群架构和通信流量特征

HPC网络性能测试方案设计

端到端转发时延测试

MPI基准测试

LinPack基准测试

HPC 应用测试

附录：基础环境配置

关注星融元

什么是超级以太网系统

超以太网协议栈概览

物理层

链路层

传输层：UET，新一代协议栈的核心

选择性重传（Selective Retransmit）

乱序交付（Out-of-Order Delivery）

包喷洒（Packet Spraying）

拥塞控制（Congestion Control）

端到端的安全

在网计算（In Network Collectives）

软件层：Extended Libfabrics 2.0

星融元RoCE交换机与UEC

近期文章

拥塞控制

RoCEv2 的拥塞控制机制

基于优先级的流量控制（PFC）

显式拥塞通知（ECN）

数据中心量化拥塞通知（DCQCN）

InfiniBand 的拥塞控制机制

基于信用的流量控制

端到端拥塞控制

RoCEv2与IB拥塞控制机制比较

QoS

ECMP

RoCE的ECMP

InfiniBand的ECMP

总结

最新动态

近期文章

RoCE与IB网络架构概述

RoCE与IB报文格式对比

RoCE与IB网络层级对比

物理层

链路层

网络层

传输层

RoCE

InfiniBand

RDMA操作

应用层

网络层级对比小结

RoCE与IB的较量，究竟谁更胜一筹

参考文献

最新动态

近期文章

什么是算力

算力的分类

通用算力

智能算力

超算算力

新一代算力

数据中心算力组成