深度分析PFC(Priority-based Flow Control)处理机制

在前面《深度分析数据中心之PFC(Priority-based Flow Control)技术》一文中，针对PFC技术背景和基本技术进行了分析，而本文将结合IEEE:802.1Qbb标准进一步对PFC功能处理机制进行深度的剖析。

首先、分析PFC和普通流控的区别：

从字面上看可以很清楚的知道，PFC其实是普通流控的升级版。有网络基础的同学都知道普通流控是基于整个端口进行流控的，也就是说当网络出现拥塞时普通流控生效后会把整个端口的流量都停止掉，很明显这样的结果会造成误杀，会把正常的流量都中断掉，这样的结果是网络设计者不想看到的。为了解决这种问题同时FCOE功能本身的需求，才引导出了PFC这个概念，是基于优先级流控，这是什么意思呢？网络流量可以分0-7， 8个优先。假设我针对某个优先级进行流控，这个普通流控功能是做不到的，而PFC可以。当网络拥塞时只会对相应的优先级流量进行流控，而其他流量刚不会受流控功能影响。在实际的网络中PFC要结合ETS功能一起使用，通常在FCOE网络中我们会针对FCOE流量开启PFC功能，同时使用ETS给FCOE流量分配一定的带宽。在这两种功能的共同作用下，最终可以保证FCOE的流量不丢包，同时又能保证FCOE的流量是ETS所分配的带宽。
下面通实际报文对比两个流控功能的不同：

图1 普通流控帧
CISCO设备实际PFC报文如下：

图2 PFC帧

从两个报文的对比情况来看：普通流控帧和PFC帧的目标MAC和Etype都是一样的.不同的opcode,同时PFC增加了priority_enable_vector和time部分。

priority_enable_vector
2字节，高字节置0，低字节的每个位代表相应的time[n]是否有效。e[n]代表优先级n，当e[n]为1时，表示time[n]有效；当e[n]为0，表示time[n]无效。

time
包含time[0] 至time[7]的8个数组单元，每个数组单元为2字节。当e[n]为0时，time[n]没有意义。当e[n]为1时，time[n]代表接收站点抑制优先级为n的报文发送的时间，时间的单位为物理层芯片发送512位数据所需要的时间。所以发送一次PFC PAUSE帧，要求对端设备暂停发送的时间长度最长为：65535 ×物理层芯片发送512位数据所需要的时间。

只有priority_enable_vector对应的cos置1，time对应的cos的下的时间才有效。

其次、标准定义的PFC处理机制：

一、发送拥塞通知：
 如何通知对端
本端发送PAUSE帧给对端，通知对端暂时停止发送报文。
 何时通知对端停止报文发送
若本端在该优先级队列满后才发送PAUSE帧给对端，由于从本端发送出PAUSE帧到对端收到PAUSE帧并停止发送报文的时间段内，若对端无法存储本端发送出的报文，有可能产生报文丢包。若本端在存储转发队列满前过早的开始发送PAUSE帧，发送PAUSE帧过于平凡，会降低网络的效率。因此，在合适的时间点发送PAUSE帧，即上节提到的阀值Qeq。
 停止发送报文的时间长短
PAUSE信息携带停止发送报文的时间长短信息
 通知对端停止发送哪些报文
PAUSE帧携带IEEE802.1P优先级向量的信息
综上所述，在本端检测到拥塞时，通过发送PAUSE帧通知对端暂时停止发送报文，PAUSE帧携带停止报文发送的时间长短信息，及IEEE802.1P优先级向量信息，通知对端在上述时间段内暂时停止发送携带上述优先级的报文。

