本文主要解决的问题是在RoCEv2体系中，基于VLAN的PFC的拥塞控制是逐跳工作的，源和目的服务器之间可能有多跳，如果有持续的网络拥塞，PFC暂停帧会从阻塞点传播并返回到源，这就会导致诸如unfairness和victim flow的问题。因此作者提出了基于DSCP的优先级流量控制机制PFC，替换掉PCP和VID来确保大规模部署。

 

Abstract

       在过去一年半的时间，我们已经使用RoCEv2来支持一些微软高可靠性、延迟敏感的服务。本篇论文讲述了在此过程中遇到的挑战以及解决方案。为了把RoCEv2扩展到VLAN之外，我们设计了一个基于DSCP的优先级流量控制机制（PFC）来确保大规模部署。我们已经解决了很多安全挑战，比如PFC-减少死锁、RDMA传输livelock以及NIC PFC暂停帧风暴问题。我们也建立了监控和管理系统来确保RDMA按照预期的方式工作运行。我们的经验表明，大规模运行RoCEv2的安全和可扩展问题都可以被解决，RDMA可以代替TCP进行内部数据中心通信，并且可以实现低延迟、低CPU开销、高吞吐量。传统TCP/IP仍然占据主导地位，但是不能满足新一代DC工作负载的需求，有两个原因：传统TCP/IP的CPU负载太高，传统TCP/IP延迟太高。

1. Introduction

       随着在线服务和云计算的快速增长，大规模数据中心（DC）正在世界范围内建立。 连接DC中的服务器需要高速，可扩展的数据中心网络（DCN）[1、3、19、31]。 DCN的建立需要商用交换机和网卡（NIC）。 最先进的DCN必须支持DC中任何两个服务器之间Gb/s或更高的吞吐量。

       在当今的数据中心网络中，TCP / IP仍然是主要的传输/网络堆栈。 但是，越来越明显的是，传统的TCP / IP堆栈不能满足新一代DC工作负载的需求[4、9、16、40]，这有两个原因。

       OS内核中的数据包操作带来的CPU开销仍然很高，尽管做了很多硬件和软件上的优化，比如卸载校验和、LSO、RSS和适度中断。在我们数据中心中的测量结果显示，一个32核Intel Xeon E5-2690 Windows 2012R2 服务器用8个TCP连接以40Gb/s发送chew up6% 聚合CPU时间。使用8个TCP连接到达40Gb/s需要12%聚合的CPU时间，现代的数据中心是无法忍受这种高CPU开销的。

       许多当代DC应用，比如Search，对网络延迟都是高度灵敏的。TCP不能提供需要的低延迟，即使平均流量负载是适当的，有两个原因。第一，内核软件产生的延迟有几十毫秒；第二，由于网络拥塞，会有数据丢包现象出现，尽管很少，但并没有在我们的数据中心中消失，这时因为数据中心固有的突发性。TCP通过超时或者快速重传来恢复正常，而这两种情况中，都有很大的延迟。

       在本文中，我们总结了我们在部署RoCEv2（融合以太网v2上的RDMA）[5]（一种RDMA（远程直接内存访问）技术[6]）方面的经验，以解决Microsoft数据中心中的上述问题。 RDMA是一种在不中断CPU操作的前提下可以访问远程系统的方法。 RDMA广泛应用于高性能计算中，以Infiniband为架构，RoCEv2支持RDMA实现在以太网上，而不是Infiniband。 

       与TCP不同，RDMA需要无损网络。 也就是说由于交换机上的缓冲区溢出，必须没有数据包丢失。 RoCEv2为此使用PFC（基于优先级的流量控制）[14]。 当缓冲区占用超过指定阈值时，PFC通过暂停上游发送实体来防止缓冲区溢出。 虽然PFC的一些问题（例如行首阻塞和潜在的死锁）是众所周知的[22，33]，但我们看到了一些问题，例如RDMA传输实时锁定，NIC PFC pause frame storm和slow- receiver symptom。 甚至我们遇到的死锁问题的根本原因也与研究文献中经常讨论的示例完全不同[22，33]。

       我们注意到，VLAN标签被典型用于鉴别混合RDMA/TCP部署中的支持PFC的流量。我们将讨论，这种解决方案不会出现在我们的环境中。因此。我们提出了基于PFC的DSCP（Differentiated Services Code Point）概念，把RDMA从二层VLAN扩展到三层IP。

       我们的RDMA部署已经平稳运行了一年半，它支持Microsoft的一些高度可靠且对延迟敏感的在线服务。 我们的经验表明，通过改进RoCEv2的设计，解决各种安全问题以及构建所需的管理和监视功能，我们可以使用商用以太网在大型数据中心安全地部署RDMA。

