在前面《深度分析數據中心之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個影響因素。