摘要：數(shù)據(jù)中心網(wǎng)絡(luò)協(xié)議棧正在轉(zhuǎn)向硬件，以在低延遲和低CPU利用率的情況下實(shí)現(xiàn)100 Gbps甚至更高的數(shù)據(jù)速率。但是，NIC中網(wǎng)絡(luò)協(xié)議棧的硬連線方式扼殺了傳輸協(xié)議的創(chuàng)新。本文通過設(shè)計(jì)Tonic（一種用于傳輸邏輯的靈活硬件架構(gòu)）來實(shí)現(xiàn)高速網(wǎng)卡中的可編程傳輸協(xié)議。在100Gbps的速率下，傳輸協(xié)議必須每隔幾納秒在NIC上僅使用每個(gè)流狀態(tài)的幾千比特生成一個(gè)數(shù)據(jù)段。通過識(shí)別跨不同傳輸協(xié)議的傳輸邏輯的通用模式，我們?yōu)閭鬏斶壿嬙O(shè)計(jì)了一個(gè)高效的硬件“模板”，該模板在使用簡(jiǎn)單的API編程的同時(shí)可以滿足這些約束。基于FPGA的原型系統(tǒng)實(shí)驗(yàn)表明，Tonic能夠支持多種協(xié)議的傳輸邏輯，并能滿足100Gbps背靠背128字節(jié)數(shù)據(jù)包的時(shí)序要求。也就是說，每隔10 ns，我們的原型就會(huì)為下游DMA流水線的一千多個(gè)活動(dòng)流中的一個(gè)生成一個(gè)數(shù)據(jù)段的地址，以便獲取和傳輸數(shù)據(jù)包。

1. 介紹

傳輸協(xié)議以及網(wǎng)絡(luò)協(xié)議棧的其余部分傳統(tǒng)上都在軟件中運(yùn)行。盡管軟件網(wǎng)絡(luò)協(xié)議棧一直在努力提高其性能和效率，但為了跟上當(dāng)今數(shù)據(jù)中心的應(yīng)用程序，軟件網(wǎng)絡(luò)協(xié)議棧往往會(huì)消耗30-40%的CPU周期。

隨著數(shù)據(jù)中心轉(zhuǎn)移到100 Gbps以太網(wǎng)上，軟件網(wǎng)絡(luò)協(xié)議棧的CPU利用率變得越來越高。因此，多個(gè)供應(yīng)商開發(fā)了完全在網(wǎng)卡（NIC）上運(yùn)行的硬件網(wǎng)絡(luò)協(xié)議棧。但是，在這些NIC上僅實(shí)現(xiàn)了兩種主要的傳輸協(xié)議，它們都是硬連線方式并且只能由供應(yīng)商修改。

RoCE. RoCE用于遠(yuǎn)程直接內(nèi)存訪問(RDMA)，使用DCQCN[43]進(jìn)行擁塞控制，并使用簡(jiǎn)單的go-back-N策略進(jìn)行可靠數(shù)據(jù)傳輸。

TCP. 一些供應(yīng)商將他們選擇的TCP變體卸載到NIC，以便直接通過套接字API(TCP卸載引擎)使用或啟用RDMA(iWARP)。

然而，在過去幾十年中提出的用于可靠傳輸和擁塞控制的無數(shù)可能算法中，這些協(xié)議僅使用了一小部分。例如，最近的研究表明，低延遲數(shù)據(jù)中心網(wǎng)絡(luò)可以顯著受益于接收端驅(qū)動(dòng)的傳輸協(xié)議，這并不是當(dāng)今硬件堆棧的選擇。在微軟數(shù)據(jù)中心部署RoCE網(wǎng)卡的嘗試中，運(yùn)營商需要修改數(shù)據(jù)傳輸算法以避免網(wǎng)絡(luò)中出現(xiàn)活鎖，但必須依賴NIC供應(yīng)商進(jìn)行更改。已經(jīng)提出了其他算法來改進(jìn)RoCE的簡(jiǎn)單可靠傳輸算法。多年來，TCP在各種網(wǎng)絡(luò)中的優(yōu)化列表證明了傳輸協(xié)議對(duì)可編程性的需求。

在本文中，我們研究如何實(shí)現(xiàn)硬件傳輸協(xié)議可編程化。即使NIC供應(yīng)商開放了硬件編程接口，在高速硬件中實(shí)現(xiàn)傳輸協(xié)議也需要大量的專業(yè)知識(shí)、時(shí)間和精力。為了跟上100Gbps的速度，傳輸協(xié)議應(yīng)該每隔幾納秒生成并傳輸一個(gè)數(shù)據(jù)包。它需要能夠處理超過1000個(gè)活動(dòng)流，這在今天的數(shù)據(jù)中心服務(wù)器中是很普遍的。然而，NIC在其片上內(nèi)存和計(jì)算資源的數(shù)量方面受到極大的限制。

我們認(rèn)為，高速網(wǎng)卡上的傳輸協(xié)議可以通過編程實(shí)現(xiàn)，而不需要讓用戶接觸高速硬件編程的全部復(fù)雜性。我們的論點(diǎn)主要基于兩個(gè)因素：

首先，可編程傳輸邏輯是實(shí)現(xiàn)靈活硬件傳輸協(xié)議的關(guān)鍵。傳輸協(xié)議的實(shí)現(xiàn)完成了多種功能，例如連接管理、數(shù)據(jù)緩沖區(qū)管理和數(shù)據(jù)傳輸。然而，它的核心任務(wù)是決定傳輸哪些數(shù)據(jù)段(數(shù)據(jù)傳輸)和何時(shí)傳輸(擁塞控制)，統(tǒng)稱為傳輸邏輯，這也是大多數(shù)創(chuàng)新的地方。因此，在高速NIC上實(shí)現(xiàn)可編程傳輸協(xié)議的關(guān)鍵是使用戶能夠修改傳輸邏輯。

其次，可以利用傳輸邏輯中的通用模式來創(chuàng)建可重用的高速硬件模塊。盡管它們?cè)趹?yīng)用級(jí)API(例如，TCP的套接字和字節(jié)流抽象與RDMA的基于消息的謂詞API)以及連接和數(shù)據(jù)緩沖區(qū)管理方面存在差異，但傳輸協(xié)議有幾種共同的模式。例如，不同的傳輸協(xié)議使用不同的算法來檢測(cè)丟失的數(shù)據(jù)包。但是，一旦數(shù)據(jù)包被宣布丟失，可靠傳輸協(xié)議就會(huì)將其重傳而優(yōu)先于發(fā)送一個(gè)新的數(shù)據(jù)段。另一個(gè)例子，在擁塞控制中，給定由控制環(huán)路確定的參數(shù)(例如，擁塞窗口和速率)，只有幾種常見的方法來計(jì)算流在任何時(shí)候可以傳輸多少字節(jié)。這使我們能夠?yàn)橛布械膫鬏斶壿嬙O(shè)計(jì)一個(gè)高效的“模板”，可以使用簡(jiǎn)單的API對(duì)其編程。

基于這些觀點(diǎn)，我們?cè)O(shè)計(jì)并開發(fā)了Tonic，這是一種可編程的硬件架構(gòu)，可以使用簡(jiǎn)單的API來實(shí)現(xiàn)各種傳輸協(xié)議的傳輸邏輯，同時(shí)支持100Gbps的數(shù)據(jù)速率。每個(gè)時(shí)鐘周期，Tonic都會(huì)生成下一個(gè)數(shù)據(jù)段的地址進(jìn)行傳輸。數(shù)據(jù)段由下游DMA流水線從內(nèi)存中提取，并由硬件網(wǎng)絡(luò)協(xié)議棧的其余部分轉(zhuǎn)換為一個(gè)完整的數(shù)據(jù)包(圖1)。

我們認(rèn)為Tonic將駐留在NIC上，取代傳輸協(xié)議硬件實(shí)現(xiàn)中的硬編碼傳輸邏輯(例如，未來的RDMA NIC和TCP卸載引擎)。Tonic為傳輸邏輯提供了一個(gè)統(tǒng)一的可編程架構(gòu)，與不同傳輸協(xié)議的具體實(shí)現(xiàn)如何執(zhí)行連接和數(shù)據(jù)緩沖區(qū)管理以及它們的應(yīng)用層API無關(guān)。然而，我們將以Socket API為例，描述Tonic如何與傳輸層的其余部分交互(§2)，以及如何將其集成到Linux內(nèi)核中以與應(yīng)用程序進(jìn)行交互(§5)。

我們?cè)诩s8000行的Verilog代碼中實(shí)現(xiàn)了Tonic原型，并在不到2 0 0行代碼中實(shí)現(xiàn)各種傳輸協(xié)議的傳輸邏輯，從而證明了Tonic的可編程性。我們還使用FPGA展示了Tonic滿足～100Mpps的時(shí)序，即支持100Gbps的背靠背128B數(shù)據(jù)包。也就是說，每隔10 ns，Tonic可以生成下游DMA流水線獲取和發(fā)送一個(gè)數(shù)據(jù)包所需的傳輸元數(shù)據(jù)。從生成到傳輸，單個(gè)段地址通過Tonic的延遲約為0.1μs，Tonic最多可支持2048個(gè)并發(fā)流。

2. onic作為傳輸邏輯

本節(jié)概述了Tonic如何適應(yīng)傳輸層（§2.1），以及如何克服在高速NIC上實(shí)現(xiàn)傳輸邏輯的挑戰(zhàn)（§2.2）。

>2.1 Tonic如何適應(yīng)傳輸層

位于應(yīng)用程序和堆棧其余部分之間的傳輸層協(xié)議執(zhí)行兩個(gè)主要功能：

連接管理：連接管理包括創(chuàng)建和配置端點(diǎn)(例如，TCP的套接字和RDMA的隊(duì)列對(duì))，并在開始時(shí)建立連接，在結(jié)束時(shí)關(guān)閉連接并釋放其資源。

數(shù)據(jù)傳輸：數(shù)據(jù)傳輸涉及以段流的形式可靠而高效地將數(shù)據(jù)從一個(gè)端點(diǎn)傳輸?shù)搅硪粋€(gè)端點(diǎn)1。不同的傳輸協(xié)議為應(yīng)用程序請(qǐng)求數(shù)據(jù)傳輸提供了不同的API：TCP提供了字節(jié)流的抽象，應(yīng)用程序可以連續(xù)向該字節(jié)流追加數(shù)據(jù)，而在RDMA中，對(duì)隊(duì)列對(duì)的每個(gè)“send”調(diào)用都會(huì)創(chuàng)建單獨(dú)的工作請(qǐng)求，并被視為單獨(dú)的消息。此外，在不同的傳輸協(xié)議實(shí)現(xiàn)中，管理應(yīng)用程序的數(shù)據(jù)緩沖區(qū)的具體情況也有所不同。無論如何，傳輸協(xié)議必須將未完成的數(shù)據(jù)以適合單個(gè)數(shù)據(jù)包的多個(gè)數(shù)據(jù)段形式傳輸?shù)侥康牡?。確定哪些字節(jié)構(gòu)成下一個(gè)數(shù)據(jù)段以及何時(shí)傳輸它是通過數(shù)據(jù)傳輸和擁塞控制算法來完成的，我們統(tǒng)稱為傳輸邏輯并在Tonic中實(shí)現(xiàn)。