2. Background

       我们的数据中心网络是一个基于以太网的多层Clos网络。20-40个服务器连接到一个top-of-rack（ToR，顶层机架）交换机，数十个ToR连接到叶子交换机层。叶子交换机反过来连接到数十到上百个Spine交换机层上。大多数链路是40Gb/s，我们计划在不久的将来更新到50GbE和100GbE，所有的交换机都是使用IP路由。

       服务器和使用大约2米的铜电缆连接到ToR交换机，ToR交换机和叶子交换机之间有10-20米的距离，leaf和spine交换机之间有200-300米。三层交换机将数以万计的服务器连接到一个数据中心，本篇论文中，我们的关注点是同一个spine交换机层下的若干服务器之间的支持RDMA。

       RoCEv2：部署RoCEv2是基于技术和经济的两个原因。RoCEv2在一个Ethernet/IPv4/UDP数据包中解封装一个RDMA传输包，使得RoCEv2和我们线程的网络基础设施相兼容，基于ECMP的多路径路由需要UDP头部，目的UDP端口通常设置为4791，源UDP端口对每个QP是随机选择的。中间交换机使用标准的五元组哈希。因此，属于同一个QP的流量有相同的路径，而不同QP中的流量可以有不同的路径（甚至在同一对通信终端之间）。

       PFC and buffer 保留：RoCEv2使用PFC来防止缓冲区溢出。PFC标准指定了8个优先级种类，来减少head-of-line阻塞问题。但是，在我们的网络中，RDMA只能使用8个中的两个优先级。原因如下：

       PFC是一个在两个以太网节点之间的逐跳协议。发送者的egress port把数据发送到接收者的ingress port，发送端口把数据包放到最多8个队列中进行排队，每个队列对应一个优先级，接收端口把数据包缓存到对应的接收队列中。在我们网络中使用的共享缓冲区的交换机中，一个接收队列被作为一个counter简单地实现，所有的数据包共享一个通用的buffer池。

       一旦接收队列的长度达到了一定阈值（XOFF），交换机会发送PFC暂停帧到对应的上流egress queue。在egress队列接收到暂停帧的时候，就会停止发送数据包。暂停帧中包含了需要暂停的优先级队列和暂停时间。一旦接收队列的长度小于另一个阈值（XON），交换机会发送一个0持续时间的暂停帧给egress queue来恢复传输。XOFF的值必须能够保证没有buffer overflow，XON来保证没有缓冲区buffer underflow。（overflow表示缓冲区已满，不能再写入了，underflow表示缓冲区空的，不能读取数据）。 

       传播时延取决于发送者和接收者之间的距离。在我们的网络环境中，二者的距离最大是300米。ToR和leaf交换机有shallow buffers（9MB或者12MB），我们只能给两个无损的流量类别预留充足的headroom，即使交换机支持8个流量类别。一个无损类别进行实时流量，另一个无损类别进行批量数据传输。

       传播延迟取决于发送方和接收方之间的距离。 在我们的网络中，这可能长达300米。 鉴于我们的ToR和Leaf交换机具有较浅的缓冲区（9MB或12MB），即使这些交换机支持八个流量类别，我们也只能为两个无损流量类别保留足够的净空。 我们将一种无损类用于实时流量，将另一类用于批量数据传输。

       Need for congestion control：PFC是逐跳工作的，源和目的服务器之间可能有多跳，如果有持续的网络拥塞，PFC暂停帧会从阻塞点传播并返回到源，这就会导致诸如unfairness和victim flow的问题。

       为了减少这些额外的问题，包括QCN、DCQCN和TIMELY在内的基于流量的拥塞控制机制应运而生。我们选择使用DCQCN，本质是利用ECN进行拥塞警告，之所以选择DCQCN，是因为它能直接对中间交换机的队列长度进行响应，并且所有的交换机都支持ECN。小的队列长度减少了PFC的产生和传播几率。尽管DCQCN帮助减少了PFC暂停帧的数量，但是是PFC在保护数据包不被丢弃。PFC提出了一些安全问题，正的本论文的重点内容，第4部分会进行讨论。我们相信，从本论文学到的经验教训同样适用于使用TIMELY的网络。

       Coexistence of RDMA and TCP：本论文中，RDMA是为intra-DC通信设计的，而intra-DC和延迟应用仍然需要TCP，TCP使用一个不同的流量类（无损），不同的流量类别将TCP和RDMA的流量隔离开来。

