外平台均指代RoCEv2协议

2023-06-04 14:55
Admin

　　外平台均指代RoCE v2协议正在当年的高功能推算(HPC)编制中，往往会采用少许定制的汇集治理计划，比如：Myrinet、Quadrics、InfiniBand，而不是以太网。这些汇集能够离开以太网计划正在计划上的束缚，能够供应更高的带宽、更低的延迟、更好的堵塞限度、以及少许特有的成效。

　　IBTA正在2010年发外了RoCE(RDMA over Converged Ethernet)合同时间规范，随后又正在2014年发外了RoCEv2合同时间规范，同时带宽上也有大幅晋升。以太网功能的大幅晋升，使越来越众的人念要选拔能兼容古代以太网的高功能汇集治理计划。这也冲破了top500上应用以太网的HPC集群数目越来越少的趋向，使以太网现正在照旧占领top500的半壁山河。

　　固然现正在Myrinet、Quadrics仍然没落，但InfiniBand照旧攻陷着高功能汇集中紧急的一席之地，此外Cray自研系列汇集，银河自研系列汇集，Tofu D系列汇集也有着其紧急的位置。

　　RoCE合同是一种能正在以太网长进行RDMA（长途内存直接拜望）的集群汇集通讯合同。它将收/发包的任务卸载(offload)到了网卡上，不需求像TCP/IP合同相似使编制进入内核态，节减了拷贝、封包解包等等的开销。如此大大下降了以太网通讯的延迟，节减了通信时对CPU资源的占用，缓解了汇集中的堵塞，让带宽获得更有用的行使。

　　RoCE合同有两个版本：RoCE v1和RoCE v2。个中RoCE v1是链途层合同，因此应用RoCEv1合同通讯的两边务必正在统一个二层汇集内；而RoCE v2是汇集层合同，因而RoCE v2合同的包能够被三层途由，具有更好的可扩展性。

　　RoCE合同保存了IB与运用圭臬的接口、传输层和汇集层，将IB网的链途层和物理层更换为以太网的链途层和汇集层。正在RoCE数据包链途层数据帧中，Ethertype字段值被IEEE界说为了0x8915，来解释这是一个RoCE数据包。不过因为RoCE合同没有接受以太网的汇集层，正在RoCE数据包中并没有IP字段，因而RoCE数据包不行被三层途由，数据包的传输只可被限制正在一个二层汇集中途由。

　　RoCE v2合同对RoCE合同实行了少许刷新。RoCEv2合同将RoCE合同保存的IB汇集层局部更换为了以太网汇集层和应用UDP合同的传输层，而且行使以太网汇集层IP数据报中的DSCP和ECN字段达成了堵塞限度的成效。因而RoCE v2合同的包能够被途由，具有更好的可扩展性。因为RoCE v2合同现正在仍然所有庖代存正在缺陷的RoCE合同，人们正在提到RoCE合同时凡是也指的是RoCE v2合同，故本文中接下来提到的扫数RoCE合同，除非出格声明为第一代RoCE，均指代RoCE v2合同。

　　正在应用RoCE合同的汇集中，必必要达成RoCE流量的无损传输。由于正在实行RDMA通讯时，数据包务必无丢包地、按依次地达到，假使涌现丢包或者包乱序达到的景况，则必必要实行go-back-N重传，而且巴望收到的数据包后面的数据包不会被缓存。

　　RoCE合同的堵塞限度共有两个阶段：应用DCQCN(Datacenter Quantized Congestion Notification)实行减速的阶段和应用PFC(Priority Flow Control)暂停传输的阶段（固然端庄来说惟有前者是堵塞限度战略，后者实在是流量限度战略，不过我习气把它们算作堵塞限度的两个阶段，后文中也这会这么写）。

　　当正在汇集中存正在众对一通讯的景况时，这时汇集中往往就会涌现堵塞，其整体阐扬是换取机某一个端口的待发送缓冲区信息的总巨细急迅拉长。假使景况得不到限度，将会导致缓冲区被填满，从而导致丢包。因而，正在第一个阶段，当换取机检测到某个端口的待发送缓冲区信息的总巨细到达必定的阈值时，就会将RoCE数据包中IP层的ECN字段实行标识。当接管方接管到这个数据包，创造ECN字段仍然被换取机标识了，就会返回一个CNP(Congestion Notification Packet)包给发送方，指引发送方下降发送速率。

　　需求出格注视的是，对付ECN字段的标识并不是到达一个阈值就一概标识，而是存正在两个Kmin和Kmax，如图2所示，当堵塞部队长度小于Kmin时，不实行标识。当部队长度位于Kmin和Kmax之间时，部队越长，标识概率越大。当部队长度大于Kmax时，则一概标识。而接管方不会每收到一个ECN包就返回一个CNP包，而是正在每一个岁月间隔内，假使收到了带有ECN标识的数据包，就会返回一个CNP包。如此，发送方就能够按照收到的CNP包的数目来调治本身的发送速率。

　　当汇集中的堵塞景况进一步恶化时，换取机检测到某个端口的待发送部队长度到达一个更高的阈值时，换取机将向信息开头的上一跳发送PFC的暂停限度帧，使上逛任职器或者换取机暂停向其发送数据，直到换取机中的堵塞获得缓解的时期，向上逛发送一个PFC限度帧来闭照上有赓续发送。因为PFC的流量限度是声援按分别的流量通道实行暂停的，因而，当筑树好了每个流量通道带宽占总带宽的比例，能够一个流量通道上的流量传输暂停，并不影响其他流量通道上的数据传输。

　　值得一提的是，并不是每一款声称声援RoCE的换取机都圆满的达成了堵塞限度的成效。正在我的测试中，创造了某品牌的某款换取机的正在形成堵塞时，对来自分别端口但注入速率沟通的流量实行ECN标识时概率分别，导致了负载不屈衡的题目。