圖1顯示了Tonic如何適合硬件網(wǎng)絡(luò)協(xié)議棧的高級(jí)概述。為了將Tonic與連接管理和應(yīng)用級(jí)API的細(xì)節(jié)分離，連接設(shè)置和拆卸需要在Tonic之外運(yùn)行。Tonic依靠傳輸層的其余部分為每個(gè)已建立的連接提供唯一的標(biāo)識(shí)符(流id)，并使用這些ID顯式地添加和刪除連接。

對(duì)于發(fā)送端的數(shù)據(jù)傳輸，Tonic跟蹤未完成的字節(jié)數(shù)和特定于傳輸?shù)脑獢?shù)據(jù)以實(shí)現(xiàn)傳輸邏輯，即在擁塞控制算法指定的時(shí)間為每個(gè)流生成下一個(gè)數(shù)據(jù)段的地址。因此，Tonic不需要存儲(chǔ)和/或處理實(shí)際的數(shù)據(jù)字節(jié)；它依靠傳輸層的其余部分來管理主機(jī)上的數(shù)據(jù)緩沖區(qū)，并在現(xiàn)有連接上有新的數(shù)據(jù)傳輸請(qǐng)求時(shí)通知它(有關(guān)詳細(xì)信息，請(qǐng)參閱§5)。

傳輸邏輯的接收端主要涉及生成控制信號(hào)，如確認(rèn)，每個(gè)數(shù)據(jù)包的授權(quán)令牌或周期性擁塞通知數(shù)據(jù)包（CNP），而傳輸層的其余部分則管理接收數(shù)據(jù)緩沖區(qū)并將接收的數(shù)據(jù)傳輸給應(yīng)用程序。雖然處理接收到的數(shù)據(jù)可能會(huì)相當(dāng)復(fù)雜，但在接收端上生成控制信號(hào)通常比發(fā)送端上更簡(jiǎn)單。因此，雖然我們主要關(guān)注發(fā)送端，但我們重用發(fā)送端的模塊來實(shí)現(xiàn)接收端，僅用于生成每個(gè)數(shù)據(jù)包的累積和選擇性ack，并以線速授予令牌。

>2.2 硬件設(shè)計(jì)挑戰(zhàn)

由于兩個(gè)主要限制，在NIC中以線速實(shí)現(xiàn)傳輸邏輯極具挑戰(zhàn)性：

時(shí)序限制。數(shù)據(jù)中心的數(shù)據(jù)包大小中值小于200字節(jié)。要使這些小數(shù)據(jù)包達(dá)到100Gbps，網(wǎng)卡必須每10 ns發(fā)送一個(gè)數(shù)據(jù)包。因此，每隔10 ns，傳輸邏輯應(yīng)該確定接下來由哪個(gè)活動(dòng)流來傳輸哪個(gè)數(shù)據(jù)段。為了做出該決定，它需要使用每個(gè)流的一些狀態(tài)(例如，已確認(rèn)的數(shù)據(jù)段、重復(fù)的ack、速率/窗口大小等)。當(dāng)各種傳輸事件發(fā)生時(shí)(例如，接收確認(rèn)或超時(shí))，更新這些狀態(tài)。這些更新可能涉及不可忽略的硬件開銷操作，例如搜索位圖和數(shù)組。

為了在處理每個(gè)事件時(shí)有更多的時(shí)間，同時(shí)仍然每隔～10 ns確定下一個(gè)據(jù)段，我們可以設(shè)想將傳輸事件的處理流水線化到跨多個(gè)階段。當(dāng)傳入事件來自不同的流時(shí)，因?yàn)樗鼈兏虏煌臓顟B(tài)使得流水線更容易處理。處理相同流的背靠背事件(例如，在接收確認(rèn)的同時(shí)生成數(shù)據(jù)段)需要更新到相同的狀態(tài)，這使得在確保狀態(tài)一致性的同時(shí)流水線事件處理變得困難。因此，我們努力在10ns內(nèi)處理每個(gè)傳輸事件，而不是快速合并下一個(gè)事件的狀態(tài)，以防它影響相同的流。

內(nèi)存限制：一個(gè)典型的數(shù)據(jù)中心服務(wù)器有超過1000個(gè)并發(fā)活動(dòng)流，其中包含數(shù)千字節(jié)的動(dòng)態(tài)數(shù)據(jù)。由于NIC只有幾兆字節(jié)的高速內(nèi)存，因此傳輸協(xié)議在NIC上的每個(gè)流只能存儲(chǔ)幾千字節(jié)的狀態(tài)。

Tonic的目標(biāo)是滿足這些嚴(yán)格的時(shí)序和內(nèi)存限制，同時(shí)通過簡(jiǎn)單的API支持可編程性。為此，我們確定了各種協(xié)議中傳輸邏輯的通用模式，并將這些模式實(shí)現(xiàn)為可重用的固定功能模塊。這些模式允許我們針對(duì)時(shí)序和內(nèi)存優(yōu)化這些模塊，同時(shí)通過減少用戶必須指定的功能來簡(jiǎn)化API編程。這些模式在表1中進(jìn)行了總結(jié)，并將在下一節(jié)中詳細(xì)討論，在那里我們將描述Tonic的組件以及這些模式如何影響它們的設(shè)計(jì)。

3. Tonic架構(gòu)

發(fā)送端的傳輸邏輯決定了每個(gè)流要傳輸哪些數(shù)據(jù)段（數(shù)據(jù)傳遞）和何時(shí)傳輸（擁塞控制）。從概念上講，擁塞控制算法執(zhí)行credit management，即確定給定流一次可以傳輸多少字節(jié)。數(shù)據(jù)傳輸算法執(zhí)行segment selection，即確定特定流應(yīng)該傳輸哪個(gè)連續(xù)的字節(jié)序列。盡管術(shù)語“數(shù)據(jù)傳輸”和“擁塞控制”通常與基于TCP的傳輸協(xié)議相關(guān)聯(lián)，但Tonic為傳輸邏輯提供了一種通用的可編程架構(gòu)，也可用于其他類型的傳輸協(xié)議，例如接收端驅(qū)動(dòng)和基于RDMA的[8]傳輸協(xié)議。

Tonic利用data delivery和credit management之間天然的功能分離，將它們劃分為具有獨(dú)立狀態(tài)的兩個(gè)組件(圖2)。data delivery引擎處理與數(shù)據(jù)段的生成、跟蹤和傳輸相關(guān)的事件，而credit引擎處理與調(diào)整每個(gè)流的信用并為具有足夠信用的流發(fā)送段地址相關(guān)的事件。

以兩個(gè)引擎之間的輕量級(jí)協(xié)調(diào)為代價(jià)，這種劃分方式幫助Tonic在每個(gè)周期同時(shí)處理多個(gè)事件(例如，接收確認(rèn)和段傳輸)的同時(shí)滿足其時(shí)序限制。這些事件必須讀取其相應(yīng)流的當(dāng)前狀態(tài)，對(duì)其進(jìn)行更新，并將其寫回內(nèi)存以便在下一周期中處理事件。然而，在每個(gè)周期中對(duì)內(nèi)存的并發(fā)讀寫成本很高。與使用寬內(nèi)存來服務(wù)所有傳輸事件不同，分區(qū)允許data delivery和credit engines使用更窄的內(nèi)存來服務(wù)于與其特定功能相關(guān)的事件，從而滿足時(shí)間限制。

在本節(jié)中，我們將在§3.1中介紹引擎如何協(xié)調(diào)，在保持輸出鏈路利用率的同時(shí)，公平有效地從每個(gè)周期的幾千個(gè)流中挑選一個(gè)流進(jìn)行分段傳輸。接下來，§3.2和§3.3描述了每個(gè)引擎中的固定功能和可編程事件處理模塊，以及它們的設(shè)計(jì)是如何從表1中的模式中獲得靈感的。我們?cè)凇?.4中介紹了Tonic在一個(gè)循環(huán)中接收到同一流的多個(gè)事件時(shí)解決沖突的解決方案，并在§3.5中介紹了它的編程接口。

>3.1 高效的流調(diào)度

在任何時(shí)候，如果它(1)有足夠的信用并且(2)有新的或丟失的數(shù)據(jù)段要發(fā)送時(shí)，一個(gè)流只能傳輸一個(gè)數(shù)據(jù)段。為了節(jié)省工作量，Tonic必須跟蹤符合傳輸條件的流集合(滿足上述兩個(gè)標(biāo)準(zhǔn))，并且在每個(gè)周期選擇要傳輸?shù)牧鲿r(shí)僅在這些流中進(jìn)行選擇。要有效地做到這一點(diǎn)很有挑戰(zhàn)性。我們有超過1000多個(gè)流，它們的狀態(tài)分布在兩個(gè)引擎上：只有信用引擎知道每個(gè)流有多少信用，只有數(shù)據(jù)傳輸引擎知道流的段的狀態(tài)，并且可以生成它的下一個(gè)段的地址。我們不能通過在每個(gè)循環(huán)中檢查兩個(gè)引擎的所有流的狀態(tài)來找到在該循環(huán)中符合傳輸條件的流。

相反，我們將段地址的生成與它們最終傳輸?shù)紻MA流水線的過程解耦。我們?cè)试S數(shù)據(jù)傳遞引擎為一個(gè)流生成最多N個(gè)段地址，而不必有足夠的信用將它們發(fā)送出去。在信用引擎中，我們?yōu)槊總€(gè)流保留一個(gè)大小為N的環(huán)形緩沖區(qū)來存儲(chǔ)這些未完成的段地址。當(dāng)流有足夠的信用來發(fā)送一個(gè)段時(shí)，信用引擎從緩沖區(qū)退出隊(duì)列并輸出一個(gè)段地址，并向數(shù)據(jù)傳輸引擎發(fā)送信號(hào)以減少該流中未完成段的數(shù)量。

這解決了兩個(gè)引擎之間的分區(qū)狀態(tài)問題。數(shù)據(jù)傳輸引擎不需要跟蹤流的信用變化來生成段地址。僅當(dāng)段地址從緩沖區(qū)出列時(shí)才需要通知它。此外，信用引擎不需要知道所有流段的確切狀態(tài)。如果流的環(huán)形緩沖區(qū)為空，則該流沒有要發(fā)送的段。否則，當(dāng)流有足夠的信用時(shí)，已經(jīng)有可以輸出的段地址。

不過，數(shù)據(jù)傳輸引擎不能簡(jiǎn)單地在每個(gè)周期檢查所有流的狀態(tài)，以確定哪些流可以生成段。相反，我們?cè)跀?shù)據(jù)傳輸引擎中動(dòng)態(tài)維護(hù)活動(dòng)流集，即該流至少要有一個(gè)要生成的段且未完成段少于N個(gè) (參見圖2中的紅色編號(hào)圓圈)。當(dāng)創(chuàng)建一個(gè)流時(shí)，會(huì)將其添加到活動(dòng)集中。每個(gè)周期，從集合中選擇并移除一個(gè)流以用于段生成(步驟1)。一旦被處理(步驟2)，只有當(dāng)它有更多的數(shù)據(jù)段要發(fā)送并且少于N個(gè)未完成的數(shù)據(jù)段時(shí)，它才會(huì)被插回集合中(步驟3)。否則，如果稍后接收到來自信用引擎的ack或信號(hào)激活了流程，則將其插入到集合中(步驟9)。此外，生成的段地址被轉(zhuǎn)發(fā)到信用引擎(步驟4)，用于插入環(huán)形緩沖區(qū)(步驟5)。