3. DSCP-BASED PFC

       在本小节中，我们测试了原始的基于VLAN的PFC面对的问题，并提出了基于DSCP的PFC方案。基于VLAN的PFC暂停帧中，VLAN TAG中包含了数据包优先级和VID，但是优先级和VID在部署中引发了两个严重的问题，因此提出了基于DSCP的PFC方案。

       图3（a）显示了原始基于VLAN的PFC中PFC暂停帧的数据包格式和数据包。暂停帧是一个二层帧，并没有VLAN标签，数据包的VLAN标签有四部分，TPID被固定为0x8100，DEI（Drop Eligible Indicator丢弃符合条件的指标），PCP（Priority Code Point）包含数据包的优先级，VID（VLAN identifier）是数据包的VLAN ID。

       尽管我们只需要PCP，但是PCP和VID是不可分离的，因此，为了支持PFC， 我们必须在服务器端和交换机端都配置VLAN。为了使得交换机端口支持VLAN，我们需要把面向交换机端口的服务器设置为trunk模式（支持VLAN标记的数据包），而不是access模式（发送和接收的都是没有标记的数据包）。基本的PFC功能都是使用这种配置，但是会引发两个问题。

       第一，交换机的trunk模式和操作系统提供的服务有不利的交互。OS provisioning是一个基本服务，当服务器OS需要更新或者安装，或者当服务器需要被修复和供应的时候，需要运行这个基本服务。在我们的数据中心中，OS provisioning必须自动完成。我们使用PXE boot来安装OS。当服务器经过PXE boot的时候，它的NIC没有VLAN配置，结果就是不能发送和接收带有VLAN标签的数据包，但是由于面向服务器端口配置成了trunk模式，这些交换机端口只能发送带有VLAN标签的数据包，因此服务器之间的PXE boot通信和OS provisioning服务就崩溃了。我们尝试了一些“黑客”方式进行问题修复，比如基于猜测的服务器状态改变交换机端口配置，让NIC接收所有的数据包，不管是否有VLAN标签，但是这些方式都是很复杂并且不可靠的，或者说，都不是标准的。

       第二，我们已经从二层VLAN移开了，我们所有的交换机，包括ToR，都运行着三层IP交付，而不是基于MAC的二层桥接。一个三层网络有很多优势，比如扩展性、更好的管理和监控、更好的安全性、所有的协议都是公开而标准的。但是，在三层网络中，当穿越子网边界时，没有标准的方式去预留VLAN PCP。

       分析这两个问题，可以发现产生的原因都是，基于VLAN的PFC不必要的数据包优先级和VLANID，因此提出了基于DSCP的PFC，替换掉PCP和VID。我们的关键观点就是PFC暂停帧并不包含VLAN标签，数据包中的VLAN标签只是用来携带数据包优先级，但是在IP中，我们有更好的方式传输优先级信息，那就是IP头部的DSCP域。

       如图3（b）所示解决办法就是把数据包优先级从VLAN标签中移到DSCP，这个改变是很小的，并且只涉及到了数据包（data packet）的格式，PFC暂停帧并没有改变。基于DSCP的PFC中，没有VLAN标签，所以就没有上述两个问题，因为上述两个问题的起因就是因为VLAN标签中的优先级和VLAN ID。面向服务器端口不用配置成trunk模式了，也就意味着PXE boot不会有任何问题。与此同时，数据包的优先级会以DSCP值的形式，在子网中通过IP路由正确传输。当然，基于DSCP的PFC并不能为工作在二层的设计提供服务，但是对我们来说也没任何问题，因为数据中心中没有二层网络。

       当然，基于DSCP的PFC不适用于需要停留在第2层的设计，例如，以太网光纤通道（FCoE）。 这对我们来说不是问题，因为我们的数据中心中没有任何第二层网络。

       基于DSCP的PFC要求NIC和交换机都基于DSCP值而不是VLAN标签对数据包进行分类和排队。 另外，NIC需要发送具有正确DSCP值的数据包。 幸运的是，交换机和NIC ASIC足够灵活以实现此目的。 内部，在每个端口上，交换机或NIC维护八个优先级组（PG），每个PG可配置为无损或有损。 如果将PG i（i∈[0，7]）配置为无损，则一旦其入口缓冲区占用超过XOFF阈值，就会生成优先级为i的暂停帧。 DSCP值和PFC优先级之间的映射可以是灵活的，甚至可以是多对一的。 在我们的实现中，我们仅将DSCP值i映射到PFC优先级i。

       我们基于DSCP的PFC规范是公开可用的，并得到所有主要供应商（Arista网络，Broadcom，Cisco，Dell，Intel，Juniper，Mellanox等）的支持。 我们认为，基于DSCP的PFC比针对IP网络的基于VLAN的原始设计提供了更简单，更具可扩展性的解决方案。

