一周一论文（翻译）——[SIGMOD 2016] RDMA over Commodity Ethernet at Scale
本文主要解決的問(wèn)題是在RoCEv2體系中，基于VLAN的PFC的擁塞控制是逐跳工作的，源和目的服務(wù)器之間可能有多跳，如果有持續(xù)的網(wǎng)絡(luò)擁塞，PFC暫停幀會(huì)從阻塞點(diǎn)傳播并返回到源，這就會(huì)導(dǎo)致諸如unfairness和victim flow的問(wèn)題。因此作者提出了基于DSCP的優(yōu)先級(jí)流量控制機(jī)制PFC，替換掉PCP和VID來(lái)確保大規(guī)模部署。
?
Abstract
?????? 在過(guò)去一年半的時(shí)間，我們已經(jīng)使用RoCEv2來(lái)支持一些微軟高可靠性、延遲敏感的服務(wù)。本篇論文講述了在此過(guò)程中遇到的挑戰(zhàn)以及解決方案。為了把RoCEv2擴(kuò)展到VLAN之外，我們?cè)O(shè)計(jì)了一個(gè)基于DSCP的優(yōu)先級(jí)流量控制機(jī)制（PFC）來(lái)確保大規(guī)模部署。我們已經(jīng)解決了很多安全挑戰(zhàn)，比如PFC-減少死鎖、RDMA傳輸livelock以及NIC PFC暫停幀風(fēng)暴問(wèn)題。我們也建立了監(jiān)控和管理系統(tǒng)來(lái)確保RDMA按照預(yù)期的方式工作運(yùn)行。我們的經(jīng)驗(yàn)表明，大規(guī)模運(yùn)行RoCEv2的安全和可擴(kuò)展問(wèn)題都可以被解決，RDMA可以代替TCP進(jìn)行內(nèi)部數(shù)據(jù)中心通信，并且可以實(shí)現(xiàn)低延遲、低CPU開(kāi)銷、高吞吐量。傳統(tǒng)TCP/IP仍然占據(jù)主導(dǎo)地位，但是不能滿足新一代DC工作負(fù)載的需求，有兩個(gè)原因：傳統(tǒng)TCP/IP的CPU負(fù)載太高，傳統(tǒng)TCP/IP延遲太高。
1. Introduction
?????? 隨著在線服務(wù)和云計(jì)算的快速增長(zhǎng)，大規(guī)模數(shù)據(jù)中心（DC）正在世界范圍內(nèi)建立。 連接DC中的服務(wù)器需要高速，可擴(kuò)展的數(shù)據(jù)中心網(wǎng)絡(luò)（DCN）[1、3、19、31]。 DCN的建立需要商用交換機(jī)和網(wǎng)卡（NIC）。 最先進(jìn)的DCN必須支持DC中任何兩個(gè)服務(wù)器之間Gb/s或更高的吞吐量。
?????? 在當(dāng)今的數(shù)據(jù)中心網(wǎng)絡(luò)中，TCP / IP仍然是主要的傳輸/網(wǎng)絡(luò)堆棧。 但是，越來(lái)越明顯的是，傳統(tǒng)的TCP / IP堆棧不能滿足新一代DC工作負(fù)載的需求[4、9、16、40]，這有兩個(gè)原因。
?????? OS內(nèi)核中的數(shù)據(jù)包操作帶來(lái)的CPU開(kāi)銷仍然很高，盡管做了很多硬件和軟件上的優(yōu)化，比如卸載校驗(yàn)和、LSO、RSS和適度中斷。在我們數(shù)據(jù)中心中的測(cè)量結(jié)果顯示，一個(gè)32核Intel Xeon E5-2690 Windows 2012R2 服務(wù)器用8個(gè)TCP連接以40Gb/s發(fā)送chew up6% 聚合CPU時(shí)間。使用8個(gè)TCP連接到達(dá)40Gb/s需要12%聚合的CPU時(shí)間，現(xiàn)代的數(shù)據(jù)中心是無(wú)法忍受這種高CPU開(kāi)銷的。
?????? 許多當(dāng)代DC應(yīng)用，比如Search，對(duì)網(wǎng)絡(luò)延遲都是高度靈敏的。TCP不能提供需要的低延遲，即使平均流量負(fù)載是適當(dāng)?shù)?#xff0c;有兩個(gè)原因。第一，內(nèi)核軟件產(chǎn)生的延遲有幾十毫秒；第二，由于網(wǎng)絡(luò)擁塞，會(huì)有數(shù)據(jù)丟包現(xiàn)象出現(xiàn)，盡管很少，但并沒(méi)有在我們的數(shù)據(jù)中心中消失，這時(shí)因?yàn)閿?shù)據(jù)中心固有的突發(fā)性。TCP通過(guò)超時(shí)或者快速重傳來(lái)恢復(fù)正常，而這兩種情況中，都有很大的延遲。
?????? 在本文中，我們總結(jié)了我們?cè)诓渴餜oCEv2（融合以太網(wǎng)v2上的RDMA）[5]（一種RDMA（遠(yuǎn)程直接內(nèi)存訪問(wèn)）技術(shù)[6]）方面的經(jīng)驗(yàn)，以解決Microsoft數(shù)據(jù)中心中的上述問(wèn)題。 RDMA是一種在不中斷CPU操作的前提下可以訪問(wèn)遠(yuǎn)程系統(tǒng)的方法。 RDMA廣泛應(yīng)用于高性能計(jì)算中，以Infiniband為架構(gòu)，RoCEv2支持RDMA實(shí)現(xiàn)在以太網(wǎng)上，而不是Infiniband。?
?????? 與TCP不同，RDMA需要無(wú)損網(wǎng)絡(luò)。 也就是說(shuō)由于交換機(jī)上的緩沖區(qū)溢出，必須沒(méi)有數(shù)據(jù)包丟失。 RoCEv2為此使用PFC（基于優(yōu)先級(jí)的流量控制）[14]。 當(dāng)緩沖區(qū)占用超過(guò)指定閾值時(shí)，PFC通過(guò)暫停上游發(fā)送實(shí)體來(lái)防止緩沖區(qū)溢出。 雖然PFC的一些問(wèn)題（例如行首阻塞和潛在的死鎖）是眾所周知的[22，33]，但我們看到了一些問(wèn)題，例如RDMA傳輸實(shí)時(shí)鎖定，NIC PFC pause frame storm和slow- receiver symptom。 甚至我們遇到的死鎖問(wèn)題的根本原因也與研究文獻(xiàn)中經(jīng)常討論的示例完全不同[22，33]。
?????? 我們注意到，VLAN標(biāo)簽被典型用于鑒別混合RDMA/TCP部署中的支持PFC的流量。我們將討論，這種解決方案不會(huì)出現(xiàn)在我們的環(huán)境中。因此。我們提出了基于PFC的DSCP（Differentiated Services Code Point）概念，把RDMA從二層VLAN擴(kuò)展到三層IP。
?????? 我們的RDMA部署已經(jīng)平穩(wěn)運(yùn)行了一年半，它支持Microsoft的一些高度可靠且對(duì)延遲敏感的在線服務(wù)。 我們的經(jīng)驗(yàn)表明，通過(guò)改進(jìn)RoCEv2的設(shè)計(jì)，解決各種安全問(wèn)題以及構(gòu)建所需的管理和監(jiān)視功能，我們可以使用商用以太網(wǎng)在大型數(shù)據(jù)中心安全地部署RDMA。
2. Background
?????? 我們的數(shù)據(jù)中心網(wǎng)絡(luò)是一個(gè)基于以太網(wǎng)的多層Clos網(wǎng)絡(luò)。20-40個(gè)服務(wù)器連接到一個(gè)top-of-rack（ToR，頂層機(jī)架）交換機(jī)，數(shù)十個(gè)ToR連接到葉子交換機(jī)層。葉子交換機(jī)反過(guò)來(lái)連接到數(shù)十到上百個(gè)Spine交換機(jī)層上。大多數(shù)鏈路是40Gb/s，我們計(jì)劃在不久的將來(lái)更新到50GbE和100GbE，所有的交換機(jī)都是使用IP路由。
?????? 服務(wù)器和使用大約2米的銅電纜連接到ToR交換機(jī)，ToR交換機(jī)和葉子交換機(jī)之間有10-20米的距離，leaf和spine交換機(jī)之間有200-300米。三層交換機(jī)將數(shù)以萬(wàn)計(jì)的服務(wù)器連接到一個(gè)數(shù)據(jù)中心，本篇論文中，我們的關(guān)注點(diǎn)是同一個(gè)spine交換機(jī)層下的若干服務(wù)器之間的支持RDMA。
?????? RoCEv2：部署RoCEv2是基于技術(shù)和經(jīng)濟(jì)的兩個(gè)原因。RoCEv2在一個(gè)Ethernet/IPv4/UDP數(shù)據(jù)包中解封裝一個(gè)RDMA傳輸包，使得RoCEv2和我們線程的網(wǎng)絡(luò)基礎(chǔ)設(shè)施相兼容，基于ECMP的多路徑路由需要UDP頭部，目的UDP端口通常設(shè)置為4791，源UDP端口對(duì)每個(gè)QP是隨機(jī)選擇的。中間交換機(jī)使用標(biāo)準(zhǔn)的五元組哈希。因此，屬于同一個(gè)QP的流量有相同的路徑，而不同QP中的流量可以有不同的路徑（甚至在同一對(duì)通信終端之間）。
?????? PFC and buffer 保留：RoCEv2使用PFC來(lái)防止緩沖區(qū)溢出。PFC標(biāo)準(zhǔn)指定了8個(gè)優(yōu)先級(jí)種類，來(lái)減少head-of-line阻塞問(wèn)題。但是，在我們的網(wǎng)絡(luò)中，RDMA只能使用8個(gè)中的兩個(gè)優(yōu)先級(jí)。原因如下：
?????? PFC是一個(gè)在兩個(gè)以太網(wǎng)節(jié)點(diǎn)之間的逐跳協(xié)議。發(fā)送者的egress port把數(shù)據(jù)發(fā)送到接收者的ingress port，發(fā)送端口把數(shù)據(jù)包放到最多8個(gè)隊(duì)列中進(jìn)行排隊(duì)，每個(gè)隊(duì)列對(duì)應(yīng)一個(gè)優(yōu)先級(jí)，接收端口把數(shù)據(jù)包緩存到對(duì)應(yīng)的接收隊(duì)列中。在我們網(wǎng)絡(luò)中使用的共享緩沖區(qū)的交換機(jī)中，一個(gè)接收隊(duì)列被作為一個(gè)counter簡(jiǎn)單地實(shí)現(xiàn)，所有的數(shù)據(jù)包共享一個(gè)通用的buffer池。
?????? 一旦接收隊(duì)列的長(zhǎng)度達(dá)到了一定閾值（XOFF），交換機(jī)會(huì)發(fā)送PFC暫停幀到對(duì)應(yīng)的上流egress queue。在egress隊(duì)列接收到暫停幀的時(shí)候，就會(huì)停止發(fā)送數(shù)據(jù)包。暫停幀中包含了需要暫停的優(yōu)先級(jí)隊(duì)列和暫停時(shí)間。一旦接收隊(duì)列的長(zhǎng)度小于另一個(gè)閾值（XON），交換機(jī)會(huì)發(fā)送一個(gè)0持續(xù)時(shí)間的暫停幀給egress queue來(lái)恢復(fù)傳輸。XOFF的值必須能夠保證沒(méi)有buffer overflow，XON來(lái)保證沒(méi)有緩沖區(qū)buffer underflow。（overflow表示緩沖區(qū)已滿，不能再寫(xiě)入了，underflow表示緩沖區(qū)空的，不能讀取數(shù)據(jù)）。?
?????? 傳播時(shí)延取決于發(fā)送者和接收者之間的距離。在我們的網(wǎng)絡(luò)環(huán)境中，二者的距離最大是300米。ToR和leaf交換機(jī)有shallow buffers（9MB或者12MB），我們只能給兩個(gè)無(wú)損的流量類別預(yù)留充足的headroom，即使交換機(jī)支持8個(gè)流量類別。一個(gè)無(wú)損類別進(jìn)行實(shí)時(shí)流量，另一個(gè)無(wú)損類別進(jìn)行批量數(shù)據(jù)傳輸。
?????? 傳播延遲取決于發(fā)送方和接收方之間的距離。 在我們的網(wǎng)絡(luò)中，這可能長(zhǎng)達(dá)300米。 鑒于我們的ToR和Leaf交換機(jī)具有較淺的緩沖區(qū)（9MB或12MB），即使這些交換機(jī)支持八個(gè)流量類別，我們也只能為兩個(gè)無(wú)損流量類別保留足夠的凈空。 我們將一種無(wú)損類用于實(shí)時(shí)流量，將另一類用于批量數(shù)據(jù)傳輸。
?????? Need for congestion control：PFC是逐跳工作的，源和目的服務(wù)器之間可能有多跳，如果有持續(xù)的網(wǎng)絡(luò)擁塞，PFC暫停幀會(huì)從阻塞點(diǎn)傳播并返回到源，這就會(huì)導(dǎo)致諸如unfairness和victim flow的問(wèn)題。
?????? 為了減少這些額外的問(wèn)題，包括QCN、DCQCN和TIMELY在內(nèi)的基于流量的擁塞控制機(jī)制應(yīng)運(yùn)而生。我們選擇使用DCQCN，本質(zhì)是利用ECN進(jìn)行擁塞警告，之所以選擇DCQCN，是因?yàn)樗苤苯訉?duì)中間交換機(jī)的隊(duì)列長(zhǎng)度進(jìn)行響應(yīng)，并且所有的交換機(jī)都支持ECN。小的隊(duì)列長(zhǎng)度減少了PFC的產(chǎn)生和傳播幾率。盡管DCQCN幫助減少了PFC暫停幀的數(shù)量，但是是PFC在保護(hù)數(shù)據(jù)包不被丟棄。PFC提出了一些安全問(wèn)題，正的本論文的重點(diǎn)內(nèi)容，第4部分會(huì)進(jìn)行討論。我們相信，從本論文學(xué)到的經(jīng)驗(yàn)教訓(xùn)同樣適用于使用TIMELY的網(wǎng)絡(luò)。
?????? Coexistence of RDMA and TCP：本論文中，RDMA是為intra-DC通信設(shè)計(jì)的，而intra-DC和延遲應(yīng)用仍然需要TCP，TCP使用一個(gè)不同的流量類（無(wú)損），不同的流量類別將TCP和RDMA的流量隔離開(kāi)來(lái)。
3. DSCP-BASED PFC
?????? 在本小節(jié)中，我們測(cè)試了原始的基于VLAN的PFC面對(duì)的問(wèn)題，并提出了基于DSCP的PFC方案。基于VLAN的PFC暫停幀中，VLAN TAG中包含了數(shù)據(jù)包優(yōu)先級(jí)和VID，但是優(yōu)先級(jí)和VID在部署中引發(fā)了兩個(gè)嚴(yán)重的問(wèn)題，因此提出了基于DSCP的PFC方案。
?????? 圖3（a）顯示了原始基于VLAN的PFC中PFC暫停幀的數(shù)據(jù)包格式和數(shù)據(jù)包。暫停幀是一個(gè)二層幀，并沒(méi)有VLAN標(biāo)簽，數(shù)據(jù)包的VLAN標(biāo)簽有四部分，TPID被固定為0x8100，DEI（Drop Eligible Indicator丟棄符合條件的指標(biāo)），PCP（Priority Code Point）包含數(shù)據(jù)包的優(yōu)先級(jí)，VID（VLAN identifier）是數(shù)據(jù)包的VLAN ID。
?????? 盡管我們只需要PCP，但是PCP和VID是不可分離的，因此，為了支持PFC， 我們必須在服務(wù)器端和交換機(jī)端都配置VLAN。為了使得交換機(jī)端口支持VLAN，我們需要把面向交換機(jī)端口的服務(wù)器設(shè)置為trunk模式（支持VLAN標(biāo)記的數(shù)據(jù)包），而不是access模式（發(fā)送和接收的都是沒(méi)有標(biāo)記的數(shù)據(jù)包）。基本的PFC功能都是使用這種配置，但是會(huì)引發(fā)兩個(gè)問(wèn)題。
?????? 第一，交換機(jī)的trunk模式和操作系統(tǒng)提供的服務(wù)有不利的交互。OS provisioning是一個(gè)基本服務(wù)，當(dāng)服務(wù)器OS需要更新或者安裝，或者當(dāng)服務(wù)器需要被修復(fù)和供應(yīng)的時(shí)候，需要運(yùn)行這個(gè)基本服務(wù)。在我們的數(shù)據(jù)中心中，OS provisioning必須自動(dòng)完成。我們使用PXE boot來(lái)安裝OS。當(dāng)服務(wù)器經(jīng)過(guò)PXE boot的時(shí)候，它的NIC沒(méi)有VLAN配置，結(jié)果就是不能發(fā)送和接收帶有VLAN標(biāo)簽的數(shù)據(jù)包，但是由于面向服務(wù)器端口配置成了trunk模式，這些交換機(jī)端口只能發(fā)送帶有VLAN標(biāo)簽的數(shù)據(jù)包，因此服務(wù)器之間的PXE boot通信和OS provisioning服務(wù)就崩潰了。我們嘗試了一些“黑客”方式進(jìn)行問(wèn)題修復(fù)，比如基于猜測(cè)的服務(wù)器狀態(tài)改變交換機(jī)端口配置，讓NIC接收所有的數(shù)據(jù)包，不管是否有VLAN標(biāo)簽，但是這些方式都是很復(fù)雜并且不可靠的，或者說(shuō)，都不是標(biāo)準(zhǔn)的。
?????? 第二，我們已經(jīng)從二層VLAN移開(kāi)了，我們所有的交換機(jī)，包括ToR，都運(yùn)行著三層IP交付，而不是基于MAC的二層橋接。一個(gè)三層網(wǎng)絡(luò)有很多優(yōu)勢(shì)，比如擴(kuò)展性、更好的管理和監(jiān)控、更好的安全性、所有的協(xié)議都是公開(kāi)而標(biāo)準(zhǔn)的。但是，在三層網(wǎng)絡(luò)中，當(dāng)穿越子網(wǎng)邊界時(shí)，沒(méi)有標(biāo)準(zhǔn)的方式去預(yù)留VLAN PCP。
?????? 分析這兩個(gè)問(wèn)題，可以發(fā)現(xiàn)產(chǎn)生的原因都是，基于VLAN的PFC不必要的數(shù)據(jù)包優(yōu)先級(jí)和VLANID，因此提出了基于DSCP的PFC，替換掉PCP和VID。我們的關(guān)鍵觀點(diǎn)就是PFC暫停幀并不包含VLAN標(biāo)簽，數(shù)據(jù)包中的VLAN標(biāo)簽只是用來(lái)攜帶數(shù)據(jù)包優(yōu)先級(jí)，但是在IP中，我們有更好的方式傳輸優(yōu)先級(jí)信息，那就是IP頭部的DSCP域。
?????? 如圖3（b）所示解決辦法就是把數(shù)據(jù)包優(yōu)先級(jí)從VLAN標(biāo)簽中移到DSCP，這個(gè)改變是很小的，并且只涉及到了數(shù)據(jù)包（data packet）的格式，PFC暫停幀并沒(méi)有改變。基于DSCP的PFC中，沒(méi)有VLAN標(biāo)簽，所以就沒(méi)有上述兩個(gè)問(wèn)題，因?yàn)樯鲜鰞蓚€(gè)問(wèn)題的起因就是因?yàn)?/span>VLAN標(biāo)簽中的優(yōu)先級(jí)和VLAN ID。面向服務(wù)器端口不用配置成trunk模式了，也就意味著PXE boot不會(huì)有任何問(wèn)題。與此同時(shí)，數(shù)據(jù)包的優(yōu)先級(jí)會(huì)以DSCP值的形式，在子網(wǎng)中通過(guò)IP路由正確傳輸。當(dāng)然，基于DSCP的PFC并不能為工作在二層的設(shè)計(jì)提供服務(wù)，但是對(duì)我們來(lái)說(shuō)也沒(méi)任何問(wèn)題，因?yàn)閿?shù)據(jù)中心中沒(méi)有二層網(wǎng)絡(luò)。
?????? 當(dāng)然，基于DSCP的PFC不適用于需要停留在第2層的設(shè)計(jì)，例如，以太網(wǎng)光纖通道（FCoE）。 這對(duì)我們來(lái)說(shuō)不是問(wèn)題，因?yàn)槲覀兊臄?shù)據(jù)中心中沒(méi)有任何第二層網(wǎng)絡(luò)。
?????? 基于DSCP的PFC要求NIC和交換機(jī)都基于DSCP值而不是VLAN標(biāo)簽對(duì)數(shù)據(jù)包進(jìn)行分類和排隊(duì)。 另外，NIC需要發(fā)送具有正確DSCP值的數(shù)據(jù)包。 幸運(yùn)的是，交換機(jī)和NIC ASIC足夠靈活以實(shí)現(xiàn)此目的。 內(nèi)部，在每個(gè)端口上，交換機(jī)或NIC維護(hù)八個(gè)優(yōu)先級(jí)組（PG），每個(gè)PG可配置為無(wú)損或有損。 如果將PG i（i∈[0，7]）配置為無(wú)損，則一旦其入口緩沖區(qū)占用超過(guò)XOFF閾值，就會(huì)生成優(yōu)先級(jí)為i的暫停幀。 DSCP值和PFC優(yōu)先級(jí)之間的映射可以是靈活的，甚至可以是多對(duì)一的。 在我們的實(shí)現(xiàn)中，我們僅將DSCP值i映射到PFC優(yōu)先級(jí)i。
?????? 我們基于DSCP的PFC規(guī)范是公開(kāi)可用的，并得到所有主要供應(yīng)商（Arista網(wǎng)絡(luò)，Broadcom，Cisco，Dell，Intel，Juniper，Mellanox等）的支持。 我們認(rèn)為，基于DSCP的PFC比針對(duì)IP網(wǎng)絡(luò)的基于VLAN的原始設(shè)計(jì)提供了更簡(jiǎn)單，更具可擴(kuò)展性的解決方案。
4. THE SAFETY CHALLENGES
?????? 使用PFC和RDMA傳輸會(huì)帶來(lái)一些安全挑戰(zhàn)。 現(xiàn)在，我們描述這些挑戰(zhàn)以及為解決這些挑戰(zhàn)而設(shè)計(jì)的解決方案。
4.1 RDMA transport livelock
?????? RDMA傳輸協(xié)議的設(shè)計(jì)有一個(gè)假設(shè)前提，就是在網(wǎng)絡(luò)擁塞的時(shí)候，數(shù)據(jù)包不會(huì)被丟棄，在RoCEv2中是通過(guò)PFC來(lái)實(shí)現(xiàn)的，但是，丟包現(xiàn)象仍然會(huì)發(fā)生，比如FCS錯(cuò)誤或者交換機(jī)軟件、硬件層面的bug，理想情況下，我們希望RDMA性能在存在此類錯(cuò)誤的情況下能夠盡可能地不會(huì)損失太多。但是我們發(fā)現(xiàn)，即使丟包率很低，RDMA性能也會(huì)大幅下降。我們用下面簡(jiǎn)單的實(shí)驗(yàn)來(lái)說(shuō)明這個(gè)問(wèn)題。
?????? 用一臺(tái)交換機(jī)W連接兩個(gè)服務(wù)器A和B，分別進(jìn)行RDMA SEND，WRITE，READ實(shí)驗(yàn)。第一個(gè)實(shí)驗(yàn)中，A執(zhí)行RDMA SENDs將4MB數(shù)據(jù)以最快速度發(fā)送到B；第二個(gè)實(shí)驗(yàn)中，A執(zhí)行RDMAWRITE操作，其余和第一個(gè)實(shí)驗(yàn)相同；第三個(gè)實(shí)驗(yàn)中，B使用RDMAREAD以最快的速度從B讀取4MB數(shù)據(jù)塊。實(shí)驗(yàn)環(huán)境中，丟包率是1/256（4%）。
?????? 我們發(fā)現(xiàn)，即使丟包率很低，吞吐能力還是為0。換句話說(shuō)，系統(tǒng)處于活鎖狀態(tài)，雖然鏈路充分利用了線速，但是進(jìn)程沒(méi)有任何進(jìn)展。根源在于go-back-0算法，這個(gè)算法用來(lái)進(jìn)行RDMA傳輸?shù)膩G失恢復(fù)。假設(shè)A給B發(fā)送消息，這個(gè)消息被分段成了數(shù)據(jù)包0，1，…，m，假設(shè)數(shù)據(jù)包i丟失了，那么B會(huì)給A發(fā)送NAK（i），A收到之后就會(huì)從數(shù)據(jù)包0重新發(fā)送該消息，因此go-back-0就導(dǎo)致了活鎖。一個(gè)4MB的消息被分成4000個(gè)數(shù)據(jù)包，因?yàn)閬G包率是1/256，假設(shè)第一個(gè)256個(gè)數(shù)據(jù)包會(huì)丟失一個(gè)數(shù)據(jù)包，那么發(fā)送者就會(huì)重新發(fā)送，發(fā)送的時(shí)候又會(huì)丟包，所以會(huì)一直發(fā)送，但沒(méi)有任何進(jìn)展。表面上看起來(lái)一直在發(fā)送，但實(shí)際上并沒(méi)有有效進(jìn)展。
?????? TCP和RDMA在網(wǎng)絡(luò)上有不同的假設(shè)。TCP是最大努力交付，允許數(shù)據(jù)包丟失，并且通過(guò)諸如SACK等復(fù)雜的重傳機(jī)制解決丟包問(wèn)題。RDMA假設(shè)網(wǎng)絡(luò)是無(wú)損的，因此供應(yīng)商選擇使用簡(jiǎn)單的go-back-0方法，在這種方法中，發(fā)送者不需要維護(hù)重傳狀態(tài)。
?????? 這個(gè)實(shí)驗(yàn)清晰地展示了在大規(guī)模網(wǎng)絡(luò)環(huán)境中（比如我們的數(shù)據(jù)中心網(wǎng)絡(luò)），盡管使用了PFC，但是仍然會(huì)有是丟包現(xiàn)象發(fā)生，因此還是需要一個(gè)復(fù)雜的重傳機(jī)制。NIC的資源限制意味著無(wú)法實(shí)現(xiàn)像SACK那樣復(fù)雜的重傳機(jī)制，同時(shí)，SACK也沒(méi)有必要，因?yàn)镻FC已經(jīng)消除了網(wǎng)絡(luò)擁塞造成的丟包現(xiàn)象，丟包現(xiàn)象很少，沒(méi)必要使用如此復(fù)雜的機(jī)制。
?????? 我們的解決辦法是用go-back-N代替go-back-0機(jī)制，在go-back-N中，重傳從第一個(gè)丟失的數(shù)據(jù)包開(kāi)始，之前已經(jīng)接收到的數(shù)據(jù)包不需要重傳。Go-back-N機(jī)制幾乎和go-back-0一樣簡(jiǎn)單，同時(shí)避免了活鎖。自從使用了go-back-N，我們沒(méi)有遇到過(guò)活鎖，因此建議使用go-back-N。
4.2 PFC DeadLock
?????? 我們?cè)?jīng)認(rèn)為我們的網(wǎng)絡(luò)是無(wú)死鎖的，因?yàn)樗哂蠧los網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)和上下路由[1、3、19]。 在這種拓?fù)渲?#xff0c;當(dāng)源服務(wù)器將數(shù)據(jù)包發(fā)送到目標(biāo)服務(wù)器時(shí)，數(shù)據(jù)包首先爬升到源和目標(biāo)的公共祖先之一，然后沿路徑到達(dá)目標(biāo)。 因此，不存在循環(huán)緩沖區(qū)依賴性。 但是令我們驚訝的是，當(dāng)我們?cè)谝粋€(gè)測(cè)試集群中進(jìn)行壓力測(cè)試時(shí)，我們確實(shí)遇到了PFC死鎖。
?????? 正如我們稍后將看到的，這是因?yàn)镻FC和以太網(wǎng)數(shù)據(jù)包泛洪之間的意外交互破壞了上下路由。
?????? 在深入研究此示例的細(xì)節(jié)之前，讓我們簡(jiǎn)要回顧一下ToR交換機(jī)如何將IP數(shù)據(jù)包轉(zhuǎn)發(fā)到服務(wù)器。 通常，連接到同一ToR的服務(wù)器位于同一IP子網(wǎng)中。 然后將該子網(wǎng)通告給網(wǎng)絡(luò)的其余部分，以便網(wǎng)絡(luò)的其余部分可以將數(shù)據(jù)包轉(zhuǎn)發(fā)到ToR交換機(jī)。 一旦ToR接收到屬于其服務(wù)器之一的IP數(shù)據(jù)包，它就需要查詢兩個(gè)表。 一個(gè)是ARP表，ToR交換機(jī)可以從該表中找出目標(biāo)服務(wù)器的MAC地址。 第二個(gè)是MAC地址表，ToR交換機(jī)可從該表中找出MAC地址與哪個(gè)物理端口相關(guān)聯(lián)。 ARP表用于第3層IP，而MAC地址表用于第2層。 ARP表由ARP協(xié)議維護(hù)。 交換機(jī)監(jiān)視哪個(gè)數(shù)據(jù)包來(lái)自哪個(gè)端口來(lái)建立MAC地址表。
?????? 這兩個(gè)表都使用超時(shí)來(lái)淘汰過(guò)時(shí)的條目。ARP和MAC表的典型超時(shí)值有很大不同：分別為4小時(shí)和5分鐘。 使用這種不同的超時(shí)值的原因是，刷新兩個(gè)表中的條目的開(kāi)銷非常不同。 當(dāng)收到新的數(shù)據(jù)包時(shí)，MAC表將由硬件自動(dòng)刷新，而ARP表則由由交換器CPU處理的ARP數(shù)據(jù)包更新。 因此，ARP表的維護(hù)成本更高，因此ARP表的超時(shí)值更長(zhǎng)。 如此不同的超時(shí)值可能導(dǎo)致ARP項(xiàng)“不完整”，即ARP表中存在MAC地址，但該MAC地址的MAC地址表中沒(méi)有條目。 當(dāng)目的地為此類MAC地址的數(shù)據(jù)包到達(dá)時(shí)，交換機(jī)將無(wú)法確定將數(shù)據(jù)包轉(zhuǎn)發(fā)到哪個(gè)端口。 在這種情況下，標(biāo)準(zhǔn)行為是交換機(jī)將數(shù)據(jù)包泛洪到其所有端口。
?????? 下面，我們使用如圖4所示的簡(jiǎn)化示例來(lái)說(shuō)明死鎖的發(fā)生方式。 我們假設(shè)示例中的所有數(shù)據(jù)包都是受PFC保護(hù)的無(wú)損數(shù)據(jù)包。
1.服務(wù)器S1正在通過(guò)路徑{T0，La，T1}將數(shù)據(jù)包發(fā)送到S3和S5。紫色數(shù)據(jù)包發(fā)送到S3，黑色數(shù)據(jù)包發(fā)送到S5。 S3已死，因此在端口T1.p3處接收到的紫色數(shù)據(jù)包將泛洪到T1的其余端口（包括p4）。 T1.p4的出口隊(duì)列一旦到達(dá)目的地，就會(huì)丟棄紫色數(shù)據(jù)包，因?yàn)槟康牡豈AC不匹配。但在此之前，這些紫色數(shù)據(jù)包在此排隊(duì)。此外，由于來(lái)自S1和其他來(lái)源的廣播流量，T1.p2也變得擁塞。因此，黑色數(shù)據(jù)包在T1中排隊(duì)。結(jié)果，T1.p3的入口開(kāi)始暫停La.p1的出口。
2.因此，隨著黑色和紫色數(shù)據(jù)包在La中建立隊(duì)列，La.p0的入口端口開(kāi)始暫停T0.p2的出口端口。出于同樣的原因，T0.p0的入口端口開(kāi)始暫停S1。
3.服務(wù)器S4開(kāi)始通過(guò)路徑{T1，Lb，T0}將藍(lán)色數(shù)據(jù)包發(fā)送到S2。不幸的是，S2也已經(jīng)死了。然后，端口T0.p3將藍(lán)色數(shù)據(jù)包泛洪到包括T0.p2在內(nèi)的其余端口。由于T0.p2的出口處的所有數(shù)據(jù)包（包括藍(lán)色數(shù)據(jù)包）都無(wú)法排出，因此T0.p3的入口端口開(kāi)始暫停Lb.p0。
4.結(jié)果，Lb.p1的入口端口開(kāi)始暫停T1.p4，而T1.p1開(kāi)始暫停S4。
?????? 請(qǐng)注意，即使在T1.p2的擁塞消失之后黑包離開(kāi)T1到S5，T1.p3也將繼續(xù)暫停La.p1。 這是因?yàn)長(zhǎng)1暫停了T1.p4，因此紫色數(shù)據(jù)包無(wú)法排出。 然后在四個(gè)開(kāi)關(guān)之間形成一個(gè)PFC暫停幀循環(huán)。 因此發(fā)生死鎖。 一旦發(fā)生死鎖，即使我們重新啟動(dòng)所有服務(wù)器，死鎖也不會(huì)消失。
?????? 此死鎖是眾所周知的循環(huán)緩沖區(qū)依賴關(guān)系的具體示例（請(qǐng)參見(jiàn)[12、18、22、36]和其中的引用）。 但是，周期性依賴的原因是“新的”。 這是由交換機(jī)的泛洪行為引起的。 在以太網(wǎng)交換機(jī)中，一旦數(shù)據(jù)包的目的地MAC地址未知，該數(shù)據(jù)包就會(huì)泛洪到除接收端口之外的所有端口。 如上例所示，這種“合法”行為導(dǎo)致形成依賴圈。
?????? 我們需要停止對(duì)無(wú)損數(shù)據(jù)包進(jìn)行泛洪，以防止發(fā)生死鎖。 當(dāng)ARP條目不完整時(shí)，有多種選擇供我們選擇（即，存在IP地址到MAC地址的映射，但沒(méi)有MAC地址到端口號(hào)的映射）。 （1）我們將數(shù)據(jù)包轉(zhuǎn)發(fā)到交換CPU，然后讓交換CPU確定該怎么做。 （2）我們將MAC表的超時(shí)值設(shè)置為長(zhǎng)于ARP表的超時(shí)值，以使ARP條目不會(huì)不完整。 （3）如果無(wú)損數(shù)據(jù)包對(duì)應(yīng)的ARP條目不完整，我們將其丟棄。
?????? 我們選擇了選項(xiàng)（3）。 選項(xiàng)（1）可能會(huì)增加交換機(jī)CPU開(kāi)銷。 選項(xiàng)（2）需要減少ARP表超時(shí)值或增加MAC地址表超時(shí)值。 如果減小ARP表超時(shí)值，則會(huì)增加用于ARP處理的交換機(jī)CPU開(kāi)銷。 如果增加MAC地址表超時(shí)值，則需要更長(zhǎng)的時(shí)間來(lái)告知服務(wù)器何時(shí)與交換機(jī)斷開(kāi)連接。 選項(xiàng)（3）是防止死鎖的更好方法，因?yàn)樗梢灾苯臃乐寡h(huán)緩沖區(qū)依賴性。
?????? 我們從PFC僵局中學(xué)到的教訓(xùn)是廣播和多播對(duì)于無(wú)損網(wǎng)絡(luò)是危險(xiǎn)的。 為了防止發(fā)生死鎖，我們建議不要將廣播和多播數(shù)據(jù)包置于無(wú)損類中。
4.3 NIC PFC pause frame storm
?????? PFC暫停幀可防止通過(guò)暫停上游設(shè)備而丟棄數(shù)據(jù)包。 但是，由于行頭阻塞，PFC可能對(duì)無(wú)害流量造成附帶損害。 我們?cè)趫D5中說(shuō)明最壞的情況：
1，服務(wù)器0的NIC發(fā)生故障，不斷向其ToR交換機(jī)發(fā)送暫停幀;
2. ToR交換機(jī)依次暫停所有其余端口，包括到Leaf交換機(jī)的所有上游端口。
3.葉子交換機(jī)暫停脊椎交換機(jī)；
4. Spine交換機(jī)暫停其余的Leaf交換機(jī)；
5.其余的葉子交換機(jī)暫停其ToR交換機(jī)；
6. ToR交換機(jī)會(huì)暫停連接到它們的服務(wù)器。
?????? PFC風(fēng)暴問(wèn)題的根本原因是NIC的接收管道中存在錯(cuò)誤。 該錯(cuò)誤使NIC無(wú)法處理收到的數(shù)據(jù)包。 結(jié)果，NIC的接收緩沖區(qū)已滿，并且NIC一直一直發(fā)出暫停幀。
?????? 我們已經(jīng)與NIC提供程序一起修復(fù)了此NIC錯(cuò)誤。 此外，為了防止PFC風(fēng)暴損害網(wǎng)絡(luò)，我們?nèi)缦略贜IC和ToR交換機(jī)上實(shí)現(xiàn)了兩個(gè)看門狗。 在NIC方面，我們與NIC提供程序一起構(gòu)建了PFC風(fēng)暴預(yù)防看門狗。 這是可能的，因?yàn)镹IC有一個(gè)單獨(dú)的微控制器，可用于監(jiān)視NIC接收方管道。 一旦NIC微控制器檢測(cè)到接收管道已停止一段時(shí)間（默認(rèn)為100ms），并且NIC正在生成暫停幀，則微控制器將禁止NIC生成暫停幀。 我們?cè)赑FC風(fēng)暴中的經(jīng)驗(yàn)是，一旦NIC進(jìn)入風(fēng)暴模式，由于NIC不再能夠正常工作，服務(wù)器便與網(wǎng)絡(luò)斷開(kāi)連接。 NIC看門狗無(wú)法挽救服務(wù)器。 相反，其目標(biāo)是防止暫停幀風(fēng)暴損害網(wǎng)絡(luò)的其余部分。
?????? 在ToR交換機(jī)方面，我們與交換機(jī)提供商合作構(gòu)建了一個(gè)交換機(jī)看門狗，以監(jiān)視面向服務(wù)器的端口。 一旦面向出口端口的服務(wù)器對(duì)無(wú)法排空的數(shù)據(jù)包進(jìn)行排隊(duì)，并且該端口正在從NIC接收連續(xù)的暫停幀，則交換機(jī)將禁用該端口的無(wú)損模式，并丟棄往返于該端口的無(wú)損數(shù)據(jù)包。 網(wǎng)卡。 與NIC側(cè)看門狗類似，它可以防止出現(xiàn)故障的NIC暫停幀傳播到網(wǎng)絡(luò)中。 一旦交換機(jī)檢測(cè)到來(lái)自NIC的暫停幀消失了一段時(shí)間（默認(rèn)為200ms），它將重新啟用端口的無(wú)損模式。
?????? 這兩個(gè)看門狗相互補(bǔ)充。 其中之一應(yīng)足以阻止NIC PFC風(fēng)暴。 我們都為雙重保險(xiǎn)實(shí)施了保險(xiǎn)。
?????? 請(qǐng)注意，這兩種看門狗實(shí)現(xiàn)之間的差別很小。 一旦暫停幀消失，交換看門狗將重新啟用無(wú)損模式，而NIC看門狗不會(huì)重新啟用無(wú)損模式。 這是因?yàn)槲覀円呀?jīng)觀察到，一旦NIC進(jìn)入PFC風(fēng)暴模式，它就永遠(yuǎn)不會(huì)回來(lái)。 因此，NIC不需要重新啟用無(wú)損模式。
?????? 我們還觀察到，NIC PFC風(fēng)暴問(wèn)題通常可以通過(guò)服務(wù)器重新啟動(dòng)來(lái)解決。 因此，一旦NIC不起作用，我們的服務(wù)器管理系統(tǒng)將嘗試修復(fù)（重新引導(dǎo)，重新映像等）服務(wù)器。 修理需要數(shù)十分鐘。 NIC看門狗可以將出現(xiàn)問(wèn)題的NIC的損壞限制在服務(wù)器修復(fù)開(kāi)始之前的數(shù)百毫秒內(nèi)。成功修復(fù)服務(wù)器并且暫停服務(wù)器中的幀消失后，交換機(jī)可以為相應(yīng)的交換機(jī)重新啟用無(wú)損模式 自動(dòng)移植。
?????? 博學(xué)的讀者可能會(huì)對(duì)這兩個(gè)看門狗之間的相互作用感到好奇。 NIC看門狗禁用NIC暫停幀后，交換機(jī)看門狗將為相應(yīng)的交換機(jī)端口重新啟用無(wú)損模式。 到NIC的數(shù)據(jù)包將被交換機(jī)丟棄（如果NIC的MAC地址超時(shí)）或被NIC丟棄（因?yàn)镹IC接收管道無(wú)法正常工作）。 無(wú)論哪種情況，NIC PFC風(fēng)暴都不會(huì)對(duì)整個(gè)網(wǎng)絡(luò)造成損害。
?????? 我們建議交換機(jī)和NIC都應(yīng)實(shí)施看門狗，以防止NIC PFC風(fēng)暴。
4.4 The Slow-receiver symptom
?????? 在我們的數(shù)據(jù)中心中，服務(wù)器NIC使用點(diǎn)對(duì)點(diǎn)電纜連接到ToR交換機(jī)。 NIC通過(guò)PCIe連接到CPU和內(nèi)存系統(tǒng)。 對(duì)于40 GbE NIC，它使用PCIe Gen3x8，它提供64Gb / s的原始雙向帶寬，超過(guò)NIC的40Gb / s的吞吐量。 因此，交換機(jī)與服務(wù)器CPU和內(nèi)存之間似乎沒(méi)有瓶頸。 我們認(rèn)為服務(wù)器NIC應(yīng)該無(wú)法為交換機(jī)生成PFC暫停幀，因?yàn)榉?wù)器端沒(méi)有擁塞點(diǎn)。
?????? 但這不是我們觀察到的。 我們發(fā)現(xiàn)許多服務(wù)器每秒可能會(huì)生成多達(dá)數(shù)千個(gè)PFC暫停幀。 由于RDMA數(shù)據(jù)包不需要服務(wù)器CPU進(jìn)行處理，因此瓶頸必須在NIC中。 事實(shí)證明確實(shí)如此。 NIC的內(nèi)存資源有限，因此將大多數(shù)數(shù)據(jù)結(jié)構(gòu)（包括QPC（隊(duì)列對(duì)上下文）和WQE（工作隊(duì)列元素））放入服務(wù)器的主內(nèi)存中。 NIC僅在其自己的內(nèi)存中緩存少量條目。 NIC具有內(nèi)存轉(zhuǎn)換表（MTT），可將虛擬內(nèi)存轉(zhuǎn)換為物理內(nèi)存。 MTT只有2K條目。 對(duì)于4KB頁(yè)面大小，2K MTT條目只能處理8MB內(nèi)存。
?????? 如果WQE中的虛擬地址未在MTT中映射，則將導(dǎo)致高速緩存未命中，并且NIC必須為新的虛擬地址替換一些舊條目。 NIC必須訪問(wèn)服務(wù)器的主內(nèi)存才能獲取新虛擬地址的條目。 所有這些操作都需要時(shí)間，并且接收管道必須等待208個(gè)。 因此，MTT高速緩存未命中將減慢數(shù)據(jù)包處理流程。 一旦接收管道速度變慢，并且接收緩沖區(qū)占用超過(guò)PFC閾值，NIC必須為交換機(jī)生成PFC暫停幀。
?????? 我們將此現(xiàn)象稱為慢接收器癥狀。 盡管其破壞程度不如NIC PFC風(fēng)暴嚴(yán)重，但它仍可能導(dǎo)致暫停幀傳播到網(wǎng)絡(luò)中并造成附帶損害。
?????? 接收速度慢的癥狀是由NIC設(shè)計(jì)引起的“軟”錯(cuò)誤。 我們采取了兩項(xiàng)措施來(lái)緩解這種情況。 在NIC方面，我們使用2MB而不是4KB的大頁(yè)面大小。 頁(yè)面較大時(shí)，MTT條目未命中的頻率會(huì)降低。 在交換機(jī)方面，我們啟用了不同交換機(jī)端口之間的動(dòng)態(tài)緩沖區(qū)共享。 與靜態(tài)緩沖區(qū)預(yù)留相比，動(dòng)態(tài)緩沖區(qū)共享在統(tǒng)計(jì)上為RDMA流量提供了更多緩沖區(qū)。 因此，即使NIC時(shí)不時(shí)暫停交換機(jī)端口，交換機(jī)也可以在本地吸收其他隊(duì)列，而無(wú)需將暫停幀傳播回網(wǎng)絡(luò)。 與靜態(tài)緩沖區(qū)分配相比，我們的經(jīng)驗(yàn)表明，動(dòng)態(tài)緩沖區(qū)共享有助于減少PFC暫停幀的傳播并提高帶寬利用率。
5. RDMA In Production
?????? 我們添加了新的管理和監(jiān)視功能，以調(diào)試第4節(jié)中描述的各種RDMA和PFC安全問(wèn)題，并檢測(cè)與RDMA相關(guān)的錯(cuò)誤和事件。 現(xiàn)在，我們討論這些新功能，包括RDMA / PFC配置監(jiān)視，PFC暫停幀和無(wú)損流量監(jiān)視以及活動(dòng)RDMA延遲監(jiān)視。 我們還介紹了延遲和吞吐量測(cè)量。
5.1 Configuration management and monitoring
?????? 要啟用RDMA，我們需要在交換機(jī)端配置PFC，并在服務(wù)器端配置RDMA和PFC。 在交換機(jī)端，PFC配置是QoS配置的一部分。 PFC配置具有全局部分，該部分保留緩沖區(qū)大小，根據(jù)DSCP值將數(shù)據(jù)包分類為不同的流量類別，將不同的流量類別映射到不同的隊(duì)列，并為不同的隊(duì)列分配不同的帶寬預(yù)留。 PFC配置還具有每個(gè)端口部分，該部分為每個(gè)單獨(dú)的物理端口啟用PFC。
?????? 在服務(wù)器端，有用于啟用/禁用RoCEv2的配置，PFC配置，DCQCN配置和流量配置。 在流量配置中，用戶可以指定要放入PFC保護(hù)中的流量類型。 該規(guī)范基于與TCP目標(biāo)端口類似的目標(biāo)傳輸端口。
???? 我們提供了一個(gè)配置監(jiān)視服務(wù)，以檢查交換機(jī)和服務(wù)器的運(yùn)行配置是否與所需配置相同。 我們的RDMA管理和監(jiān)視服務(wù)可以處理多種交換機(jī)類型，多種交換機(jī)和NIC固件版本以及針對(duì)不同配置的不同配置要求所帶來(lái)的復(fù)雜性。
5.2 PFC pause frame and traffic monitoring
?????? 除了配置監(jiān)視之外，我們還構(gòu)建了對(duì)PFC暫停幀和兩個(gè)RDMA流量類別的監(jiān)視。 對(duì)于暫停幀，我們監(jiān)視由交換機(jī)和服務(wù)器發(fā)送和接收的暫停幀的數(shù)量。 我們?cè)诜?wù)器端進(jìn)一步監(jiān)視暫停間隔。 與暫停幀的數(shù)量相比，暫停間隔可以更準(zhǔn)確地揭示網(wǎng)絡(luò)中擁塞的嚴(yán)重性。 不幸的是，暫停間隔不適用于我們當(dāng)前使用的交換機(jī)。 我們已向交換ASIC提供商提出了針對(duì)未來(lái)ASIC的PFC暫停間隔監(jiān)視要求。
?????? 對(duì)于RDMA流量監(jiān)視，我們按優(yōu)先級(jí)收集每個(gè)端口發(fā)送和接收的數(shù)據(jù)包和字節(jié)，在入口端口丟棄數(shù)據(jù)包，在出口隊(duì)列丟棄數(shù)據(jù)包。 流量計(jì)數(shù)器可以幫助我們了解RDMA流量模式和趨勢(shì)。 丟棄計(jì)數(shù)器可幫助我們檢測(cè)RDMA流量是否有問(wèn)題：通常不應(yīng)丟棄RDMA數(shù)據(jù)包。
5.3 RDMA Pingmesh
?????? 我們已經(jīng)為RDMA開(kāi)發(fā)了類似于TCP Pingmesh服務(wù)的活動(dòng)等待時(shí)間測(cè)量服務(wù)[21]。 我們讓服務(wù)器使用RDMA相互ping通，并將測(cè)量系統(tǒng)稱為RDMA Pingmesh。 RDMA Pingmesh將有效負(fù)載大小為512字節(jié)的RDMA探針啟動(dòng)到不同位置（ToR，Podset，數(shù)據(jù)中心）的服務(wù)器，并記錄測(cè)量的RTT（如果探針成功）或錯(cuò)誤代碼（如果探針失敗）。
?????? 從RDMA Pingmesh的RTT測(cè)量值，我們可以推斷RDMA是否運(yùn)行良好。
?????? 我們的RDMA管理和監(jiān)控采用務(wù)實(shí)的方法，重點(diǎn)關(guān)注配置，計(jì)數(shù)器和端到端延遲。 我們希望這種方法在未來(lái)的100G或更高速度的網(wǎng)絡(luò)中效果很好。 RDMA由于網(wǎng)絡(luò)速度高和NIC卸載而給數(shù)據(jù)包級(jí)監(jiān)控帶來(lái)了挑戰(zhàn)，我們計(jì)劃在下一步中解決。
總結(jié)
以上是生活随笔為你收集整理的一周一论文（翻译）——[SIGMOD 2016] RDMA over Commodity Ethernet at Scale的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： 一周一论文（翻译）——[Acta 199
- 下一篇： 一周一论文（翻译）——[SIGMOD 2