類似地，信用引擎維護(hù)準(zhǔn)備傳輸流的集合，即在其環(huán)形緩沖區(qū)中具有一個(gè)或多個(gè)段地址的流，并且有足夠的信用將至少一個(gè)段發(fā)送出去。每個(gè)周期，從集合中選擇一個(gè)流(步驟6)，發(fā)送來自其環(huán)形緩沖區(qū)中的一個(gè)段地址(步驟7)，減少其信用，并且如果它有更多的段地址和信用用于進(jìn)一步傳輸，則將其插回集合中(步驟8)。它還向數(shù)據(jù)傳輸引擎發(fā)送關(guān)于傳輸?shù)男盘?hào)(步驟9)，以減少該流中未完成段的數(shù)量。

為了公平起見，當(dāng)從活動(dòng)(或準(zhǔn)備傳輸)集合中挑選流時(shí)，Tonic使用FIFO在集合中的流之間實(shí)現(xiàn)循環(huán)調(diào)度。循環(huán)調(diào)度的選擇不是最基本的；任何其他滿足我們的時(shí)序約束的調(diào)度器都可以取代FIFO來支持其他調(diào)度規(guī)則。

>3.2 靈活的段選擇

對(duì)于B字節(jié)的信用，一個(gè)流可以發(fā)送S = max（B，MSS）字節(jié)，其中MSS是最大段的大小。在傳輸協(xié)議中，數(shù)據(jù)傳輸算法使用確認(rèn)來跟蹤數(shù)據(jù)每個(gè)字節(jié)的狀態(tài)（例如，已傳輸、丟失、正在傳輸和未傳輸），并使用該狀態(tài)來決定下一步傳輸哪個(gè)連續(xù)的S字節(jié)數(shù)據(jù)。

然而，在高速NIC中實(shí)現(xiàn)數(shù)據(jù)傳輸算法有兩個(gè)主要挑戰(zhàn)。首先，由于內(nèi)存限制，NIC無法存儲(chǔ)每個(gè)字節(jié)的信息。其次，除了少數(shù)例外，這些算法是為軟件設(shè)計(jì)的，在軟件中，它們可以存儲(chǔ)并自由循環(huán)使用大量元數(shù)據(jù)來聚合信息。這種計(jì)算靈活性在這些算法中創(chuàng)造了顯著的多樣性。不過由于NIC硬件比軟件更受約束，因此我們并不打算支持所有的數(shù)據(jù)傳輸算法，而是在尋找能夠在各種算法中通用，同時(shí)也適合硬件實(shí)現(xiàn)的模式。

· 預(yù)先計(jì)算的固定段邊界

數(shù)據(jù)傳輸算法可以從數(shù)據(jù)流中的任何位置選擇要發(fā)送的下一個(gè)字節(jié)，并生成具有可變邊界的段。但是，由于NIC無法保持每個(gè)字節(jié)狀態(tài)，因此當(dāng)流請(qǐng)求傳輸新數(shù)據(jù)時(shí)，Tonic要求將數(shù)據(jù)劃分為固定大小的段（通過內(nèi)核模塊或驅(qū)動(dòng)程序，參見§5）。這樣，數(shù)據(jù)傳輸算法可以使用分段信息來選擇下一段。

注意，可以根據(jù)每個(gè)流的吞吐量和延遲需求為每個(gè)流配置固定的段大小。對(duì)于基于消息的傳輸協(xié)議（例如RoCEv2），具有固定的段邊界自然適合；消息長度是已知的，可以從一開始就選擇最佳的段大小。對(duì)于具有字節(jié)流抽象的協(xié)議（例如TCP和NDP），固定段大小應(yīng)在數(shù)據(jù)添加到流中時(shí)即時(shí)確定。對(duì)于高帶寬數(shù)據(jù)流，可以將其設(shè)置為MSS（如果使用TSO[18]，則設(shè)置為更大）。對(duì)于偶爾生成小數(shù)據(jù)段的流，可以將段大小設(shè)置為較小的值，這取決于是在通知Tonic之前將多個(gè)小段合并為一個(gè)較大的段，還是立即傳輸小段（§5）。無論如何，為了避免在NIC上存儲(chǔ)每個(gè)字節(jié)的狀態(tài)，段大小應(yīng)該在Tonic之外決定，并且不經(jīng)常更改。

· 有限窗口中每小段狀態(tài)

不同于流的可用信用，如果一個(gè)新段距離第一個(gè)未確認(rèn)的段超過K個(gè)段，數(shù)據(jù)傳輸算法通常不會(huì)傳輸該新段，以限制發(fā)送端和接收端需要保持的狀態(tài)2。但是，在具有10μs RTT的100 Gbps網(wǎng)絡(luò)中，K可以達(dá)到約128個(gè)段。幸運(yùn)的是，我們觀察到對(duì)于大多數(shù)的數(shù)據(jù)傳輸算法來說存儲(chǔ)以下每段狀態(tài)就足夠了：（1）段是否已確認(rèn)（存在選擇性確認(rèn)）？（2） 如果沒有，它是丟失了還是還在傳輸中？（3） 如果丟失，是否已重新傳輸（避免冗余重傳）？

更具體地說，我們觀察到在沒有明確的否定確認(rèn)的情況下，數(shù)據(jù)傳輸算法從肯定確認(rèn)中為每個(gè)段積累丟失的證據(jù)，例如重復(fù)累積（例如，TCP NewReno[23]）或選擇性ack（例如，RDMA和TCP SACK的IRN [16]）。一旦某個(gè)段的累積證據(jù)超過閾值，該算法就可以自信地宣布該片段丟失。通常，段i的丟失證據(jù)也是每個(gè)未確認(rèn)的段j（j

· 并發(fā)事件處理

對(duì)于每個(gè)流，有四個(gè)主要事件會(huì)影響其下一個(gè)段地址的生成。首先，接收到確認(rèn)可以向前移動(dòng)窗口并使流能夠生成更多的段，或者發(fā)送信號(hào)段丟失并觸發(fā)重傳。第二，沒有確認(rèn)（即超時(shí)）也可能導(dǎo)致更多的段被標(biāo)記為丟失并觸發(fā)重傳。第三，段地址的生成會(huì)增加流的未完成段的數(shù)量，如果超過N，則可以停用該流。第四，段地址傳輸（除credit引擎外）減少了未完成段的數(shù)量，可以使流生成更多的段地址。

Tonic的數(shù)據(jù)傳輸引擎有四個(gè)模塊來處理這四個(gè)事件（圖2）。每個(gè)周期，每個(gè)模塊從數(shù)據(jù)傳輸引擎中的內(nèi)存中讀取其接收到處理事件的流狀態(tài)，并相應(yīng)地更新流狀態(tài)。數(shù)據(jù)傳輸引擎中的流狀態(tài)包括一組固定的變量，用于跟蹤跨事件段的當(dāng)前窗口的狀態(tài)，以及可編程組件中使用的用戶定義變量（表2）。作為固定狀態(tài)變量的一個(gè)示例，Tonic為每個(gè)流保留了一組固定的位圖（見§3.2.2）：ack位圖跟蹤選擇性確認(rèn)的段，marked-for-rtx跟蹤需要重傳的丟失段，rtx-cnt存儲(chǔ)有關(guān)其先前重新傳輸?shù)男畔ⅰ?/p>

以下段落簡(jiǎn)要描述了每個(gè)事件處理模塊如何影響流的狀態(tài)，以及是否存在我們可以利用的通用模式，以固定功能的方式實(shí)現(xiàn)其全部或部分功能。

輸入。該模塊處理確認(rèn)過程（和其他輸入數(shù)據(jù)包，見§3.3.3）。響應(yīng)確認(rèn)的狀態(tài)變量的一些更新在所有數(shù)據(jù)傳輸算法中都是類似的，并且不需要編程（例如，更新窗口邊界，并在ack位圖中標(biāo)記選擇性確認(rèn)的段，見§3.2.2），而依賴于確認(rèn)作為信號(hào)的丟失檢測(cè)和恢復(fù)，不同算法之間的差異很大，必須由用戶進(jìn)行編程（表1中的#4）。因此，輸入模塊被設(shè)計(jì)為兩級(jí)流水線：一個(gè)用于公共更新的固定功能階段，另一個(gè)用于丟失檢測(cè)和恢復(fù)的可編程階段。

這種兩階段設(shè)計(jì)的好處是常見的更新主要涉及位圖和數(shù)組（§3.2.2），而它們?cè)谟布斜粚?shí)現(xiàn)為環(huán)形緩沖區(qū)，并且跨元素修改的成本很高。例如，在所有數(shù)據(jù)傳輸算法中，如果一個(gè)輸入數(shù)據(jù)包累計(jì)確認(rèn)了段A，并有選擇性地確認(rèn)段S，則wnd-start將會(huì)被更新為max（wnd-start，A），acked[s]為1，并且所有位圖和數(shù)組的邊界將根據(jù)新的wnd-start進(jìn)行更新。通過將這些更新轉(zhuǎn)移到一個(gè)固定的功能階段，我們可以（i）優(yōu)化它們以滿足Tonic的時(shí)序和內(nèi)存限制，（ii）為程序員提供一個(gè)專用階段，即一個(gè)獨(dú)立的周期，用于進(jìn)行丟失檢測(cè)和恢復(fù)。在這個(gè)專門階段，程序員可以使用前一階段更新的狀態(tài)變量和內(nèi)存中的其余變量來推斷段丟失（并執(zhí)行§3.3.3中討論的其他用戶定義的計(jì)算）。

定期更新。數(shù)據(jù)傳輸引擎對(duì)活動(dòng)流進(jìn)行迭代，每次發(fā)送一個(gè)到該模塊，以檢查重傳計(jì)時(shí)器是否過期，并執(zhí)行其他用戶定義的定期更新（§3.3.3）。因此，憑借其10 ns的時(shí)鐘周期，Tonic可以在其重傳計(jì)時(shí)器到期后的幾u(yù)s內(nèi)覆蓋每個(gè)流。該模塊必須是可編程的，因?yàn)橹貍鞒瑫r(shí)是用于檢測(cè)丟失的信號(hào)（表1中的#4）。與輸入模塊的可編程階段類似，程序員可以使用每個(gè)流的狀態(tài)變量來推斷段損失。

段生成。給定一個(gè)活動(dòng)流及其變量，該模塊生成下一個(gè)段的地址并將其轉(zhuǎn)發(fā)給信用引擎。Tonic根據(jù)以下觀察結(jié)果（表1中的#3）可以將段地址生成作為一個(gè)固定的功能模塊來實(shí)現(xiàn)：盡管不同的可靠數(shù)據(jù)傳輸算法有不同的方法來推斷段丟失，但一旦檢測(cè)到丟失的段，在發(fā)送任何新的數(shù)據(jù)之前重新傳輸它是合乎邏輯的。因此，無論數(shù)據(jù)傳輸算法如何，選擇下一段的過程都是相同的，并且在Tonic中作為一個(gè)固定功能模塊來實(shí)現(xiàn)。因此，該模塊優(yōu)先重發(fā)marked-for-rtx中丟失的段，而不是發(fā)送下一個(gè)新的段，即highest_sent+1，同時(shí)也增加了未完成段的數(shù)量。