4. THE SAFETY CHALLENGES

       使用PFC和RDMA传输会带来一些安全挑战。 现在，我们描述这些挑战以及为解决这些挑战而设计的解决方案。

4.1 RDMA transport livelock

       RDMA传输协议的设计有一个假设前提，就是在网络拥塞的时候，数据包不会被丢弃，在RoCEv2中是通过PFC来实现的，但是，丢包现象仍然会发生，比如FCS错误或者交换机软件、硬件层面的bug，理想情况下，我们希望RDMA性能在存在此类错误的情况下能够尽可能地不会损失太多。但是我们发现，即使丢包率很低，RDMA性能也会大幅下降。我们用下面简单的实验来说明这个问题。

       用一台交换机W连接两个服务器A和B，分别进行RDMA SEND，WRITE，READ实验。第一个实验中，A执行RDMA SENDs将4MB数据以最快速度发送到B；第二个实验中，A执行RDMAWRITE操作，其余和第一个实验相同；第三个实验中，B使用RDMAREAD以最快的速度从B读取4MB数据块。实验环境中，丢包率是1/256（4%）。

       我们发现，即使丢包率很低，吞吐能力还是为0。换句话说，系统处于活锁状态，虽然链路充分利用了线速，但是进程没有任何进展。根源在于go-back-0算法，这个算法用来进行RDMA传输的丢失恢复。假设A给B发送消息，这个消息被分段成了数据包0，1，…，m，假设数据包i丢失了，那么B会给A发送NAK（i），A收到之后就会从数据包0重新发送该消息，因此go-back-0就导致了活锁。一个4MB的消息被分成4000个数据包，因为丢包率是1/256，假设第一个256个数据包会丢失一个数据包，那么发送者就会重新发送，发送的时候又会丢包，所以会一直发送，但没有任何进展。表面上看起来一直在发送，但实际上并没有有效进展。

       TCP和RDMA在网络上有不同的假设。TCP是最大努力交付，允许数据包丢失，并且通过诸如SACK等复杂的重传机制解决丢包问题。RDMA假设网络是无损的，因此供应商选择使用简单的go-back-0方法，在这种方法中，发送者不需要维护重传状态。

       这个实验清晰地展示了在大规模网络环境中（比如我们的数据中心网络），尽管使用了PFC，但是仍然会有是丢包现象发生，因此还是需要一个复杂的重传机制。NIC的资源限制意味着无法实现像SACK那样复杂的重传机制，同时，SACK也没有必要，因为PFC已经消除了网络拥塞造成的丢包现象，丢包现象很少，没必要使用如此复杂的机制。

       我们的解决办法是用go-back-N代替go-back-0机制，在go-back-N中，重传从第一个丢失的数据包开始，之前已经接收到的数据包不需要重传。Go-back-N机制几乎和go-back-0一样简单，同时避免了活锁。自从使用了go-back-N，我们没有遇到过活锁，因此建议使用go-back-N。