二、处理拥塞通知：
 若对端有开启相应优先级的PFC功能，且尚未暂停发送相应优先级的报文，则暂停发送相应优先级的报文，并根据PFC PAUSE帧中对应的暂停时间启动定时器。当定时器到期后，将恢复相应优先级报文的发送。
 若对端有开启相应优先级的PFC功能，且已经暂停发送相应优先级的报文，则根据PFC PAUSE帧中对应的暂停时间更新对应定时器的到期时间。
 若PFC PAUSE帧中对应的暂停时间为0，则相当于使对应的暂停定时器立即到期，立即恢复相应优先级报文的发送。
 若PFC PAUSE帧中对应的暂停时间不为0，则相当于复位对应的暂停定时器。也就是说，只要本端一直拥塞，则对端会因不断收到PFC PAUSE帧而持续暂停发送相应优先级的报文。
 若对端没有开启相应优先级的PFC功能，则不会暂停发送相应优先级的报文。

最后：分析CISCO实现：

当网络拥塞的时候，端口会发出流控帧，那么就要对端口的缓存设置一条水线，达到水线后，就出发PFC PAUSE。如果水线设置的太小，那么可能导致降低网络带宽的利用率；如果水线设置的太大，那么可能导致丢包；所以需要设置一个合理的水线值。Cisco的水线设置，主要考虑了以下5个因素：
1、 接收端最大的传输MTU（Maximum transmission unit (MTU) on the transmitting end of receiver R）
最糟糕的情况是，端口检测到了拥塞，要发出PFC pause帧，而这个时候传输队列中刚好有一个MTU为9216的报文正在传输，故PFC PAUSE的发送就会受到延迟。
2、 线路速率（Speed of wire W）
当端口发出PFC PAUSE帧后，端口还需要能够缓存住已经在线缆中传输的报文。考虑10Gbps的链路速率，接收端发出PAUSE帧后，传统的100m电缆要延迟476ns，发送端在收到PAUSE帧前，还要发出4760bit（595byte）的数据量；传统的单模光纤要延迟513ns，发送端在收到PAUSE帧前，还要发出5130bit（641byte）的数据量。所以缓存需要考虑最糟糕的情况，每100m要能够缓存641byte的数据量。
3、 传输延迟（Transceiver latency）
接收端口发送出PAUSE帧和接收端口接收PAUSE帧产生的时延需要考虑。每延时512ns，则需要缓存640byte的数据量，考虑发送和接收的总共时延，这部分产生的缓存需要按照2倍计算。
4、 接收端对PAUSE帧的反应时间（Response time of sender S）
端口从接收到PAUSE帧到停止发送报文，需要60 quanta，也就是60*512=30720bit（3840byte）
5、 发送端口的MTU（MTU on the transmitting end of sender S）
发送端口收到PAUSE帧，要停止发送报文，但已经有一个报文传输了一位，最糟糕的情况，就是正在传输的报文大小为MTU，这个报文不能丢弃，要发送出去。

总结：根据上述五大因素的分析，端口缓存的最小值应该是
9216byte*2+641byte*3+640byte*2=21635byte。当然，根据不同的环境，参数需要修订。比如设备间最大的PFC传输距离是300m，CAN网卡支持的最大PFC传输距离是50m。不同的传输距离，对端口缓存的要求是不同的。

802-1bb-d2-3中则提出了以下4个方面的PFC 延时：
a) Processing and queuing delay of the PFC request;
b) Propagation delay of the PFC frame across the media;
c) Response time to the PFC indication at the far end; and
d) Propagation delay across the media on the return path.
这5个方面的延时，具体化到设备上，如下：
a) PFC transmission delay: the time needed by a station to request transmission of a PFC frame after a PFC M_CONTROL.request has been invoked (e.g., because a maximum length data frame can be transmitted).
b) Interface Delay (ID): the sum of MAC Control, MAC/RS, PCS, PMA, and PMD delays. Interface Delay is is dependent on the MAC and physical layer in use.
c) Cable Delay: the number of bits in flight stored in the transmission medium. This delay value is dependent on the selected technology and on the medium length.
d) Higher Layer Delay (HD): the time needed for a queue to go into paused state after the reception of a PFC M_CONTROL.indication that paused its priority. A substantial portion of this delay component is implementation specific.
总结这标准中提到的因素：接口队列传输延时、接口延时、电缆延时、反应延时。这四个方面实际就是Cisco提出的5个影响因素。