數(shù)據(jù)段傳輸。該模塊為固定功能，在從信用引擎?zhèn)鬏敹蔚刂窌r(shí)觸發(fā)。它減少了相應(yīng)流中未完成段的數(shù)量。如果流由于環(huán)形緩沖區(qū)滿了而被停用，則會(huì)再次將其插入活動(dòng)集中。

>3.3 靈活的信用管理

傳輸協(xié)議使用擁塞控制算法，通過控制流的傳輸速度來避免網(wǎng)絡(luò)過載。這些算法包括一個(gè)控制回路，該回路通過監(jiān)測(cè)輸入控制數(shù)據(jù)包流（例如，確認(rèn)和擁塞通知數(shù)據(jù)包（CNP））來估計(jì)網(wǎng)絡(luò)容量，并設(shè)置限制輸出數(shù)據(jù)包的參數(shù)。雖然控制回路在許多算法中有所不同，但基于參數(shù)的信用計(jì)算卻不盡相同。Tonic具有用于信用計(jì)算的高效固定功能模塊（§3.3.1和§3.3.2），并將參數(shù)調(diào)整歸入可編程模塊（§3.3.3）。

· 常用的信用計(jì)算模式

擁塞控制算法有多種方法來估計(jì)網(wǎng)絡(luò)容量。然而，它們通過三種主要方式（表1中的#5）對(duì)數(shù)據(jù)傳輸進(jìn)行限制：

擁塞窗口?？刂苹芈废拗屏艘粋€(gè)流從第一個(gè)未確認(rèn)的字節(jié)開始，最多只能飛行W個(gè)字節(jié)。因此，如果字節(jié)i是第一個(gè)未確認(rèn)的字節(jié)，則流不能發(fā)送超過i +W的字節(jié)。跟蹤飛行中的段以執(zhí)行擁塞窗口可能會(huì)變得復(fù)雜（例如，存在選擇性確認(rèn)的情況下）并在數(shù)據(jù)傳輸引擎中傳入模塊的固定功能階段實(shí)現(xiàn)。

速率?？刂苹芈废拗屏鞯钠骄俾剩≧）和最大突發(fā)大?。―）。因此，如果流在最后一次傳輸?shù)膖0時(shí)間具有信用c0，則在時(shí)間t時(shí)的信用將為min（R?（t?t0）+c0，D）。正如我們?cè)凇?中所示，在嚴(yán)格的時(shí)序和內(nèi)存約束下實(shí)現(xiàn)精確的單流速率限制是一項(xiàng)具有挑戰(zhàn)性的任務(wù)，而在Tonic中有一個(gè)優(yōu)化的固定功能實(shí)現(xiàn)。

授權(quán)令牌。控制回路從接收端接收令牌并將其添加到流的信用中，而不是估計(jì)網(wǎng)絡(luò)容量。因此，一個(gè)流的信用是接收的令牌總數(shù)減去傳輸?shù)淖止?jié)數(shù)，信用計(jì)算邏輯由簡(jiǎn)單的加法組成。

由于大多數(shù)擁塞控制算法都使用這些算法3，因此我們優(yōu)化了它們的實(shí)現(xiàn)，以滿足Tonic的時(shí)序和內(nèi)存約束。擁塞窗口的計(jì)算主要受ack的影響。因此，擁塞窗口的計(jì)算和實(shí)施發(fā)生在數(shù)據(jù)傳輸引擎中。對(duì)于其他兩個(gè)信用計(jì)算方案，信用引擎處理與信用相關(guān)事件，用戶可以簡(jiǎn)單地選擇在信用引擎中使用哪個(gè)方案。

· 信用計(jì)算的事件處理

從概念上講，有三個(gè)主要事件可以觸發(fā)流的信用計(jì)算，信用引擎有不同的模塊可以在每個(gè)周期內(nèi)并發(fā)處理它們（圖2）。首先，當(dāng)從數(shù)據(jù)傳輸引擎接收到一個(gè)段地址并且該段地址是流的環(huán)形緩沖區(qū)中的唯一地址時(shí)，流現(xiàn)在可以根據(jù)其信用（排隊(duì)模塊）進(jìn)行傳輸或保持空閑。第二，當(dāng)一個(gè)流傳輸一個(gè)段地址時(shí)，它的信用度必須降低，我們應(yīng)該根據(jù)它更新的信用度和它的環(huán)形緩沖區(qū)（傳輸模塊）的占用情況來確定它是否有資格再次傳輸。第三，可以向流中添加信用的事件（例如，來自授權(quán)令牌和泄露速率限制），這是基于速率和基于令牌的信用計(jì)算之間的主要區(qū)別。

當(dāng)使用授權(quán)令牌時(shí)，信用引擎需要兩個(gè)專用模塊來增加流的信用：一個(gè)用于處理來自接收端的輸入授權(quán)令牌，另一個(gè)用于增加超時(shí)重傳的信用。當(dāng)基于速率時(shí)，信用引擎不需要任何額外的模塊來增加信用，因?yàn)樗俾蕿镽字節(jié)/周期的流在每個(gè)周期內(nèi)隱式地獲得R字節(jié)的信用，因此，我們可以提前計(jì)算它何時(shí)符合傳輸條件。

假設(shè)在周期T0中，傳輸模塊從流f中發(fā)送了一個(gè)段，并且正在判斷該流是否符合進(jìn)一步發(fā)送的條件。假設(shè)f在環(huán)形緩沖區(qū)中有更多的段，但缺少L字節(jié)的信用。當(dāng)T=L/R，傳輸模塊可以計(jì)算何時(shí)有足夠的信用，并為T周期設(shè)置一個(gè)計(jì)時(shí)器。當(dāng)計(jì)時(shí)器到期時(shí)，f至少有一個(gè)段有足夠的信用，因此它可以直接插入ready-to-tx。當(dāng)f到達(dá)ready-to-tx的頭部并在T1周期中再次由傳輸模塊處理時(shí)，傳輸模塊可以將f的信用增加（T1?T0）? R?S，其中S是在時(shí)間T1時(shí)傳輸?shù)亩蔚拇笮?。請(qǐng)注意，在使用速率時(shí)，信用引擎必須執(zhí)行分割并維護(hù)單流計(jì)時(shí)器。我們將在§4中討論這些操作的硬件實(shí)現(xiàn)。

· 靈活的參數(shù)調(diào)整

擁塞控制算法通常有一個(gè)控制回路，該回路持續(xù)監(jiān)測(cè)網(wǎng)絡(luò)并根據(jù)估計(jì)的網(wǎng)絡(luò)容量調(diào)整信用計(jì)算參數(shù)，即速率或窗口大小。參數(shù)調(diào)整要么由輸入的數(shù)據(jù)包（例如，確認(rèn)和它們的信號(hào)，如TCP變體中的ECN或延遲以及Timely，以及DCQCN中的擁塞通知數(shù)據(jù)包（CNP））觸發(fā)，要么由周期性計(jì)時(shí)器和計(jì)數(shù)器觸發(fā)（TCP變體和字節(jié)計(jì)數(shù)器中的超時(shí)，以及DCQCN中的各種計(jì)時(shí)器），在某些情況下，也受到段丟失的觸發(fā)（TCP中重復(fù)確認(rèn)后的窗口調(diào)整）。

針對(duì)這些觸發(fā)器， Tonic的用戶可以使用“Incoming”模塊的可編程平臺(tái)(該模塊可以查看所有輸入數(shù)據(jù)包)以及定時(shí)器和計(jì)數(shù)器的“Periodic Updates”模塊來指定參數(shù)調(diào)整邏輯。這兩個(gè)模塊都位于數(shù)據(jù)傳輸引擎中，可以訪問段狀態(tài)信息，以防參數(shù)調(diào)整需要段狀態(tài)（如掉線）。更新后的參數(shù)將轉(zhuǎn)發(fā)到信用引擎。

如§6.1.1所示。我們?cè)赥onic中實(shí)現(xiàn)了幾種擁塞控制算法，它們的參數(shù)調(diào)整計(jì)算在我們的10 ns時(shí)鐘周期內(nèi)完成。那些使用整數(shù)運(yùn)算的算法不需要做任何修改。對(duì)于那些具有浮點(diǎn)運(yùn)算的操作，例如DCQCN，我們使用整數(shù)運(yùn)算將其近似為某個(gè)小數(shù)點(diǎn)。如果一個(gè)算法需要高精度和復(fù)雜的浮點(diǎn)運(yùn)算來調(diào)整參數(shù)，而又不能在一個(gè)時(shí)鐘周期內(nèi)實(shí)現(xiàn)[19]，則可以將計(jì)算交給Tonic之外的浮點(diǎn)運(yùn)算模塊。該模塊可以執(zhí)行異步計(jì)算，并將輸出存儲(chǔ)在單獨(dú)的內(nèi)存中，該內(nèi)存通過“周期性更新”模塊合并到Tonic中。

>3.4 處理沖突事件

Tonic力求同時(shí)處理事件，以便對(duì)事件作出反應(yīng)。因此，如果一個(gè)流在同一個(gè)周期中接收到多個(gè)事件，它允許事件處理模塊處理事件并更新流的狀態(tài)變量，并在將其寫回內(nèi)存之前協(xié)調(diào)狀態(tài)（圖2中的合并模塊）。

根據(jù)定義，由于確認(rèn)和重傳超時(shí)是互斥的。因此，如果在同一周期內(nèi)接收到對(duì)同一流的確認(rèn)和超時(shí)，則Tonic將丟棄超時(shí)。這大大簡(jiǎn)化了合并邏輯，因?yàn)閹讉€(gè)變量（窗口大小和重傳計(jì)時(shí)器周期）僅由這兩個(gè)事件修改，因此永遠(yuǎn)不會(huì)同時(shí)更新。我們可以使用簡(jiǎn)單的、預(yù)定義的合并邏輯來解決剩余變量的并發(fā)更新。例如，段生成增加未完成段的數(shù)量，而段傳輸減少未完成段的數(shù)量；如果兩個(gè)事件同時(shí)影響同一個(gè)流，則數(shù)字不會(huì)更改。用戶定義的變量在Incoming或Periodic Updates模塊中更新，如果兩個(gè)更新發(fā)生在同一個(gè)周期中，我們依賴程序員來指定哪些更新的變量應(yīng)該優(yōu)先。

>3.5 Tonic的編程接口

為了在Tonic中實(shí)現(xiàn)新的傳輸邏輯，程序員只需指定（i）使用三種信用管理方案中的哪一種，（ii）響應(yīng)確認(rèn)和超時(shí)的丟失檢測(cè)和恢復(fù)邏輯，以及（iii）響應(yīng)輸入數(shù)據(jù)包或周期計(jì)時(shí)器和計(jì)數(shù)器的擁塞控制參數(shù)調(diào)整。第一個(gè)用于為信用引擎選擇合適的模塊，最后兩個(gè)插入到數(shù)據(jù)傳輸引擎的相應(yīng)可編程階段（圖2）。