4.2 PFC DeadLock

       我们曾经认为我们的网络是无死锁的，因为它具有Clos网络拓扑结构和上下路由[1、3、19]。 在这种拓扑中，当源服务器将数据包发送到目标服务器时，数据包首先爬升到源和目标的公共祖先之一，然后沿路径到达目标。 因此，不存在循环缓冲区依赖性。 但是令我们惊讶的是，当我们在一个测试集群中进行压力测试时，我们确实遇到了PFC死锁。

       正如我们稍后将看到的，这是因为PFC和以太网数据包泛洪之间的意外交互破坏了上下路由。

       在深入研究此示例的细节之前，让我们简要回顾一下ToR交换机如何将IP数据包转发到服务器。 通常，连接到同一ToR的服务器位于同一IP子网中。 然后将该子网通告给网络的其余部分，以便网络的其余部分可以将数据包转发到ToR交换机。 一旦ToR接收到属于其服务器之一的IP数据包，它就需要查询两个表。 一个是ARP表，ToR交换机可以从该表中找出目标服务器的MAC地址。 第二个是MAC地址表，ToR交换机可从该表中找出MAC地址与哪个物理端口相关联。 ARP表用于第3层IP，而MAC地址表用于第2层。 ARP表由ARP协议维护。 交换机监视哪个数据包来自哪个端口来建立MAC地址表。

       这两个表都使用超时来淘汰过时的条目。ARP和MAC表的典型超时值有很大不同：分别为4小时和5分钟。 使用这种不同的超时值的原因是，刷新两个表中的条目的开销非常不同。 当收到新的数据包时，MAC表将由硬件自动刷新，而ARP表则由由交换器CPU处理的ARP数据包更新。 因此，ARP表的维护成本更高，因此ARP表的超时值更长。 如此不同的超时值可能导致ARP项“不完整”，即ARP表中存在MAC地址，但该MAC地址的MAC地址表中没有条目。 当目的地为此类MAC地址的数据包到达时，交换机将无法确定将数据包转发到哪个端口。 在这种情况下，标准行为是交换机将数据包泛洪到其所有端口。

       下面，我们使用如图4所示的简化示例来说明死锁的发生方式。 我们假设示例中的所有数据包都是受PFC保护的无损数据包。

1.服务器S1正在通过路径{T0，La，T1}将数据包发送到S3和S5。紫色数据包发送到S3，黑色数据包发送到S5。 S3已死，因此在端口T1.p3处接收到的紫色数据包将泛洪到T1的其余端口（包括p4）。 T1.p4的出口队列一旦到达目的地，就会丢弃紫色数据包，因为目的地MAC不匹配。但在此之前，这些紫色数据包在此排队。此外，由于来自S1和其他来源的广播流量，T1.p2也变得拥塞。因此，黑色数据包在T1中排队。结果，T1.p3的入口开始暂停La.p1的出口。

