RDMA over Commodity Ethernet at scale

改进PFC

dead lock 过去的PFC基于2层的协议VLAN，在以太网帧中夹带VLAN TAG来表示优先级。这会带来两个问题。

  1. 必须使用trunk模式的端口。操作系统的一些支持服务比如安装升级命令就很难使用，二数据中心中的自动化管理如他们的PXE就没办法用了。
  2. 难以转成3层的IP转发而不是继续用mac的二层桥接。3层网络可以有更好的扩展性，监控，公开而且标准等特性。但这将导致在跨子网的时候无法继续使用VLAN。

解决方案：PFC报文不变，在IP报文中新增字段DSCP来取代VLAN TAG，来完成包的优先级的功能。

安全性挑战

RDMA传输活锁 livelock

livelock， 链接一直在传东西，但是实际上完全没成功传过去。

实验： 每次传一个4MB(4000个包)，设定每隔256个丢一个包(seq&0xff == 0xff)，即丢包率1/256.这个时候假设从0开始传，那个第256个包就会丢，然后需要从0开始重传。然后在256继续丢。

原因： RDMA使用的是go back 0算法来进行重传。因为假设极少丢包，使用goback0可以不需要管理那么多的状态。

解决方法： 改成go back N。从丢掉的那个包开始重传。同样简单，而且不会死锁。

PFC死锁

dead lock 图片里面S1尝试发送紫色包到S3，黑色包到S5. 而S4打算发送蓝色包到S2. S2和S3挂掉了，S5对应的对口T1.p2拥堵状态。

s1的包经过T0.p0,T0.p2, La.P0,La.P1到达T1.p3, 这个时候T1上S3的MAC地址已经没了，ARP还在，那么就会洪泛这个包。这个时候p3仍然不会删掉紫色包，直到他去到队列头。而黑色包因为拥挤的T1.p2而无法转发过去。因此T1.p3,La.p1,La.p0,T0.p2,To.p0,S1都会被PFC暂停发包。

而S4发的包同样地经过T1.p1,T1.p4, Lb.p1, Lb.p0到达T0.p3，而S2的记录没了，洪泛蓝色包，发现T0.p2无法转发，触发PFC，暂停掉T0.p3,Lb.p0,Lb.p1,T1.p4,T1.p1,S4.

这个时候死循环形成即使S5的包都拿走了，也没办法解决。因为T1.p4包含的紫色包没有释放，T1.p3的紫色包不会被丢弃。因此死锁会持续

主要原因是PFC和ARP的交互。交换机里ARP的记录存活时间是4小时，而MAC表的是5分钟，因此存在一种可能就是ARP表能找到，但MAC表里面没有。默认的行为里，交换机会进行洪泛，来找对应的机器。而如果有port拥挤或者说是被暂停了的话，这个传输路径的端口都会被暂停。就像图里的两条反向路径，互相锁死。即使后来拥挤解除，端口的死锁也已经解不开了。

解决方法: 找到ARP但找不到MAC就丢掉，这样就不需要洪泛来查找，被其他无关端口停住。

(opt)统一存活时间会带来额外的开销，卸载到cpu同理

找不到ARP也会洪泛？

不会，那说明机器就关了，不需要找。。。

NIC PFC暂停帧风暴

起因是网卡接收端流水线出了个bug，但是后来修正了。但是提出了两个预防措施。

NIC PFC暂停帧风暴指的是一个网卡使用PFC暂停了整个网络。

  1. 网卡端，发现流水线停住一段时间（100ms）就关掉无损模式，不再发出PFC帧，开始丢包。因为他们发现这时网卡一般就不能用了。
  2. 交换机端，发现有端口无法清空，而且不停进来PFC帧就把端口的无损模式关掉，直到一段时间（200ms）不在收到PFC帧,再打开。因为网卡可能被重置了。
  3. 一起用也没关系，网卡会丢报的。不会影响网络。

接收端过慢

因为接收端有一个MTT存储vpn2ppn的映射，没命中的时候就需要替换。而他只有2K，默认4KB的页而言只能处理8MB的内存。替换和获取新的虚拟地址都需要时间。接受流水会受到很大的影响。

进而会导致很多的PFC暂停帧出现。只是没有风暴那么严重，但对网络的性能还是会有影响。

缓解办法

  1. 大页
  2. 交换机动态buffer共享

RDMA的管理和测量

记录每个时间段的包数量，byte总数，PFC数量等用来监控集群状态。

建立一个RDMA的Pingmesh用来动态监测集群的延迟变化，发512byte的包到交换机和服务器来测。

延迟和带宽

在他们的数据中心上，总体的延迟状态对比，尾延迟大幅降低。

用一个三层的576台服务器来测试带宽，podset和spine之间的带宽能到到2.56Tb/s.而ToR之间贷款为3.0Tb/s这大概是总带宽的60%。（说是因为ECMP的哈希碰撞，不是很懂）

用一个两层的24台服务器来测试，维持每台服务器7Gb/s的带宽，测试集群中的延迟，发现集群的RDMA延迟从99th的50us，99.9th的80us上升到400us和800us。而这里tcp的99th延迟大概是500us。随着带宽增大，延迟会上升。

配置相关

其他主要是一些配置细节，效果很好，问题都避免了。 不是很懂。。。没有实感。

参考资料