為了指定Incoming模塊的可編程階段的邏輯，程序員需要編寫一個(gè)函數(shù)，該函數(shù)接收輸入數(shù)據(jù)包（ack或其他控制信號(hào)）、新確認(rèn)的段數(shù)、用ack中的信息更新的ack位圖、wnd- start的新舊值（以防窗口因新的累積ack而向前移動(dòng)），以及流的其余狀態(tài)變量（表2）作為輸入。在輸出中，它們可以在marked-for-rtx中標(biāo)記要重傳的段范圍，更新?lián)砣刂茀?shù)，如窗口大小和速率，并重置重傳計(jì)時(shí)器。周期性更新模塊的編程接口等等。

在指定這些函數(shù)時(shí)，程序員可以使用整數(shù)算術(shù)運(yùn)算（例如，帶有小寬度操作數(shù)是加減乘除）和有限的只讀位圖操作集（例如，索引查找），并在更新的ack位圖中查找第一個(gè)設(shè)置位（示例程序見附錄F）。請(qǐng)注意，數(shù)據(jù)傳輸引擎中的一個(gè)專用固定功能階段在收到ack時(shí)執(zhí)行代價(jià)高昂的通用位圖更新（§3.2.3）。我們?cè)凇?.1.1中說明了可以使用此接口實(shí)現(xiàn)多種傳輸協(xié)議，并舉出了一些不能實(shí)現(xiàn)的示例。

4. 硬件實(shí)現(xiàn)

在本節(jié)中，我們描述了在Tonic嚴(yán)格的時(shí)序和內(nèi)存約束下最難實(shí)現(xiàn)的Tonic組件的硬件設(shè)計(jì)。

高精度的單流速率限制。在T=L/R周期中，一個(gè)具有每周期速率為R字節(jié)和要發(fā)送L字節(jié)的流將具有足夠的信用用于傳輸。Tonic需要在信用引擎中執(zhí)行此計(jì)算，但必須將R表示為一個(gè)整數(shù)，因?yàn)樗鼰o法進(jìn)行浮點(diǎn)除法。這在速率限制精度和Tonic可以支持的速率范圍之間進(jìn)行了權(quán)衡。如果R以字節(jié)/周期為單位，則我們不能支持低于1字節(jié)/周期或～1 Gbps的速率。如果我們用每千個(gè)周期的字節(jié)數(shù)表示R，我們可以支持低至1 Mbps的速率。然而，T=L/ R決定了從現(xiàn)在開始該流有多少個(gè)周期有資格傳輸，這導(dǎo)致較高帶寬流的速率一致性和精度較低。為了在不犧牲精度的情況下支持大范圍的速率，Tonic在不同的精度級(jí)別保留了流的多種表示形式，并在任何時(shí)刻挑選最精確的表示來計(jì)算T(詳情見附錄B)。

高效的位圖操作。Tonic使用高達(dá)128位的位圖來跟蹤每個(gè)流的段狀態(tài)。位圖以環(huán)形緩沖區(qū)的形式實(shí)現(xiàn)。頭指針對(duì)應(yīng)于第一個(gè)未確認(rèn)的段，并使用新的ack沿著緩沖區(qū)向前移動(dòng)。為了有效地實(shí)現(xiàn)其輸出取決于位圖中所有位的值的操作，我們必須將緩沖區(qū)分成多層的小部分，并行處理它們，并連接結(jié)果。在Tonic中經(jīng)常使用的一種這樣的操作是查找報(bào)頭之后的第一個(gè)設(shè)置位。環(huán)形緩沖區(qū)中報(bào)頭的移動(dòng)使該操作的實(shí)現(xiàn)變得復(fù)雜，因?yàn)楦櫭繉又械膱?bào)頭需要額外的處理，使得它很難在我們的10 ns目標(biāo)內(nèi)進(jìn)行計(jì)算。相反，Tonic在輸入環(huán)形緩沖區(qū)上使用輕量級(jí)預(yù)處理，以完全避免各層中的報(bào)頭索引計(jì)算(詳細(xì)信息見附錄C)。

并行內(nèi)存訪問。在每個(gè)周期中，數(shù)據(jù)傳輸引擎中的五個(gè)模塊(包括Incoming模塊的兩段)同時(shí)訪問其內(nèi)存(§3.2.3)。然而，F(xiàn)PGA只有雙端口RAM存儲(chǔ)器，每個(gè)端口在每個(gè)周期都能進(jìn)行讀或?qū)?。?gòu)建具有更多并發(fā)讀、寫的存儲(chǔ)器需要在單獨(dú)的存儲(chǔ)器“分塊”中保存數(shù)據(jù)的多個(gè)副本，并跟蹤分塊中每個(gè)地址的最新數(shù)據(jù)5。為了避免支持五個(gè)并發(fā)讀寫，我們?cè)O(shè)法將每個(gè)流的狀態(tài)變量劃分為兩個(gè)組，每個(gè)組最多處理四個(gè)事件。因此，Tonic可以使用兩個(gè)具有四個(gè)讀寫端口的存儲(chǔ)器，而不是單個(gè)具有五個(gè)端口的存儲(chǔ)器，同時(shí)為所有處理模塊提供并發(fā)訪問。

5. 將Tonic集成到傳輸層

Tonic的傳輸邏輯有意與其他傳輸功能(如連接管理、應(yīng)用級(jí)API和緩沖區(qū)管理)的具體實(shí)現(xiàn)相分離。本節(jié)提供一個(gè)示例，說明Tonic如何與Linux內(nèi)核交互，以了解新連接、數(shù)據(jù)傳輸請(qǐng)求和連接終止6。創(chuàng)建套接字后，應(yīng)用程序使用各種系統(tǒng)調(diào)用進(jìn)行連接管理和數(shù)據(jù)傳輸。由于Tonic主要關(guān)注傳輸邏輯的發(fā)送端，因此我們只討論與傳輸層的發(fā)送端相關(guān)的系統(tǒng)調(diào)用和修改。

連接管理。客戶端上的connect()發(fā)起連接，服務(wù)器上的listen()和accept()監(jiān)測(cè)并接受連接，close()終止連接。由于連接管理發(fā)生在Tonic之外，因此這些系統(tǒng)調(diào)用的內(nèi)核實(shí)現(xiàn)保持不變。但是，一旦連接建立，內(nèi)核會(huì)將其映射到[0，N)中的唯一flow id，其中N是Tonic支持的最大流數(shù)，并通過NIC驅(qū)動(dòng)程序通知Tonic關(guān)于新連接。

具體地說，通過內(nèi)核中連接的Transmission Control Block (TCB)，通信終端的IP地址和端口與為連接選擇的flow id和固定段大小一起發(fā)送到Tonic。內(nèi)核只需要跟蹤用于連接管理的TCB字段(例如，IP地址、端口和TCP FSM)、數(shù)據(jù)緩沖區(qū)的指針以及與接收器相關(guān)的字段。發(fā)送端上用于數(shù)據(jù)傳輸?shù)淖侄?即snd.nxt、snd.una和snd.wnd)存儲(chǔ)在Tonic中并由Tonic處理。最后，在調(diào)用close()之后，內(nèi)核使用該連接的flow id通知Tonic終止。

數(shù)據(jù)傳輸。send（）將數(shù)據(jù)添加到連接的套接字緩沖區(qū)，該緩沖區(qū)存儲(chǔ)等待傳輸?shù)奈赐瓿蓴?shù)據(jù)。Tonic為未完成的數(shù)據(jù)保留幾比特的每段狀態(tài)，并以段執(zhí)行所有傳輸邏輯計(jì)算。因此，在Tonic開始傳輸之前，數(shù)據(jù)應(yīng)該被劃分為同等大小的段（§3.2）。因此，對(duì)send（）的修改主要涉及根據(jù)連接配置的段大小來確定套接字緩沖區(qū)中數(shù)據(jù)的段邊界，并決定何時(shí)將新段通知Tonic。具體來說，內(nèi)核除了頭部和尾部外，還為每個(gè)連接的套接字緩沖區(qū)保留一個(gè)額外的指針，稱為tonic-tail。它指向已通知Tonic的最后一段。head和tonic-tail的更新被發(fā)送給Tonic，以便在生成下一段地址時(shí)從內(nèi)存中獲取。

從一個(gè)空的套接字緩沖區(qū)開始，當(dāng)應(yīng)用程序調(diào)用send()時(shí)，數(shù)據(jù)被復(fù)制到套接字緩沖區(qū)，tail也相應(yīng)地更新。假設(shè)連接配置的段大小為C，那么數(shù)據(jù)就會(huì)被分割成C大小的段。假設(shè)數(shù)據(jù)被分割成S個(gè)段和B（B

如果在時(shí)間T之后沒有足夠的數(shù)據(jù)用于C大小的段，內(nèi)核需要通知Tonic“子段”(小于C的段)及其大小，并相應(yīng)地更新Tonic-Tail。注意，Tonic要求除突發(fā)事件中的最后一個(gè)數(shù)據(jù)段外的所有數(shù)據(jù)段的大小相同，因?yàn)樗杏?jì)算(包括窗口更新)都是以數(shù)據(jù)段為單位的。因此，在創(chuàng)建一個(gè)“子段”之后，如果應(yīng)用程序有更多數(shù)據(jù)，Tonic只有在完成當(dāng)前段的傳輸后才能開始傳輸。Tonic在成功傳輸最后一個(gè)“子段”后通知內(nèi)核，此時(shí)head和tonic-Tail將會(huì)相等，內(nèi)核繼續(xù)對(duì)套接字緩沖區(qū)中的剩余數(shù)據(jù)進(jìn)行分區(qū)，并像以前一樣更新Tonic。注意，Tonic可以使用可配置的頻率周期地向內(nèi)核轉(zhuǎn)發(fā)確認(rèn)信息，使head向前移動(dòng)，為套接字緩沖區(qū)的新數(shù)據(jù)騰出空間。

可以根據(jù)每個(gè)流的延遲和吞吐量特性為其配置C和T。對(duì)于高帶寬流，可以將C設(shè)置為MSS(如果使用TSO，則設(shè)置為更大)。對(duì)于零星產(chǎn)生小段的流，設(shè)置C和T不是那么直接，因?yàn)槎尾荒茉赥onic內(nèi)合并。我們?cè)诟戒汥中詳細(xì)討論了決定這些參數(shù)的權(quán)衡問題。

其他考慮事項(xiàng)。如§6所示，Tonic當(dāng)前的設(shè)計(jì)支持2048個(gè)并發(fā)流，與數(shù)據(jù)中心[15，37]中觀察到的工作集以及文獻(xiàn)[20]中的其他硬件負(fù)載相匹配。如果一個(gè)主機(jī)的開放連接超過Tonic所能支持的數(shù)量，內(nèi)核可以按照先到先得的原則將數(shù)據(jù)流的數(shù)據(jù)傳輸分流到Tonic，或者讓用戶在創(chuàng)建套接字時(shí)設(shè)置標(biāo)志，并在Tonic耗盡新流的資源后回退到軟件。另外，現(xiàn)代基于FPGA的網(wǎng)卡有一個(gè)大的DRAM直接連接到FPGA[20]。DRAM可以用來存儲(chǔ)更多連接的狀態(tài)，并在它們激活和需要傳輸數(shù)據(jù)時(shí)將它們來回交換到Tonic的內(nèi)存中。此外，為了提供對(duì)硬件傳輸邏輯性能的可見性，Tonic可以為內(nèi)核提供一個(gè)接口，以便定期從NIC提取傳輸統(tǒng)計(jì)數(shù)據(jù)。

