HPC网络发展与RoCE的诞生在早期的高性能计算（HPC）系统中，经常使用一些定制化的网络解决方案，如Myrinet、Quadrics、InfiniBand，代替以太网。这些网络可以摆脱以太网解决方案的设计限制，可以提供更高的带宽、更低的延迟、更好的拥塞控制以及一些独特的功能。IBTA在2010年发布了RoCE（RDMAoverConvergedEthernet）协议技术标准，随后在2014年发布了RoCEv2协议技术标准，带宽也有了很大的提升。以太网性能的大幅提升，使得越来越多的人希望选择与传统以太网兼容的高性能网络解决方案。这也打破了top500上使用以太网的HPC集群越来越少的趋势，以至于以太网仍然占据了top500的半壁江山。虽然现在Myrinet和Quadrics已经死了，但InfiniBand仍然在高性能网络中占有重要地位。此外，克雷自研系列网、天和自研系列网、豆腐D系列网也各有重要地位。RoCE协议简介RoCE协议是一种集群网络通信协议，可以在以太网上进行RDMA（RemoteMemoryDirectAccess）。它将接收/发送数据包的工作卸载到网卡上，不需要像TCP/IP协议那样让系统进入内核态，减少了复制、数据包解包等开销。这样，大大降低了以太网通信的延迟，减少了通信时对CPU资源的占用，缓解了网络中的拥塞，更有效地利用了带宽。RoCE协议有两个版本：RoCEv1和RoCEv2。其中，RoCEv1是链路层协议，因此使用RoCEv1协议通信的双方必须在同一个二层网络；而RoCEv2是网络层协议，因此RoCEv2协议的数据包可以通过三层路由，具有更好的可靠性。可扩展性。RoCEv1协议RoCE协议保留了IB与应用程序、传输层和网络层的接口，用以太网的链路层和网络层代替了IB网络的链路层和物理层。RoCE数据包的链路层数据帧中，Ethertype字段的值被IEEE定义为0x8915，表示这是一个RoCE数据包。但是由于RoCE协议没有继承以太网的网络层，RoCE数据包中没有IP字段，所以RoCE数据包无法通过第三层路由，只能限制数据包的传输到第2层网络中的路由。RoCEv2协议RoCEv2协议对RoCE协议做了一些改进。RoCEv2协议将RoCE协议保留的IB网络层替换为以太网网络层和使用UDP协议的传输层，利用以太网网络层IP数据报中的DSCP和ECN字段实现拥塞控制功能。因此，RoCEv2协议的报文可以路由，具有更好的可扩展性。由于现在RoCEv2协议已经完全替代了有缺陷的RoCE协议，所以人们在提到RoCE协议时，一般都会指代RoCEv2协议。因此，本文提到的所有RoCE协议，除非特别声明为第一代RoCE，均指代RoCEv2协议。无损网络与RoCE拥塞控制机制在使用RoCE协议的网络中，必须实现RoCE流量的无损传输。因为RDMA通信时，数据包必须有序到达，不丢包。如果出现丢包或者乱序到达的数据包，则必须进行go-back-N重传，接收到的数据包后面的数据包不会被缓存。RoCE协议的拥塞控制有两个阶段：使用DCQCN（DatacenterQuantizedCongestionNotification）减速阶段和使用PFC（PriorityFlowControl）暂停传输阶段（虽然严格来说只有前者是拥塞控制策略，后者其实就是Flowcontrolstrategy，不过我习惯把它们看成两个阶段的拥塞控制，后面会写到）。当网络中出现多对一通信的情况时，此时网络往往会发生拥塞，其具体表现是交换机某个端口上要发送的缓冲区报文总大小增加迅速。如果这种情况不加以控制，就会导致缓冲区被填满，从而导致丢包。因此，在第一阶段，当交换机检测到某个端口要发送的缓冲区报文总大小达到某个阈值时，会在RoCE数据包中标记IP层的ECN字段。当接收方收到数据包，发现ECN字段已经被交换机标记后，会向发送方返回一个CNP（CongestionNotificationPacket）数据包，提醒发送方降低发送速度。需要注意的是，ECN字段的标记并不是在达到某个阈值时全部标记，而是有Kmin和Kmax两种，如图2所示，当拥塞队列长度小于Kmin时，不标记被执行。当队列长度在Kmin和Kmax之间时，队列越长，标记概率越大。当队列长度大于Kmax时，全部标记。接收方不会每次收到一个ECN包就返回一个CNP包，但是如果在每个时间间隔内收到一个带有ECN标记的数据包，就会返回一个CNP包。这样，发送方就可以根据收到的CNP报文的数量来调整自己的发送速度。当网络中的拥塞情况进一步恶化，交换机检测到某个端口上待发送队列的长度达到更高的阈值时，交换机将向报文源的上一跳发送PFC暂停控制帧，因此上游服务器或交换机暂停向其发送数据，直到交换机拥塞解除，并向上游发送PFC控制帧通知上游继续发送。由于PFC的流量控制支持根据不同的业务通道进行暂停，当设置了每个业务通道的带宽占总带宽的比例时，可以在不影响其他业务通道的情况下暂停一个业务通道上的流量传输。数据传输。值得一提的是，并不是所有号称支持RoCE的交换机都完美实现了拥塞控制功能。我在测试中发现，当某品牌的交换机产生拥塞时，对于来自不同端口但注入速度相同的流量进行ECN标记的概率是不同的，从而导致负载不均衡的问题。RoCE和Soft-RoCE虽然大多数高性能以太网卡都可以支持RoCE协议，但仍然有一些网卡不支持RoCE协议。为此，IBM、Mellanox等共同创建了开源的Soft-RoCE项目。这样在安装了不支持RoCE协议的网卡的节点上，仍然可以选择使用Soft-RoCE，使其具备使用RoCE协议与安装了网络的节点通信的能力支持RoCE协议的卡，如图3所示。这虽然不会给前者带来性能提升，但却可以让后者充分发挥其性能。在某些场景下，比如数据中心，只能将其高IO存储服务器升级为支持RoCE协议的以太网卡，以提高整体性能和扩展性。同时，这种RoCE和Soft-RoCE的组合也可以满足集群逐步升级的需求，而不是一下子升级。RoCE应用于HPC的问题HPC网络的核心需求我认为HPC网络有两个核心需求：①低延迟；②在快速变化的流量模式下保持低延迟。对于①低延迟，RoCE就是用来解决这个问题的。如前所述，RoCE通过将网络操作卸载到网卡来实现低延迟并降低CPU使用率。对于②，在快速变化的流量模式下保持低延迟的能力实际上是一个拥塞控制问题。但关键是HPC的流量模式变化很快，而RoCE并不擅长这个问题。RoCE的低延迟真机测试RoCE的延迟有幸有机会与IB的实测进行对比：以太网采用25GMellanoxConnectX-4Lx以太网卡，MellanoxSN2410交换机；IB使用100GInfiniBandEDR网卡（MellanoxConnectX-4），MellanoxCS7520。测试中，以太网交换机放置在机架顶部，IB交换机放置在较远的机柜中。因此，由于电缆的实际长度，IB交换机略有劣势。测试使用OSUMicro-Benchmarks中的osu_latency对IB、RoCE、TCP协议进行延迟测试，结果如下。虽然IB用的是100G，RoCE用的是25G，但是这里关心的是延迟，这个应该无所谓。可以看出，虽然RoCE协议确实可以大大降低通信延迟，比TCP快5倍左右，但仍然比IB慢了47%-63%。官方论文数据中使用的以太网交换机SN2410的官方延迟数据为300ns。虽然没有找到IB开关CS7520的官方延迟数据，但是找到了同样是EDR开关的SB7800的官方数据，延迟是90ns。不过以上都是近两年的一些旧设备。较新的Mellanox以太网交换机SN3000系列200G以太网交换机官方延迟数据为425ns。更新后的MellanoxSN4000系列400G以太网交换机在官方文档中没有发现延迟。数据。较新的MellanoxIB交换机QM8700系列HDR交换机官方延迟数据为130ns，而最新的QM9700系列NDR交换机在官方文档中没有找到延迟数据。（不知道为什么新一代的延迟比老的大一点，最新一代的延迟还没出。）定制网络的CrayXC系列Ariesswitch的延迟大概是100ns，天河二号A的开关机延时在100ns左右。100纳秒。可以看出，在交换机实现上，以太网交换机和IB交换机的时延性能与一些定制的超算网络还有一定的差距。RoCE的数据包结构假设我们要使用RoCE发送1个字节的数据。此时，封装这个1字节数据包的额外开销如下：以太网链路层：14字节MAC头+4字节CRC以太网IP层：20字节以太网UDP层：8字节IB传输层：12字节BaseTransportHeader(BTH)Total:58bytes假设我们要用IB发送1个字节的数据，那么我们需要额外付出封装这1个字节的数据包开销如下：IB链路层：8bytesLocalRoutingHeader(LHR)+6byteCRCIB网络层：0bytes当只有二层网络时，链路层LinkNextHeader(LNH)字段可以表示数据包没有网络层IBTransportlayer:12bytesBaseTransportHeader(BTH))total:26bytes如果是定制的网络，数据包的结构可以做得更简单。例如，天河一号A的Mini-packet（MP）包头有8个字节。由此可见，以太网厚重的底层结构也是RoCE应用于HPC的障碍之一。数据中心的以太网交换机往往还有很多其他的功能，需要大量的成本来实现，比如SDN、QoS等，我不是很了解。关于这个以太网的这些特性，我想知道：以太网管脚的这些功能是否兼容RoCE，这些功能是否会影响RoCE的性能？RoCE拥塞控制中的问题RoCE协议的两阶段拥塞控制存在一定的问题，在快速变化的流量模式下可能难以保持低延迟。PFC（PriorityFlowControl）的使用使用暂停控制帧来防止接收到过多的数据包而导致丢包。与基于信用的方法相比，这种方法不可避免地具有较低的缓冲区利用率。对于一些低延迟的交换机，缓冲区会比较小。这时候PFC（PriorityFlowControl）不好控制；如果使用信用基础，可以实现更精确的管理。与IB的拥塞控制相比，DCQCN其实是类似的，都是后向通知：先向目的地发送拥塞信息，然后再将拥塞信息返回给发送方，再进行限速。但细节上略有不同：RoCE的减速和减速策略是根据论文CongestionControlforLarge-ScaleRDMADeployments设置的一套固定公式；而IB的减速和减速策略可以自定义；虽然大多数人其实应该使用默认配置，但是有一个自由度总比没有好。还有一点，本文的测试是每N=50us最多生成一个CNP包。不知道这个值是不是改小了。我要对应的最小CCTI_Timer是1.024us。不知道实际能不能设置这么小。当然，最好的方式是直接从拥塞点直接向源头返回拥塞信息，即Forwardnotification。以太网受规范限制不做这个可以理解，但是IB为什么不做呢？RoCE在HPCSlingshot上的应用案例美国新的三大超级计算机都将使用Slingshot网络，这是一种改进的以太网。Rosetta交换机在兼容传统以太网的同时，也改进了RoCE的一些不足。如果一条链路的两端都是支持的设备（专用网卡，Rosetta交换机），可以启用一些增强功能：将IP数据包的最小帧大小减小到32字节，相邻交换机的队列占用率（credit）将bepropagenttoAdjacentswitches有更多的nb拥塞控制，但是如何实现在论文中没有详细说明。最终效果是交换机的平均延迟为350ns，已经达到了强以太网交换机的水平，但是没有IB和一些定制。超算交换机延迟低，不及上一代CrayXC超算交换机低。但是在实际应用中表现似乎还可以，但是这篇论文AnIn-DepthAnalysisoftheSlingshotInterconnect似乎是和上一代Cray超算比较的，而不是和IB比较的。CESM和GROMACS测试我还用之前测试过的25G以太网和100G测试了CESM和GROMACS来比较应用程序的性能。虽然两者的带宽相差4倍，但也有一点参考价值。GROMACS测试结果是预期的。如果有人能用100G或200GIB和以太网的大规模集群来比较两者的性能差距，其实就能说明很多问题，只是成本太高了。找出在哪里做过这样的实验。小结与结论RoCE应用于HPC在我看来存在以下问题：以太网交换机的延迟高于IB交换机和一些HPC定制网络的交换机。RoCE的流量控制和拥塞控制策略还有一定的改进空间。网络交换机的成本还是比较高的，但是从实测的性能来看，在小规模的情况下，性能不会有问题。但是大规模的，没有人测试过，所以不知道。虽然Slingshot的新超级计算机即将问世，但毕竟是改造过的，严格来说感觉不像以太网。但是从他们的魔改来看，他们似乎也觉得直接应用RoCE有问题，只有魔改之后才能使用。参考资料https://en.wikipedia.org/wiki/Myrinethttps://en.wikipedia.org/wiki/Quadrics_(company)https://www.nextplatform.com/2021/07/07/the-eternal-battle-between-infiniband-and-ethernet-in-hpc/论百亿亿级HPC系统中商用以太网技术的使用https://network.nvidia.com/pdf/prod_eth_switches/PB_SN2410.pdfInfiniband架构规范1.2.1天河一号A互连和消息-传递服务https://fasionchan.com/network/ethernet/大规模RDMA部署的拥塞控制对Slingshot互连的深入分析