　　固然现正在大局部的高功能以太网卡都能声援RoCE合同，不过照旧有少许网卡不声援RoCE合同。因而IBM、Mellanox等联手创筑了开源的Soft-RoCE项目。如此，正在装置了不声援RoCE合同的网卡的节点上，照旧能够选拔应用Soft-RoCE，使其具备了能与装置了声援RoCE合同的网卡的节点应用RoCE合同实行通讯的才气，如图3所示。固然这并不会给前者带来功能晋升，不过让后者也许充满阐扬其功能。正在少许场景下，譬喻：数据核心，能够只将其高IO存储任职器升级为声援RoCE合同的以太网卡，以进步完全功能和可扩展性。同时这种RoCE和Soft-RoCE团结的措施也能够满意集群逐渐升级的需求，而不消一次性一概升级。

　　我以为HPC汇集的焦点需求有两个：①低延迟；②正在急迅转移的流量形式下照旧能维系低延迟。

　　对付①低延迟，RoCE即是用来治理这个题目的。如前面提到的，RoCE通过将汇集操作卸载到网卡上，达成了低延迟，也节减了CPU的占用。

　　对付②正在急迅转移的流量形式下照旧能维系低延迟，实在即是堵塞限度的题目。不过要害正在于HPC的流量形式是急迅转移的，而RoCE正在这个题目上阐扬是欠佳的。

　　固然IB用的是100G的，RoCE用的是25G的，不过这里咱们体贴的是延迟，应当没相闭系。

　　能够看出，固然RoCE合同确实能大幅下降通讯延迟，比TCP速了5倍驾驭，但照旧比IB慢了47%-63%。

　　上面用到的以太网换取机SN2410的官方延迟数据是300ns，固然IB换取机CS7520没找到官方延迟数据，只是找到了同为EDR换取机的SB7800的官方数据，延迟为90ns。

　　只是上面这些是有些旧的前两年的开发了，新一点的Mellanox以太网换取机SN3000系列的200G以太网换取机官方延迟数据是425ns，更新的Mellanox SN4000系列400G以太网换取机，正在官方文档没有找到延迟数据。新一点的Mellanox IB换取机QM8700系列HDR换取机的官方延迟数据是130ns，最新的QM9700系列NDR换取机，正在官方文档中也没有找到延迟数据。（不知晓为啥都是新一代的比旧的延迟还大一点，并且最新一代的延迟都没放出来）

　　定制汇集的Cray XC系列Aries换取机延迟大约是100ns，银河-2A的换取机延迟也大约是100ns。

　　可睹正在换取机达成上，以太网换取机与IB换取机以及少许定制的超算汇集的延迟功能仍旧有必定差异的。

　　假设咱们要应用RoCE发送1 byte的数据，这时为了封装这1 byte的数据包要异常付出的价格如下：

　　假设咱们要应用IB发送1 byte的数据，这时为了封装这1 byte的数据包要异常付出的价格如下：

　　假使是定制的汇集，数据包的构造能够做到更简陋，譬喻银河-1A的Mini-packet (MP)的包头是有8 bytes。

　　由此可睹，以太网重重的底层构造也是将RoCE运用到HPC的一个反对之一。

　　数据核心的以太网换取机往往还要具备很众其他成效，还要付出很众本钱来实行达成，譬喻SDN、QoS等等，这一块我也不是很懂。

　　对付这个以太网的这些features，我挺念知晓：以太网针这些成效与RoCE兼容吗，这些成效会对RoCE的功能形成影响吗？

　　RoCE合同的两段堵塞限度都存正在必定的题目，大概难以正在急迅转移的流量形式下照旧能维系低延迟。

　　采用PFC(Priority Flow Control)采用的是暂停限度帧来制止接管到过众的数据包从而惹起丢包。这种措施比起credit-based的措施，buffer的行使率不免要低少许。由其对付少许延迟较低的换取机，buffer会相对较少，此时用PFC(Priority Flow Control)就欠好限度；而假使用credit-base则能够达成尤其切确的处置。

　　DCQCN与IB的堵塞限度比拟，实在大同小异，都是backward notification：通过通过先要将堵塞讯息发送到宗旨地，然后再将堵塞讯息返回到发送方，再实行限速。不过正在细节上略有分别：RoCE的降速与提速战略按照论文Congestion Control for Large-Scale RDMA Deployments，是固定死的一套公式；而IB中的能够自界说提速与降速战略；固然大局部人应当实质上应当都用的是默认设备，不过有自正在度总好过没有叭。尚有一点是，正在这篇论文中测试的是每N=50us最众形成一个CNP包，不知晓假使这个值改小行弗成；而IB中念对应的CCTI_Timer最小可认为1.024us，也不知晓实质能不行筑树这么小。

　　最好的措施当然仍旧直接从堵塞处直接返回堵塞讯息给源，即Forward notification。以太网受限于类型不这么干能够领略，不过IB为啥不这么干呢？

　　美邦的新三大超算都打算用Slingshot汇集，这是一个刷新的以太网，个中的Rosetta换取机兼容古代的以太网同时还对RoCE的少许不够实行了刷新，假使一条链途的两头都是声援的开发（专用网卡、Rosetta换取机）就能够开启少许加强成效：

　　结果到达的恶果是换取机均匀延迟是350ns，到达了较强的以太网换取机的程度，不过还没没有IB以及少许定制超算换取机延迟低，也没有前一代的Cray XC超算换取机延迟低。

　　我也用前面测试延迟的25G以太网和100G测了CESM与GROMACS来对照了运用的功能。固然两者之间带宽差了4倍，不过也有一点点参考价钱。