其他傳輸層。上面的設(shè)計(jì)是如何將Tonic集成到常用傳輸層的一個(gè)示例。但是，TCP、套接字和字節(jié)流并不適用于所有應(yīng)用程序。事實(shí)上，一些具有高帶寬、低延遲流的數(shù)據(jù)中心應(yīng)用程序開始使用RDMA及其基于消息的API來代替。Tonic也可以被集成到基于RDMA的傳輸中，我們將在附錄A中討論這一點(diǎn)。

6. 評(píng)估

為了評(píng)估Tonic，我們用Verilog實(shí)現(xiàn)了一個(gè)原型(約8K行代碼)，并用C++實(shí)現(xiàn)了一個(gè)周期精確的硬件仿真器 (約2K行代碼) [11]。該仿真器與NS3網(wǎng)絡(luò)仿真器[4]集成在一起進(jìn)行端到端的實(shí)驗(yàn)。

要在Tonic的Verilog原型上實(shí)現(xiàn)傳輸協(xié)議，程序員只需要提供三個(gè)Verilog文件：(i) incoming.v，描述丟失檢測(cè)和恢復(fù)邏輯以及如何改變信用管理參數(shù)(即，速率或窗口) 以響應(yīng)于輸入數(shù)據(jù)包；該代碼被插入到數(shù)據(jù)傳輸引擎中的輸入流水線的第二階段；(ii) periodic_updates.v，描述丟失檢測(cè)和恢復(fù)邏輯以響應(yīng)超時(shí)，以及如何改變信用管理參數(shù)(即，速率或窗口)以響應(yīng)周期性定時(shí)器和計(jì)數(shù)器，該代碼被插入到數(shù)據(jù)傳輸引擎中的周期性更新模塊中 (iii)user_configs.vh，其指定要使用三個(gè)信用計(jì)算方案中的哪一個(gè)以及用戶定義的狀態(tài)變量和其他參數(shù)的初始值，例如初始窗口大小、速率和信用。

我們從以下兩個(gè)方面對(duì)Tonic進(jìn)行評(píng)估：

硬件設(shè)計(jì)(§6.1)。我們使用Tonic的Verilog原型來評(píng)估其硬件架構(gòu)的可編程性和可拓展性。Tonic能否支持各種傳輸協(xié)議嗎？它是否減少了在NIC中實(shí)施傳輸協(xié)議的開發(fā)工作？Tonic能否支持具有多個(gè)變量的復(fù)雜用戶定義邏輯嗎？它能夠支持多少個(gè)單流段和并發(fā)流？

端到端行為(§6.2)。我們使用Tonic的周期性精確仿真器和NS3來比較Tonic的端到端行為和兩個(gè)協(xié)議的硬編碼實(shí)現(xiàn)：New Reno[23]和使用DCQCN的 RoCEv2 [43]，對(duì)于單個(gè)流和多個(gè)流共享一個(gè)瓶頸鏈路。

>6.1 硬件設(shè)計(jì)

評(píng)估硬件設(shè)計(jì)效率有兩個(gè)主要指標(biāo)：(i)資源利用率。FPGA由原語塊組成，這些原語塊可以通過配置和連接以實(shí)現(xiàn)Verilog程序：look-up tables (LUT)是主要的可重新配置邏輯塊，而block RAM(BRAM)用于實(shí)現(xiàn)存儲(chǔ)器。(ii)定時(shí)。在每個(gè)周期開始時(shí)，每個(gè)模塊的輸入被寫入一組輸入寄存器。在下一個(gè)周期開始之前，該模塊必須處理輸入并準(zhǔn)備輸出寄存器的結(jié)果。Tonic 的meet timing必須是100 MHz，才能每10 ns傳輸一個(gè)段地址。也就是說，要實(shí)現(xiàn)100 Gbps，每個(gè)模塊中從輸入到輸出寄存器的每條路徑的處理延遲必須保持在10 ns以內(nèi)。

我們使用這兩個(gè)指標(biāo)來評(píng)估Tonic的可編程性和可擴(kuò)展性。這些指標(biāo)高度依賴于用于合成的特定目標(biāo)。我們使用Kintex UltraScale+XCKU15P FPGA作為我們的目標(biāo)，是因?yàn)樵揊PGA和其他具有類似功能的FPGA在今天的商業(yè)可編程N(yùn)IC中都是bump-in-the-wire結(jié)構(gòu)。這是一個(gè)保守的選擇，因?yàn)檫@些NIC是為10-40 Gbps以太網(wǎng)設(shè)計(jì)的。一塊100 Gbps的網(wǎng)卡可能會(huì)有一個(gè)功能更強(qiáng)大的FPGA。此外，我們將Tonic的所有組件綜合到FPGA上，作為一個(gè)獨(dú)立的原型進(jìn)行評(píng)估。然而，考慮到固定功能模塊和可編程模塊之間有明確的接口，可以設(shè)想將固定功能組件作為ASIC實(shí)現(xiàn)以提高效率。除非另有說明，否則在所有實(shí)驗(yàn)中，我們都將并發(fā)流的最大數(shù)量設(shè)置為1024，將最大窗口大小設(shè)置為128段7。

· 硬件可編程性

我們已經(jīng)在Tonic中實(shí)現(xiàn)了六種協(xié)議的發(fā)送端傳輸邏輯，作為文獻(xiàn)中各種類型的段選擇和信用計(jì)算算法的代表。表3總結(jié)了固定功能模塊和用戶定義模塊的資源利用率，以及用于實(shí)現(xiàn)它們的代碼行和用戶定義狀態(tài)字節(jié)數(shù)。雖然我們對(duì)所有協(xié)議使用相同的單流狀態(tài)變量集(表2)，但并非所有協(xié)議在處理傳輸事件時(shí)都使用所有變量。例如，位圖只被有選擇性ack的協(xié)議使用。因此，通過一些預(yù)處理，從Verilog設(shè)計(jì)中去掉不相關(guān)的變量和計(jì)算，甚至可以進(jìn)一步降低資源利用率。

Reno和New Reno代表TCP變體，僅使用累積ack來實(shí)現(xiàn)可靠傳輸以及用于信用管理的擁塞窗口。Reno只能使用快速重傳來恢復(fù)窗口內(nèi)的一次丟失，而New Reno使用部分確認(rèn)來更有效地恢復(fù)同一窗口中的多個(gè)丟失。SACK受到RFC 6675的啟發(fā)，表示使用選擇性ack的TCP變體。我們的實(shí)現(xiàn)是每個(gè)ack至少有一個(gè)SACK塊，但可以擴(kuò)展到更多。

NDP[24]代表接收器驅(qū)動(dòng)的協(xié)議，最近提出用于低延遲數(shù)據(jù)中心網(wǎng)絡(luò)。它使用明確的NACK和超時(shí)進(jìn)行丟失檢測(cè)，并授予令牌進(jìn)行擁塞控制。RoCEv2 w/DCQCN[43]是一種廣泛使用的以太網(wǎng)RDMA傳輸協(xié)議，IRN[34]是一種最新的基于硬件的協(xié)議，用于改進(jìn)ROCE的簡(jiǎn)單數(shù)據(jù)傳輸算法。這兩者都使用速率限制器進(jìn)行信用管理。

注意，如§3.2所述，并非所有數(shù)據(jù)傳輸算法都適用于硬件實(shí)現(xiàn)。例如，由于NIC上的內(nèi)存限制，不可能在網(wǎng)卡上為每個(gè)數(shù)據(jù)包(新數(shù)據(jù)包和重傳輸數(shù)據(jù)包)保留時(shí)間戳。因此，嚴(yán)重依賴每包時(shí)間戳的傳輸協(xié)議(例如，QUIC[27])需要被修改以使用更少的時(shí)間戳工作，例如，對(duì)于要卸載到硬件的正在傳輸?shù)亩蔚淖蛹?/p>

從這些結(jié)果中可以得出三個(gè)重要結(jié)論：

① Tonic支持多種傳輸協(xié)議。

② 使用Tonic，上述每種協(xié)議的實(shí)現(xiàn)只需不到200行Verilog代碼，用戶自定義邏輯占用不到FPGA 0.6%的LUT。相比之下，Tonic的固定功能模塊可以在這些協(xié)議中重復(fù)使用，使用約8K行代碼實(shí)現(xiàn)，消耗了60倍的LUT。

③ 不同的信用管理方案具有不同的開銷。對(duì)于使用擁塞窗口的傳輸協(xié)議，窗口計(jì)算與數(shù)據(jù)傳輸引擎重疊，因此在數(shù)據(jù)傳輸引擎中實(shí)現(xiàn)(§3.3.1)。因此，他們的信用引擎使用的資源比其他公司少。與強(qiáng)制執(zhí)行接收器生成的授權(quán)令牌相比，速率限制需要更多的單流狀態(tài)和更復(fù)雜的操作(§4)，但需要更少的內(nèi)存端口用于并發(fā)讀取和寫入(§3.3.2)，總體上導(dǎo)致更低的BRAM和更高的LUT利用率。

· 硬件可擴(kuò)展性

我們通過研究Tonic架構(gòu)中的可變性來源(可編程模塊和各種參數(shù))如何影響內(nèi)存利用率和計(jì)時(shí)來評(píng)估Tonic的可擴(kuò)展性。

可編程模塊中的用戶定義邏輯可以具有任意長的相關(guān)操作鏈，這可能會(huì)導(dǎo)致時(shí)序沖突。我們用不同數(shù)量的算術(shù)、邏輯和位圖運(yùn)算為incoming.v(數(shù)據(jù)傳輸引擎中Incoming模塊的可編程階段)生成了70個(gè)隨機(jī)程序，并分析了在不違反10 ns時(shí)序的情況下相關(guān)操作鏈的長度。這些程序使用高達(dá)125B的狀態(tài)，最大依賴于65個(gè)邏輯電平(分別比表3中的基準(zhǔn)協(xié)議多6倍和2倍)。每個(gè)邏輯電平代表幾個(gè)原始邏輯塊(LUT、MUX、DSP等)中的一個(gè)，它們鏈接在一起以實(shí)現(xiàn)Verilog程序中的路徑。

我們將這些程序插入Tonic，對(duì)其進(jìn)行綜合，并分析邏輯級(jí)數(shù)與最大延遲路徑延遲之間的關(guān)系(表4)。邏輯級(jí)數(shù)不超過32的程序始終滿足時(shí)序要求，而邏輯級(jí)數(shù)超過43的程序則不符合時(shí)序要求。邏輯級(jí)數(shù)在32到42之間的，最大延遲路徑的等待時(shí)間約為10 ns。根據(jù)最大延遲路徑上原語的組合及其延遲，該區(qū)域中的程序可能會(huì)滿足時(shí)序要求。我們的基準(zhǔn)協(xié)議在其最大延遲路徑上有13到29個(gè)邏輯級(jí)數(shù)，并且都滿足時(shí)序。因此，Tonic不僅支持我們的基準(zhǔn)協(xié)議，而且還有空間支持未來更復(fù)雜的協(xié)議。

