一周一论文（翻译）——[SIGMOD 2016] RDMA over Commodity Ethernet at Scale
本文主要解決的問題是在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卸載而給數據包級監控帶來了挑戰，我們計劃在下一步中解決。
總結
以上是生活随笔為你收集整理的一周一论文（翻译）——[SIGMOD 2016] RDMA over Commodity Ethernet at Scale的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 一周一论文（翻译）——[Acta 199
- 下一篇： 一周一论文（翻译）——[SIGMOD 2