高性能计算：RoCE技术分析及应用( 三 ) _RoCE

假设我们要使用IB发送1 byte的数据，这时为了封装这1 byte的数据包要额外付出的代价如下：

IB链路层：8 bytes Local Routing Header(LHR) + 6 byte CRC
IB网络层：0 bytes 当只有二层网络时，链路层Link Next Header (LNH)字段可以指示该包没有网络层
IB传输层：12 bytes Base Transport Header (BTH)

总计：26 bytes
如果是定制的网络，数据包的结构可以做到更简单，比如天河-1A的Mini-packet (MP)的包头是有8 bytes 。

由此可见，以太网繁重的底层结构也是将RoCE应用到HPC的一个阻碍之一。

数据中心的以太网交换机往往还要具备许多其他功能，还要付出许多成本来进行实现，比如SDN、QoS等等，这一块我也不是很懂。

对于这个以太网的这些features，我挺想知道：以太网针这些功能与RoCE兼容吗，这些功能会对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为啥不这么干呢？
RoCE在HPC上的应用案例
Slingshot
美国的新三大超算都准备用Slingshot网络，这是一个改进的以太网，其中的Rosetta交换机兼容传统的以太网同时还对RoCE的一些不足进行了改进，如果一条链路的两端都是支持的设备（专用网卡、Rosetta交换机）就可以开启一些增强功能：

将IP数据包最小帧大小减小到32 bytes
相邻交换机的排队占用情况(credit)会传播给相邻的交换机
更加nb的拥塞控制，但是具体怎么实现的论文里没细说

最后达到的效果是交换机平均延迟是350ns，达到了较强的以太网交换机的水平，但是还没没有IB以及一些定制超算交换机延迟低，也没有前一代的Cray XC超算交换机延迟低。

但是在实际应用的表现似乎还行，但是论文An In-Depth Analysis of the Slingshot Interconnect中似乎只是和前一代的Cray超算比，没有和IB比。
CESM与GROMACS测试
我也用前面测试延迟的25G以太网和100G测了CESM与GROMACS来对比了应用的性能。虽然两者之间带宽差了4倍，但是也有一点点参考价值。