用戶定義的狀態(tài)變量增加了影響B(tài)RAM利用率的內(nèi)存寬度。我們?cè)赟ACK、IRN和NDP增加了額外的變量，以查看在不違反時(shí)序和耗盡BRAM的情況下內(nèi)存的寬度，并針對(duì)三種信用管理方案中的每一種重復(fù)該實(shí)驗(yàn)，因?yàn)樗鼈兙哂胁煌拇鎯?chǔ)器足跡(表4)。Tonic支持用戶自定義狀態(tài)的448B擁塞窗口信用管理，340B速率，256B授予令牌(表3中的協(xié)議使用小于30B)。

最大窗口大小確定存儲(chǔ)在數(shù)據(jù)傳輸引擎中的每個(gè)流位圖的大小，以跟蹤流的段狀態(tài)，從而影響內(nèi)存利用率和位圖操作的復(fù)雜性，從而影響時(shí)序。Tonic可以支持256位的位圖（即跟蹤256段），使用它我們可以在高達(dá)30μs RTT的網(wǎng)絡(luò)中支持單個(gè)100Gbps流（表4）。

并發(fā)流的最大數(shù)量決定內(nèi)存深度和用于流調(diào)度的FIFO大?。ā?.1）。因此，它會(huì)影響內(nèi)存利用率和隊(duì)列操作，從而影響時(shí)序。Tonic可以在硬件上擴(kuò)展到2048個(gè)并發(fā)流（表4），這與數(shù)據(jù)中心[15，37]和文獻(xiàn)[20]中的其他硬件卸載觀察到的活動(dòng)流集的大小相匹配。

Tonic有更多的空間來支持未來的協(xié)議，這些協(xié)議比我們的基準(zhǔn)協(xié)議更復(fù)雜，具有更多用戶定義的變量。它可以跟蹤每個(gè)流的256個(gè)段，支持2048個(gè)并發(fā)流。有了更強(qiáng)大的FPGA和更多的BRAM，Tonic可以支持更大的窗口和更多的流。

>6.2 端到端行為

為了檢查Tonic的端到端行為，并驗(yàn)證不同協(xié)議中基于Tonic的傳輸邏輯實(shí)現(xiàn)的保真度，我們?cè)贑++中為Tonic開發(fā)了一個(gè)周期精確的硬件仿真器。我們將此仿真器與NS3一起使用，以顯示基于Tonic實(shí)現(xiàn)的NewReno和RoCEv2 w/DCQCN發(fā)送端與其硬編碼的NS3實(shí)現(xiàn)相匹配。請(qǐng)注意，這些仿真的目的是分析和驗(yàn)證Tonic的端到端行為。Tonic支持100Gbps線路速率的能力已在§6.1中得到證明。因此，在我們的仿真中，我們使用10Gbps和40Gbps作為線速率，僅僅是為了使硬件仿真在幾秒鐘內(nèi)的多個(gè)流在計(jì)算上易于處理。

· TCP New Reno

我們?cè)赥onic中基于RFC6582實(shí)現(xiàn)了TCP New Reno，并使用NS3的本地網(wǎng)絡(luò)堆棧進(jìn)行硬編碼實(shí)現(xiàn)。我們基于Tonic的實(shí)現(xiàn)與NS3中未修改的本地TCP接收器配合使用。在所有仿真中，主機(jī)通過10Gbps鏈路連接到一個(gè)交換機(jī)，RTT為10μs，緩沖區(qū)為5.5MB，最小重傳超時(shí)為200ms（Linux默認(rèn)值），段大為1000B，并且在接收器上啟用延遲ack。

單流。我們啟動(dòng)從一個(gè)主機(jī)到另一個(gè)主機(jī)的單一流，并在接收方的NIC上隨機(jī)丟棄數(shù)據(jù)包。圖3（a）和圖3（b）分別顯示了擁塞窗口和傳輸序列號(hào)的更新（重傳用大圓點(diǎn)標(biāo)記）。Tonic在這兩種情況下的行為都與硬編碼的實(shí)現(xiàn)密切相關(guān)。這些細(xì)微的差異源于這樣一個(gè)事實(shí)：在NS3的網(wǎng)絡(luò)堆棧中，所有計(jì)算都在同一虛擬時(shí)間步長中進(jìn)行，而在Tonic中，每個(gè)事件（輸入數(shù)據(jù)包、段地址生成等）都在100ns周期內(nèi)處理（從10ns增加到10G線速率）。

多個(gè)流。兩個(gè)發(fā)送端各發(fā)送100個(gè)流到一個(gè)接收端，因此200個(gè)流在5秒鐘內(nèi)共享一個(gè)瓶頸鏈路?；赥onic實(shí)現(xiàn)的200個(gè)流的平均吞吐量的CDF與硬編碼的實(shí)現(xiàn)密切相關(guān)（圖3（c））。我們觀察到重傳次數(shù)的分布也是類似的。在分析毫秒級(jí)的流吞吐量時(shí)，我們注意到硬編碼實(shí)現(xiàn)的變化比Tonic大，因?yàn)橄鄬?duì)于NS3的堆棧，Tonic在同一主機(jī)上的流執(zhí)行每包循環(huán)調(diào)度。

· RoCEv2 with DCQCN

我們用Tonic實(shí)現(xiàn)ROCE w/DCQCN，并使用作者在[44]中的NS3進(jìn)行硬編碼實(shí)現(xiàn)。我們基于Tonic的實(shí)現(xiàn)與未經(jīng)修改的硬編碼ROCE接收器一起工作。在所有仿真中，主機(jī)通過40Gbps鏈路連接到同一交換機(jī)，RTT為4μs，網(wǎng)段大小為1000B，我們使用中的默認(rèn)DCQCN參數(shù)。

單流。Tonic是一種基于速率的算法，它使用CNP和周期性定時(shí)器和計(jì)數(shù)器進(jìn)行擁塞控制，而不是TCP中的丟包。因此，為了觀察單個(gè)流的速率更新，我們從兩臺(tái)主機(jī)向同一接收器運(yùn)行兩個(gè)流一秒鐘，以造成擁塞并跟蹤其中一個(gè)流的吞吐量變化，因?yàn)樗鼈兌际諗康较嗤乃俾?。Tonic的行為與硬編碼的實(shí)現(xiàn)非常匹配(圖4)。我們還運(yùn)行了一個(gè)100Gbps的DCQCN流，其中包含128B背靠背數(shù)據(jù)包，并確認(rèn)Tonic可以使100Gbps鏈路飽和。

多流。兩個(gè)發(fā)送方各向一個(gè)接收方發(fā)送100個(gè)流，因此200個(gè)流在一秒鐘內(nèi)共享一條瓶頸鏈路。Tonic和硬編碼的實(shí)現(xiàn)都在同一主機(jī)上的流之間執(zhí)行每數(shù)據(jù)包循環(huán)調(diào)度。結(jié)果，這兩種情況下的所有流最終的平均吞吐量為203±0.2 Mbps。此外，我們觀察到兩種情況下CNP的分布是匹配的。

7. 相關(guān)工作

Tonic是第一個(gè)能夠支持100Gbps的可編程硬件傳輸邏輯架構(gòu)。在本節(jié)中，我們回顧最密切相關(guān)的先前工作。

商用硬件網(wǎng)絡(luò)協(xié)議棧。一些網(wǎng)卡的硬件網(wǎng)絡(luò)堆棧帶有硬連線傳輸協(xié)議。但是，它們只實(shí)現(xiàn)了兩種協(xié)議，要么是ROCE[8]要么是供應(yīng)商選擇的TCP變體，并且只能由供應(yīng)商修改。Tonic使程序員能夠以最小的努力在硬件中實(shí)現(xiàn)各種傳輸協(xié)議。由于缺乏對(duì)這些NIC體系結(jié)構(gòu)的公開詳細(xì)描述，我們無法將我們的設(shè)計(jì)決策與他們的進(jìn)行比較。

非商業(yè)性硬件傳輸協(xié)議。最近的工作探索了高速運(yùn)行、占用內(nèi)存少的硬件傳輸協(xié)議。Tonic通過使研究人員能夠以適度的開發(fā)努力實(shí)施新的協(xié)議來促進(jìn)這一領(lǐng)域的創(chuàng)新。

加速網(wǎng)絡(luò)功能。一些學(xué)術(shù)和工業(yè)項(xiàng)目將終端主機(jī)虛擬交換和網(wǎng)絡(luò)功能卸載到FPGA，處理已經(jīng)生成的數(shù)據(jù)包流。另一方面，Tonic通過一次跟蹤可能的幾百個(gè)數(shù)據(jù)段來實(shí)現(xiàn)NIC中的傳輸邏輯，以便在運(yùn)行用戶定義的傳輸邏輯的同時(shí)以線速生成數(shù)據(jù)包，以確保高效可靠的傳輸。

附錄

附錄A 在RDMA中集成Tonic

遠(yuǎn)程直接內(nèi)存訪問(RDMA)使應(yīng)用程序能夠直接訪問遠(yuǎn)程端點(diǎn)上的內(nèi)存，而不涉及CPU。為此，端點(diǎn)創(chuàng)建類似于連接的queue pair，并發(fā)布請(qǐng)求，稱為Work Queue Elements (WQEs)，用于發(fā)送或接收彼此的內(nèi)存數(shù)據(jù)。雖然RDMA起源于InfiniBand networks，但以太網(wǎng)上的RDMA在數(shù)據(jù)中心變得越來越普遍。在本節(jié)中，我們使用RDMA來指代以太網(wǎng)上的RDMA實(shí)現(xiàn)。

一旦創(chuàng)建了隊(duì)列對(duì)，RDMA NIC就可以將新的“連接”添加到Tonic，并在the sender side使用它來傳輸數(shù)據(jù)，以響應(yīng)不同的WQE。每個(gè)WQE對(duì)應(yīng)于一個(gè)單獨(dú)的消息傳輸，因此很好地滿足了Tonic在開始數(shù)據(jù)傳輸之前確定段邊界的需要。

例如，在RDMA寫入中，一個(gè)端點(diǎn)發(fā)布一個(gè)Request WQE以寫入另一個(gè)端點(diǎn)上的內(nèi)存。在Request WQE中指定數(shù)據(jù)長度、發(fā)送方上的數(shù)據(jù)源地址和接收方上的數(shù)據(jù)接收器地址。因此，RDMA應(yīng)用程序和Tonic之間的緩沖區(qū)可以決定段邊界，并通知Tonic要從發(fā)送器上讀取數(shù)據(jù)的段數(shù)和源存儲(chǔ)器地址。一旦Tonic生成下一個(gè)網(wǎng)段地址，RDMA網(wǎng)卡的其余部分就可以從發(fā)送方的內(nèi)存中對(duì)其進(jìn)行DMA，并添加合適的報(bào)頭。RDMA發(fā)送類似于RDMA寫入，不同之處在于它需要接收方上的接收WQE來指定來自發(fā)送方的數(shù)據(jù)應(yīng)該寫入的接收方地址。所以，Tonic仍然可以在發(fā)送方以相同的方式使用。