2.因此，随着黑色和紫色数据包在La中建立队列，La.p0的入口端口开始暂停T0.p2的出口端口。出于同样的原因，T0.p0的入口端口开始暂停S1。

3.服务器S4开始通过路径{T1，Lb，T0}将蓝色数据包发送到S2。不幸的是，S2也已经死了。然后，端口T0.p3将蓝色数据包泛洪到包括T0.p2在内的其余端口。由于T0.p2的出口处的所有数据包（包括蓝色数据包）都无法排出，因此T0.p3的入口端口开始暂停Lb.p0。

4.结果，Lb.p1的入口端口开始暂停T1.p4，而T1.p1开始暂停S4。

       请注意，即使在T1.p2的拥塞消失之后黑包离开T1到S5，T1.p3也将继续暂停La.p1。 这是因为L1暂停了T1.p4，因此紫色数据包无法排出。 然后在四个开关之间形成一个PFC暂停帧循环。 因此发生死锁。 一旦发生死锁，即使我们重新启动所有服务器，死锁也不会消失。

       此死锁是众所周知的循环缓冲区依赖关系的具体示例（请参见[12、18、22、36]和其中的引用）。 但是，周期性依赖的原因是“新的”。 这是由交换机的泛洪行为引起的。 在以太网交换机中，一旦数据包的目的地MAC地址未知，该数据包就会泛洪到除接收端口之外的所有端口。 如上例所示，这种“合法”行为导致形成依赖圈。

       我们需要停止对无损数据包进行泛洪，以防止发生死锁。 当ARP条目不完整时，有多种选择供我们选择（即，存在IP地址到MAC地址的映射，但没有MAC地址到端口号的映射）。 （1）我们将数据包转发到交换CPU，然后让交换CPU确定该怎么做。 （2）我们将MAC表的超时值设置为长于ARP表的超时值，以使ARP条目不会不完整。 （3）如果无损数据包对应的ARP条目不完整，我们将其丢弃。

       我们选择了选项（3）。 选项（1）可能会增加交换机CPU开销。 选项（2）需要减少ARP表超时值或增加MAC地址表超时值。 如果减小ARP表超时值，则会增加用于ARP处理的交换机CPU开销。 如果增加MAC地址表超时值，则需要更长的时间来告知服务器何时与交换机断开连接。 选项（3）是防止死锁的更好方法，因为它可以直接防止循环缓冲区依赖性。

       我们从PFC僵局中学到的教训是广播和多播对于无损网络是危险的。 为了防止发生死锁，我们建议不要将广播和多播数据包置于无损类中。

4.3 NIC PFC pause frame storm

       PFC暂停帧可防止通过暂停上游设备而丢弃数据包。 但是，由于行头阻塞，PFC可能对无害流量造成附带损害。 我们在图5中说明最坏的情况：

1，服务器0的NIC发生故障，不断向其ToR交换机发送暂停帧;

2. ToR交换机依次暂停所有其余端口，包括到Leaf交换机的所有上游端口。

3.叶子交换机暂停脊椎交换机；

4. Spine交换机暂停其余的Leaf交换机；

5.其余的叶子交换机暂停其ToR交换机；