另一個(gè)示例，在一個(gè)RDMA Read中，一個(gè)端點(diǎn)從另一個(gè)端點(diǎn)上的存儲(chǔ)器請(qǐng)求數(shù)據(jù)。因此，響應(yīng)方端點(diǎn)應(yīng)該向請(qǐng)求方端點(diǎn)傳輸數(shù)據(jù)。同樣，數(shù)據(jù)長度、響應(yīng)方的數(shù)據(jù)源地址和請(qǐng)求方的數(shù)據(jù)接收器地址在WQE中指定。因此，緩沖區(qū)可以決定數(shù)據(jù)段邊界，并使用Tonic傳輸數(shù)據(jù)。

因此，Tonic可以集成到RDMA 網(wǎng)卡中，以取代數(shù)據(jù)傳輸發(fā)送方的硬編碼傳輸邏輯。事實(shí)上，我們的兩個(gè)基準(zhǔn)協(xié)議ROCE w/DCQCN[43]和IRN[34]是為RDMA 網(wǎng)卡提出的。也就是說，這是假設(shè)在另一端有一個(gè)兼容的接收器來生成控制信號(hào)(例如，確認(rèn)、擁塞通知等)。無論選擇在發(fā)送端的Tonic上實(shí)現(xiàn)哪種傳輸協(xié)議都需要這些信號(hào)。

雖然以太網(wǎng)上的RDMA的一些實(shí)現(xiàn)，如iWarp[7]處理失序（OOO）數(shù)據(jù)包并實(shí)現(xiàn)類似TCP/IP的確認(rèn)，但其他的（即RoCE[8]）假設(shè)一個(gè)無損網(wǎng)絡(luò)并具有更簡(jiǎn)單的傳輸協(xié)議，不要求接收器處理OOO數(shù)據(jù)包和產(chǎn)生頻繁的控制信號(hào)。然而，隨著以太網(wǎng)上的RDMA在數(shù)據(jù)中心越來越普遍，在這些網(wǎng)卡中也正在實(shí)現(xiàn)在接收器上處理OOO數(shù)據(jù)包和生成各種控制信號(hào)的能力，以實(shí)現(xiàn)更有效的傳輸。

最后，Tonic在同一流中提供有序可靠的數(shù)據(jù)傳輸。因此，通過同一流發(fā)送的消息以相同的順序傳輸給接收方。然而，有時(shí)需要支持通信端點(diǎn)(例如，隊(duì)列對(duì))的無序消息傳輸，例如，當(dāng)消息彼此獨(dú)立時(shí)，或者當(dāng)使用“非連接”的端點(diǎn)(例如，一個(gè)發(fā)送者和多個(gè)接收者)時(shí)，可以提高應(yīng)用的性能。通過在Tonic中為同一通信端點(diǎn)創(chuàng)建多個(gè)流并同時(shí)使用它們，仍然可以使用Tonic支持無序消息傳輸。擴(kuò)展Tonic以支持同一流中的無序消息傳輸是未來工作的一個(gè)有趣途徑。

附錄B 高精度單流速率限制

在信用引擎中使用速率時(shí)，如果一個(gè)速率為R字節(jié)/周期的流需要L字節(jié)的信用來傳輸一個(gè)段，則Tonic計(jì)算T=L/R作為該流將有足夠的信用來傳輸?shù)臅r(shí)間。它設(shè)置一個(gè)定時(shí)器，該定時(shí)器在T周期內(nèi)到期，并且在其到期時(shí)，將未準(zhǔn)備好發(fā)送的流排隊(duì)以進(jìn)行傳輸(§3.3.2)。由于Tonic無法在其時(shí)間限制內(nèi)進(jìn)行浮點(diǎn)除法，因此R必須表示為整數(shù)。

這在速率限制精度和Tonic可以支持的速率范圍之間進(jìn)行了權(quán)衡。如果我們將R表示為每個(gè)周期的字節(jié)數(shù)，則可以計(jì)算流將具有足夠信用的確切周期，但不能支持低于每周期一個(gè)字節(jié)或約1Gbps的速率。如果我們用每千次周期的字節(jié)數(shù)來表示R，我們可以支持較低的速率(例如，1 Mbps)，但T=L/R將確定從現(xiàn)在起該流可以有多少千次周期有資格進(jìn)行傳輸。這導(dǎo)致較高帶寬流的速率一致性和精度較低。舉個(gè)具體的例子，對(duì)于一個(gè)20Gbps的流，R將是每千次周期25000字節(jié)。假設(shè)流有1500字節(jié)的數(shù)據(jù)段要傳輸。它將有足夠的信用在8個(gè)周期內(nèi)完成，但是必須等待[1500/25000]=1000個(gè)周期來排隊(duì)等待傳輸。

Tonic沒有對(duì)R進(jìn)行單一表示，而是對(duì)每個(gè)流保留多個(gè)變量R1，. . .， Rk，每個(gè)變量以不同的精確程度代表流的速率。由于擁塞控制環(huán)路根據(jù)網(wǎng)絡(luò)容量調(diào)整速率，Tonic可以有效地在R1、.。。。，Rk之間切換以選擇最精確的表示法來隨時(shí)計(jì)算T。這使得Tonic能夠在不犧牲速率限制精度的情況下支持各種的速率。

附錄C 高效的位圖操作

Tonic使用高達(dá)128位的位圖來跟蹤每個(gè)流的段窗口的狀態(tài)。位圖被實(shí)現(xiàn)為環(huán)形緩沖區(qū)，頭部指針對(duì)應(yīng)于第一個(gè)未確認(rèn)的段。隨著新的確認(rèn)到來，頭部指針在環(huán)形中向前移動(dòng)。為了有效地實(shí)現(xiàn)其輸出取決于位圖中所有位的值的操作，我們必須通過將環(huán)形緩沖區(qū)劃分為較小的部分，并行處理它們，并合并結(jié)果來對(duì)它們進(jìn)行并行化。對(duì)于較大的環(huán)形緩沖器，這種分割運(yùn)行的模式在多層中重復(fù)。由于每一層都依賴于前一層的輸入，我們必須將每一層的計(jì)算保持在最低限度，以保持在10 ns的目標(biāo)范圍內(nèi)。

其中一種操作是找到頭部之后的第一個(gè)設(shè)置位。此操作用于在marked-for-rtx位圖中查找下一個(gè)丟失的數(shù)據(jù)段進(jìn)行重傳。環(huán)形緩沖區(qū)的頭部移動(dòng)使該操作的實(shí)現(xiàn)變得復(fù)雜。假設(shè)我們有一個(gè)32位的環(huán)形緩沖區(qū)A32，第5和30位設(shè)置為1，頭部位于索引6。因此，find first(A32，6)=30。我們把環(huán)形緩沖區(qū)分成8個(gè)4位的部分，并將結(jié)果送入8位環(huán)形緩沖區(qū)A8，其中A8[i]=OR(A32[i：i+3])。因此，只設(shè)置了A8[1]和A8[7]。然而，由于A32[4：7]中的設(shè)置位在原環(huán)形緩沖區(qū)中的頭部之前，我們不能簡(jiǎn)單地使用1作為A8的頭部索引，否則我們將錯(cuò)誤地生成5而不是30作為最終結(jié)果。因此，我們需要額外的計(jì)算來找到正確的新頭部。對(duì)于具有多層這種分割運(yùn)行模式的較大環(huán)形緩沖區(qū)，我們需要計(jì)算每一層的頭部。

相反，我們?cè)谳斎氕h(huán)形緩沖區(qū)上使用了輕量級(jí)的預(yù)處理，以完全避免頭部索引計(jì)算。更具體地說，使用A32作為輸入，我們計(jì)算出等于A32的A’32，只是從索引0到頭部(在我們的例子中是6)的所有位都被設(shè)置為0。從索引0開始，A’32中的第一個(gè)設(shè)置位始終比A32中的第一個(gè)設(shè)置位更接近原始頭部。因此，如果A’32有任何設(shè)置位，則find first(A32，6)等于find first(A’32，0)，否則等于find first(A32，0)。這樣，與輸入的頭部索引H無關(guān)，我們總是可以從頭部索引固定為0的兩個(gè)子問題中求解find first(A，H)。

附錄D 使用Tonic通過Socket API確定流量的C和T

在§5中，我們提供了一個(gè)示例，說明如何將Tonic集成到Linux內(nèi)核中，以便應(yīng)用程序可以通過Socket API使用它。我們引入了兩個(gè)參數(shù)：(i)C，它是流的固定段大?。?ii)T，它是內(nèi)核在向Tonic發(fā)送“子段”(小于C的段)之前等待來自應(yīng)用程序的更多數(shù)據(jù)的持續(xù)時(shí)間。C和T可以根據(jù)每個(gè)流的延遲和吞吐量特性進(jìn)行配置。對(duì)于高帶寬流，可以將C設(shè)置為MSS(如果更大，則可以使用TSO)。對(duì)于只偶爾生成數(shù)據(jù)段的流，正如我們下面討論的那樣，設(shè)置C和T并不是那么簡(jiǎn)單。

在固定C的情況下，增加T會(huì)導(dǎo)致更多的小數(shù)據(jù)段在發(fā)送到Tonic進(jìn)行傳輸之前被合并成C大小的數(shù)據(jù)段，但代價(jià)是延遲更高。C決定了Tonic生成的數(shù)據(jù)段的大小和子數(shù)據(jù)段的數(shù)量?；仡櫼幌隆?，當(dāng)沒有足夠的數(shù)據(jù)在T內(nèi)形成一個(gè)完整的C大小的段時(shí)，就會(huì)創(chuàng)建一個(gè)子段。Tonic需要除突發(fā)中的最后一個(gè)子段外的所有段的大小相等。因此，即使在子段被發(fā)送到Tonic進(jìn)行傳輸之后，更多的數(shù)據(jù)被添加到套接字緩沖區(qū)，Tonic也必須成功地傳送所有先前的段，然后才能開始傳輸新的段。因此，最好是產(chǎn)生更大的分段但更少的子分段。在T固定的情況下，增加C會(huì)產(chǎn)生更大的段。然而，為了產(chǎn)生更少的子段，C應(yīng)該被挑選出來，以便在大多數(shù)情況下突發(fā)中的數(shù)據(jù)可以被C整除。突發(fā)在時(shí)間上被T分隔。因此，T的選擇會(huì)影響C的選擇，反之亦然。

例如，如果應(yīng)用程序周期性地生成128字節(jié)的請(qǐng)求，則C可以很容易地設(shè)置為128，T則基于周期性。作為另一個(gè)例子，對(duì)于一個(gè)周期性地生成大小不一的段的應(yīng)用程序，將T設(shè)置為0并且將C設(shè)置為最大預(yù)期段大小，會(huì)導(dǎo)致Tonic傳輸由應(yīng)用產(chǎn)生的數(shù)據(jù)段而不進(jìn)行整合，從而潛在地創(chuàng)建許多子段。對(duì)于同一應(yīng)用程序，將T設(shè)置為0，將C設(shè)置為最小預(yù)期段大小可能會(huì)導(dǎo)致Tonic生成許多小段，因?yàn)樗蟹侄味紝⒈环纸鉃樽钚☆A(yù)期段大小。請(qǐng)注意，如果Tonic用于僅偶爾生成數(shù)據(jù)段的流，則這些權(quán)衡會(huì)變得更加明顯。對(duì)于高帶寬流，C可以設(shè)置為MSS（如果使用TSO則會(huì)更大），而T則取決于應(yīng)用程序的流量模式和突發(fā)度。



審核編輯：劉清