6. ToR交换机会暂停连接到它们的服务器。

       PFC风暴问题的根本原因是NIC的接收管道中存在错误。 该错误使NIC无法处理收到的数据包。 结果，NIC的接收缓冲区已满，并且NIC一直一直发出暂停帧。

       我们已经与NIC提供程序一起修复了此NIC错误。 此外，为了防止PFC风暴损害网络，我们如下在NIC和ToR交换机上实现了两个看门狗。 在NIC方面，我们与NIC提供程序一起构建了PFC风暴预防看门狗。 这是可能的，因为NIC有一个单独的微控制器，可用于监视NIC接收方管道。 一旦NIC微控制器检测到接收管道已停止一段时间（默认为100ms），并且NIC正在生成暂停帧，则微控制器将禁止NIC生成暂停帧。 我们在PFC风暴中的经验是，一旦NIC进入风暴模式，由于NIC不再能够正常工作，服务器便与网络断开连接。 NIC看门狗无法挽救服务器。 相反，其目标是防止暂停帧风暴损害网络的其余部分。

       在ToR交换机方面，我们与交换机提供商合作构建了一个交换机看门狗，以监视面向服务器的端口。 一旦面向出口端口的服务器对无法排空的数据包进行排队，并且该端口正在从NIC接收连续的暂停帧，则交换机将禁用该端口的无损模式，并丢弃往返于该端口的无损数据包。 网卡。 与NIC侧看门狗类似，它可以防止出现故障的NIC暂停帧传播到网络中。 一旦交换机检测到来自NIC的暂停帧消失了一段时间（默认为200ms），它将重新启用端口的无损模式。

       这两个看门狗相互补充。 其中之一应足以阻止NIC PFC风暴。 我们都为双重保险实施了保险。

       请注意，这两种看门狗实现之间的差别很小。 一旦暂停帧消失，交换看门狗将重新启用无损模式，而NIC看门狗不会重新启用无损模式。 这是因为我们已经观察到，一旦NIC进入PFC风暴模式，它就永远不会回来。 因此，NIC不需要重新启用无损模式。

       我们还观察到，NIC PFC风暴问题通常可以通过服务器重新启动来解决。 因此，一旦NIC不起作用，我们的服务器管理系统将尝试修复（重新引导，重新映像等）服务器。 修理需要数十分钟。 NIC看门狗可以将出现问题的NIC的损坏限制在服务器修复开始之前的数百毫秒内。成功修复服务器并且暂停服务器中的帧消失后，交换机可以为相应的交换机重新启用无损模式 自动移植。

       博学的读者可能会对这两个看门狗之间的相互作用感到好奇。 NIC看门狗禁用NIC暂停帧后，交换机看门狗将为相应的交换机端口重新启用无损模式。 到NIC的数据包将被交换机丢弃（如果NIC的MAC地址超时）或被NIC丢弃（因为NIC接收管道无法正常工作）。 无论哪种情况，NIC PFC风暴都不会对整个网络造成损害。

       我们建议交换机和NIC都应实施看门狗，以防止NIC PFC风暴。

4.4 The Slow-receiver symptom

       在我们的数据中心中，服务器NIC使用点对点电缆连接到ToR交换机。 NIC通过PCIe连接到CPU和内存系统。 对于40 GbE NIC，它使用PCIe Gen3x8，它提供64Gb / s的原始双向带宽，超过NIC的40Gb / s的吞吐量。 因此，交换机与服务器CPU和内存之间似乎没有瓶颈。 我们认为服务器NIC应该无法为交换机生成PFC暂停帧，因为服务器端没有拥塞点。

       但这不是我们观察到的。 我们发现许多服务器每秒可能会生成多达数千个PFC暂停帧。 由于RDMA数据包不需要服务器CPU进行处理，因此瓶颈必须在NIC中。 事实证明确实如此。 NIC的内存资源有限，因此将大多数数据结构（包括QPC（队列对上下文）和WQE（工作队列元素））放入服务器的主内存中。 NIC仅在其自己的内存中缓存少量条目。 NIC具有内存转换表（MTT），可将虚拟内存转换为物理内存。 MTT只有2K条目。 对于4KB页面大小，2K MTT条目只能处理8MB内存。

       如果WQE中的虚拟地址未在MTT中映射，则将导致高速缓存未命中，并且NIC必须为新的虚拟地址替换一些旧条目。 NIC必须访问服务器的主内存才能获取新虚拟地址的条目。 所有这些操作都需要时间，并且接收管道必须等待208个。 因此，MTT高速缓存未命中将减慢数据包处理流程。 一旦接收管道速度变慢，并且接收缓冲区占用超过PFC阈值，NIC必须为交换机生成PFC暂停帧。

       我们将此现象称为慢接收器症状。 尽管其破坏程度不如NIC PFC风暴严重，但它仍可能导致暂停帧传播到网络中并造成附带损害。

       接收速度慢的症状是由NIC设计引起的“软”错误。 我们采取了两项措施来缓解这种情况。 在NIC方面，我们使用2MB而不是4KB的大页面大小。 页面较大时，MTT条目未命中的频率会降低。 在交换机方面，我们启用了不同交换机端口之间的动态缓冲区共享。 与静态缓冲区预留相比，动态缓冲区共享在统计上为RDMA流量提供了更多缓冲区。 因此，即使NIC时不时暂停交换机端口，交换机也可以在本地吸收其他队列，而无需将暂停帧传播回网络。 与静态缓冲区分配相比，我们的经验表明，动态缓冲区共享有助于减少PFC暂停帧的传播并提高带宽利用率。

5. RDMA In Production

       我们添加了新的管理和监视功能，以调试第4节中描述的各种RDMA和PFC安全问题，并检测与RDMA相关的错误和事件。 现在，我们讨论这些新功能，包括RDMA / PFC配置监视，PFC暂停帧和无损流量监视以及活动RDMA延迟监视。 我们还介绍了延迟和吞吐量测量。

5.1 Configuration management and monitoring

       要启用RDMA，我们需要在交换机端配置PFC，并在服务器端配置RDMA和PFC。 在交换机端，PFC配置是QoS配置的一部分。 PFC配置具有全局部分，该部分保留缓冲区大小，根据DSCP值将数据包分类为不同的流量类别，将不同的流量类别映射到不同的队列，并为不同的队列分配不同的带宽预留。 PFC配置还具有每个端口部分，该部分为每个单独的物理端口启用PFC。

       在服务器端，有用于启用/禁用RoCEv2的配置，PFC配置，DCQCN配置和流量配置。 在流量配置中，用户可以指定要放入PFC保护中的流量类型。 该规范基于与TCP目标端口类似的目标传输端口。

     我们提供了一个配置监视服务，以检查交换机和服务器的运行配置是否与所需配置相同。 我们的RDMA管理和监视服务可以处理多种交换机类型，多种交换机和NIC固件版本以及针对不同配置的不同配置要求所带来的复杂性。

5.2 PFC pause frame and traffic monitoring

       除了配置监视之外，我们还构建了对PFC暂停帧和两个RDMA流量类别的监视。 对于暂停帧，我们监视由交换机和服务器发送和接收的暂停帧的数量。 我们在服务器端进一步监视暂停间隔。 与暂停帧的数量相比，暂停间隔可以更准确地揭示网络中拥塞的严重性。 不幸的是，暂停间隔不适用于我们当前使用的交换机。 我们已向交换ASIC提供商提出了针对未来ASIC的PFC暂停间隔监视要求。

       对于RDMA流量监视，我们按优先级收集每个端口发送和接收的数据包和字节，在入口端口丢弃数据包，在出口队列丢弃数据包。 流量计数器可以帮助我们了解RDMA流量模式和趋势。 丢弃计数器可帮助我们检测RDMA流量是否有问题：通常不应丢弃RDMA数据包。

5.3 RDMA Pingmesh

       我们已经为RDMA开发了类似于TCP Pingmesh服务的活动等待时间测量服务[21]。 我们让服务器使用RDMA相互ping通，并将测量系统称为RDMA Pingmesh。 RDMA Pingmesh将有效负载大小为512字节的RDMA探针启动到不同位置（ToR，Podset，数据中心）的服务器，并记录测量的RTT（如果探针成功）或错误代码（如果探针失败）。

       从RDMA Pingmesh的RTT测量值，我们可以推断RDMA是否运行良好。

       我们的RDMA管理和监控采用务实的方法，重点关注配置，计数器和端到端延迟。 我们希望这种方法在未来的100G或更高速度的网络中效果很好。 RDMA由于网络速度高和NIC卸载而给数据包级监控带来了挑战，我们计划在下一步中解决。