TCP發(fā)展受阻的原因是什么呢？RDMA和Linux TCP技術(shù)解析

在考慮今天如何開始時(shí)，我回顧了一下這兩天關(guān)于硬件和軟件之間分歧的主題演講。主要探討了擁塞控制如何在這個(gè)不斷發(fā)展的領(lǐng)域中增長(zhǎng)和演變。由于技術(shù)不斷變革，問題也不斷涌現(xiàn)，因此解決方案需要隨時(shí)間調(diào)整。此外，ChatGPT的普及和加速器的進(jìn)步正在從根本上改變通信模式，以及通信的負(fù)載和要求。因此，我想確保大家了解這是我們真正要討論的重點(diǎn)。接下來的講話將專注于該領(lǐng)域的一個(gè)具體方面。

有一些問題，我知道你們中的一些人之前已經(jīng)遇到過。為什么你會(huì)再次提出這個(gè)問題？為什么你要對(duì)比RDMA和TCP？實(shí)際上，RoCE和IB已經(jīng)很好地滿足了大多數(shù)高性能通信需求。然而，還有很多工作要做，特別是關(guān)于啟用亂序傳輸（Out-of-order delivery）和選擇性確認(rèn)（Selective Acknowledgements, SACK），以提高自由傳輸?shù)男?。我們期望?shí)現(xiàn)比現(xiàn)有方案更好的性能，其中擁塞控制機(jī)制是一個(gè)關(guān)鍵。今天早些時(shí)候，我們也討論了一些類似的增強(qiáng)功能。這個(gè)領(lǐng)域非常值得關(guān)注，因?yàn)?strong>不同的工作負(fù)載和流程對(duì)擁塞控制方案有不同的要求。因此，這也是RoCE持續(xù)發(fā)展和改進(jìn)的方向。

另外，當(dāng)我們從圍繞RDMA構(gòu)建的特殊定制網(wǎng)絡(luò)轉(zhuǎn)向使應(yīng)用程序更具通用性時(shí)，流量將將成為更加關(guān)鍵的因素。對(duì)于TCP的熟悉程度，以及在規(guī)模上調(diào)試問題的經(jīng)驗(yàn)，理解如何處理問題、如何分配帶寬、如何確保公平性等，這些都是TCP帶來的挑戰(zhàn)，并迫使我們重新思考和審視這些問題。

最后一個(gè)觀點(diǎn)是，雖然RoCE通常運(yùn)行在定制的后端網(wǎng)絡(luò)或特定目的構(gòu)建網(wǎng)絡(luò)上，但構(gòu)建一個(gè)完整的生態(tài)系統(tǒng)還需要考慮通用存儲(chǔ)的需求。之前的討論提到了云服務(wù)，這些服務(wù)幾乎總是在某種TCP變體上運(yùn)行。隨著機(jī)器學(xué)習(xí)的不斷增長(zhǎng)，特別是推理服務(wù)在云路徑上的應(yīng)用，這些服務(wù)并不總是依賴于定制網(wǎng)絡(luò)。盡管如此，它們?nèi)匀幻媾R巨大的數(shù)據(jù)和帶寬需求。

因此，問題在于TCP是否存在根本性問題，是否需要徹底改進(jìn)，或者我們能否重新利用它。在這個(gè)領(lǐng)域，觀點(diǎn)各異，有些人認(rèn)為TCP對(duì)于數(shù)據(jù)中心來說并不適用，我們需要從頭開始設(shè)計(jì)。Homa就是這樣一個(gè)例子。但讓我們深入探討一下，看看我們能為TCP做些什么。

那么，為什么要關(guān)注TCP呢？在數(shù)據(jù)中心網(wǎng)絡(luò)的領(lǐng)域中，擁塞控制算法的豐富性無疑是最為關(guān)鍵的一環(huán)。這是一個(gè)歷經(jīng)數(shù)十年深入研究的領(lǐng)域，提供了眾多行為模型供我們選擇，使得我們可以根據(jù)具體用例挑選最合適的模型。無論你是在尋找適用于短距離數(shù)據(jù)中心鏈路的方案，還是適用于遠(yuǎn)距離廣域網(wǎng)鏈路的方案，甚至是混合鏈路的解決方案，都有相應(yīng)的選項(xiàng)可供選擇。這個(gè)領(lǐng)域內(nèi)的擁塞控制、速率控制、公平性等概念易于理解，同時(shí)選擇性確認(rèn)和高效重傳等機(jī)制也得到了廣泛的研究。此外，預(yù)測(cè)性支持亂序包交付和有序完成的能力也是系統(tǒng)設(shè)計(jì)中不可或缺的一部分。

一個(gè)值得探討的問題是：這不是之前已經(jīng)嘗試過了嗎？顯然，iWARP就是其中一次較大的嘗試。在這次嘗試中，人們?cè)噲D將RDMA框架概念置于TCP基本傳輸方案之上。但這一嘗試至少需要依賴硬件TCP引擎來實(shí)現(xiàn)，這實(shí)際上排除了很多可能性。你必須選擇你能實(shí)現(xiàn)的東西，無論是固件還是硬件，最終基本上限制了TCP可用的速率、速度和靈活性。此外，在網(wǎng)絡(luò)上執(zhí)行TCP以及在RDMA與主機(jī)之間進(jìn)行框架轉(zhuǎn)換的嘗試，使得該協(xié)議變得異常復(fù)雜且難以實(shí)現(xiàn)。

另一個(gè)嘗試是名為OpenOnload或Onload的堆棧。該堆棧實(shí)際上將TCP庫置于用戶空間，并引導(dǎo)路徑，以避免TCP執(zhí)行受到應(yīng)用程序線程的鎖定爭(zhēng)用，而是在應(yīng)用程序的上下文中執(zhí)行庫。Solarflare的解決方案在高頻交易（HFT）和高性能計(jì)算（HPC）領(lǐng)域取得了巨大成功，我相信這里的人們都有所了解。然而，它也面臨著同樣的問題。多年來，它已經(jīng)偏離了可以稱為標(biāo)準(zhǔn)TCP的東西，即Linux實(shí)現(xiàn)。這導(dǎo)致Linux堆棧經(jīng)歷的一些增強(qiáng)和改進(jìn)在該模型中無法使用。隨著時(shí)間的推移，它成為了一個(gè)分歧的解決方案，引發(fā)了一些額外的摩擦。

接下來是DPDK標(biāo)準(zhǔn)的經(jīng)典用戶空間TCP實(shí)現(xiàn)，這種實(shí)現(xiàn)經(jīng)常在中間件中使用。它在電信解決方案中非常受歡迎，因?yàn)樗噲D以最小的CPU開銷和最少的符合性或兼容性要求來執(zhí)行TCP。然而，我認(rèn)為它有些過于專業(yè)化，并不常見作為一種通用的廣泛部署的解決方案。

因此，我們?nèi)匀幻媾R一個(gè)問題：是否能讓TCP在簡(jiǎn)單硬件上易于實(shí)現(xiàn)，并達(dá)到所需的性能水平。

那么，多年來TCP發(fā)展受阻的原因是什么呢？套接字，對(duì)吧。我想在這方面不會(huì)有太多問題。同步的、基于系統(tǒng)調(diào)用的套接字接口存在問題，它與現(xiàn)代異步、低開銷的標(biāo)準(zhǔn)接收器模型不符。然而，由于安裝基數(shù)如此之大，實(shí)際上在短期內(nèi)廢除套接字是不值得實(shí)現(xiàn)的方案。

然而，在消息傳遞方面，我們確實(shí)面臨著一系列挑戰(zhàn)。一種常見的訪問模式，在TCP上實(shí)現(xiàn)它卻是相當(dāng)困難的。特別是在字節(jié)流序列上構(gòu)建消息框架，這本身就是一個(gè)棘手的問題。如果我們要支持無序的消息傳遞，那么難度將會(huì)進(jìn)一步增加。雖然在高層次上有成功的例子，如NVMe-TCP，但這并不意味著這是一個(gè)簡(jiǎn)單的任務(wù)。你需要投入大量的工作來從字節(jié)流中提取PDU流，并確保每個(gè)層次都能獨(dú)立且正確地工作。這意味著在效率和性能方面，我們需要付出相當(dāng)大的努力。實(shí)際上，我們之前的討論也提到了，你需要在某個(gè)暫存緩沖區(qū)中進(jìn)行PDU分割，然后再進(jìn)行DM處理。

傳統(tǒng)上，TCP并不支持零拷貝技術(shù)，但稍后我們會(huì)看到關(guān)于零拷貝影響的相關(guān)數(shù)據(jù)。最新的Linux實(shí)現(xiàn)在發(fā)送（Tx）方面已經(jīng)具備了相當(dāng)不錯(cuò)的零拷貝功能，但在接收（Rx）方面仍存在一些問題。盡管Tx的實(shí)現(xiàn)很棒，且真正實(shí)現(xiàn)了零拷貝，但其效率仍無法與RDMA和寫操作相比。關(guān)于內(nèi)核頁面翻轉(zhuǎn)機(jī)制，一個(gè)關(guān)鍵問題是，除非CPU完全控制與實(shí)際頁表相關(guān)的異構(gòu)內(nèi)存，否則它可能無法正常工作。這些頁表可能位于PCI交換機(jī)中，并不受主機(jī)內(nèi)存管理單元（MMU）的控制。

最后，TCP面臨的一個(gè)挑戰(zhàn)是精確放置和管理緩沖區(qū)。顯然，你可以解鎖一個(gè)緩沖區(qū)，并通過TCP套接字接口進(jìn)行讀寫操作。但如果你希望進(jìn)行更具體的操作，那么你不希望受到套接字緩沖區(qū)（SKB）的開銷影響，也不希望從無法控制的內(nèi)存空間分配任何額外數(shù)據(jù)。實(shí)現(xiàn)對(duì)應(yīng)用程序的透明處理是相當(dāng)困難的。因此，這些是我認(rèn)為TCP存在的不足之處。

在接下來的演講中，我們將探討是否能解決這些問題，并討論一個(gè)具體的實(shí)現(xiàn)方案。我們一直在努力嘗試解決這些問題，并希望最終能夠取得成功的結(jié)果。

我們目前正在參與的測(cè)試或生態(tài)系統(tǒng)，展示在左邊的這張圖片中。這是一塊標(biāo)準(zhǔn)的Ryzen主板，上面插入了一張FPGA卡。這張F(tuán)PGA卡上又連接了兩個(gè)GPU。這張F(tuán)PGA卡的功能類似于一個(gè)網(wǎng)絡(luò)路由器和一個(gè)PCIe交換機(jī)，其PCI通道均為Gen 3 x16，以太網(wǎng)端口為100G。盡管速度是一個(gè)重要的考慮因素，但在這個(gè)設(shè)計(jì)中，從GPU出來的路徑實(shí)際上并未達(dá)到100G的能力，而只能運(yùn)行在大約40G。因此，我們不會(huì)過多地討論這個(gè)路徑的細(xì)節(jié)。

這個(gè)特定的FPGA設(shè)置，我們可以將其視為在Enfabrica中實(shí)際構(gòu)建的設(shè)計(jì)的硬件近似。它支持一些令人印象深刻的功能。其中之一是它能夠進(jìn)行完整的硬件分類和轉(zhuǎn)向。這意味著它可以一直查看到L5頭。一旦它在L4級(jí)別識(shí)別出特定的流，特別是如果它知道了一個(gè)流是什么，它就可以跟蹤在該流內(nèi)部看到的字節(jié)偏移量。此外，它還實(shí)現(xiàn)了一個(gè)相當(dāng)高效的TSO/GRO方案（幻燈片中的信息有誤）。

讓我們先來看一些數(shù)據(jù)，然后再深入探討其實(shí)際含義。右邊的圖表展示了我們所利用硬件驅(qū)動(dòng)所能實(shí)現(xiàn)的性能。很明顯，我們無法達(dá)到800G的速率。因此，在這個(gè)實(shí)驗(yàn)中，我們基本上從數(shù)據(jù)包中移除了所有有效載荷字節(jié)，使其僅在頭部模式下運(yùn)行。我們盡可能地提高應(yīng)用程序和堆棧的運(yùn)行速度，使用的是未經(jīng)修改的Linux內(nèi)核，上面運(yùn)行著我們的驅(qū)動(dòng)程序。我們的目標(biāo)是測(cè)量在各種MTU數(shù)據(jù)包下，我們可以實(shí)現(xiàn)多快的數(shù)據(jù)包速率和有效吞吐量。吞吐量是通過將分組數(shù)乘以空包大小來計(jì)算的。

從圖表中可以明顯看出，沒有GRO的情況下性能相當(dāng)差。使用軟件GRO相比基準(zhǔn)性能有了明顯的提升，但仍然相對(duì)較低。然而，當(dāng)我們使用我們的硬件GRO方案和修改后的驅(qū)動(dòng)程序時(shí)，開銷大大降低，我們實(shí)際上可以接近達(dá)到800G的數(shù)據(jù)包速率。為了實(shí)現(xiàn)這一目標(biāo)，我們需要覆蓋非常廣泛的MTU范圍，并且在較低的MTU大小下，我們的速率增長(zhǎng)也相當(dāng)可觀。因此，實(shí)際上，我們可以只運(yùn)行所需速度的堆棧。

這意味著，我們學(xué)到或之前推測(cè)的其中一點(diǎn)是，套接字API接口存在相當(dāng)大的問題。它幾乎增加了所有的開銷，并影響了驅(qū)動(dòng)程序?qū)崿F(xiàn)和資源效率。具體來說，套接字API接口沒有在關(guān)鍵路徑中進(jìn)行緩存分配，而是選擇在非關(guān)鍵路徑中進(jìn)行。然而，值得注意的是，原生的SACK和ACK操作實(shí)際上運(yùn)行得非常好。它們能夠保持相當(dāng)穩(wěn)定的速率，并且確實(shí)從無序數(shù)據(jù)和有序完成模型中受益。因此，在出現(xiàn)輕微故障時(shí)，它們能夠非常無縫地恢復(fù)，而不會(huì)引發(fā)真正的問題，前提是故障和重傳發(fā)生在某個(gè)特定的窗口內(nèi)。

另一件要考慮的事情是，如果我們仔細(xì)審視Linux堆棧本身，它已經(jīng)成為最令人滿意的堆棧之一。每個(gè)月都有大約五到十個(gè)提交，其中一到兩個(gè)通常是具有顯著性能優(yōu)勢(shì)的重要更新。此外，Linux堆棧擁有一個(gè)龐大的社區(qū)，這個(gè)社區(qū)非?；钴S，持續(xù)關(guān)注著性能及其影響。

在擁塞控制算法方面，已經(jīng)有了巨大的改進(jìn)。像BBR這樣的新算法在關(guān)鍵地方產(chǎn)生了重要影響。短隊(duì)列的實(shí)現(xiàn)使得緩沖區(qū)膨脹不再成為問題，即使在使用TSO/GRO類型方案時(shí)也是如此。此外，無縫路由對(duì)于鏈路負(fù)載和鏈路（或分布數(shù)據(jù)）的問題至關(guān)重要。

特別是在機(jī)器學(xué)習(xí)和大數(shù)據(jù)類型應(yīng)用的背景下，這一點(diǎn)變得更加重要。想象一下，如果你有200G的鏈路，但在短時(shí)間內(nèi)所有流量都集中在其中一個(gè)鏈路上，那么你就會(huì)遇到問題，整體效率會(huì)急劇下降。

值得一提的是，使用eBPF作為可配置攔截器是一種非常有效和有趣的動(dòng)態(tài)擁塞控制機(jī)制。此外，Big TCP也是一個(gè)解決方案，它實(shí)際上應(yīng)該在之前提到過的某個(gè)地方被提及。TCP在有效負(fù)載大小方面并沒有做得很好，而Big TCP通過超過16位有效負(fù)載大小的限制，允許主機(jī)表達(dá)比16位更大的緩沖區(qū)。

這個(gè)圖表沒有展示的是CPU利用率，這顯然是一個(gè)關(guān)鍵問題，與其他堆棧一樣重要。其中一個(gè)待解決的問題是，為了達(dá)到所需的性能水平，需要多少CPU資源。今天，我們將探討其中的一些問題，但對(duì)于真正感興趣的人，我建議關(guān)注這兩個(gè)鏈接。在我們發(fā)布幻燈片時(shí)，這兩個(gè)鏈接應(yīng)該會(huì)出現(xiàn)在其中。David在這兩次演講中詳細(xì)闡述了我們對(duì)某些研究的看法，以及這些小改變?nèi)绾斡绊慍PU利用率，并影響我們達(dá)到高數(shù)據(jù)包速率的能力。

我們確實(shí)研究過像io_uring和af_xdp這樣的解決方案。io_uring顯然具有很多潛力，它擁有許多吸引人的特性，為你提供了人們期望的異步直接訪問接口。然而，這是一個(gè)新的API，將其融入現(xiàn)有的堆棧中，如機(jī)器學(xué)習(xí)，需要時(shí)間。也許將來會(huì)實(shí)現(xiàn)。零拷貝RX路徑仍在開發(fā)中，需要付出大量努力才能有效地實(shí)現(xiàn)零拷貝RX并獲得所需的結(jié)果。

我們?cè)谝欢ǔ潭壬涎芯苛薬f_xdp，但基本上跳過了它。因?yàn)閄DP的主要目標(biāo)是將數(shù)據(jù)包快速送入用戶空間，而協(xié)議棧仍然是一個(gè)待解決的問題。因此，它更接近我之前提到的DPDK解決方案。但實(shí)際上，你并沒有獲得一個(gè)經(jīng)過良好測(cè)試、可互操作且高效運(yùn)行的堆棧。

那么，我們構(gòu)建了什么呢？我們構(gòu)建的方式看起來像右側(cè)這張相當(dāng)復(fù)雜的圖片。從這張圖表中可以看出，大部分元素都是Linux堆棧中已有的部分，我們基本上沒有進(jìn)行大的修改，只是進(jìn)行了一些細(xì)微的調(diào)整。核心的部分是我們所稱的核心設(shè)備驅(qū)動(dòng)程序，它負(fù)責(zé)驅(qū)動(dòng)隊(duì)列、進(jìn)行維護(hù)工作，以及執(zhí)行所有必要的操作。我們?cè)诙褩Ｖ刑砑恿艘粋€(gè)非常標(biāo)準(zhǔn)的InfiniBand提供者和驅(qū)動(dòng)程序庫或驅(qū)動(dòng)程序?qū)印?/p>

這張圖表應(yīng)該與你所見過的其他圖表非常相似。你的工作區(qū)域在用戶空間，有工作隊(duì)列和完成隊(duì)列用于發(fā)送和接收工作，你還有一個(gè)提交密鑰，可以直接將緩沖區(qū)發(fā)布到硬件上。這里最獨(dú)特的地方在于這兩個(gè)箭頭。實(shí)際上，我們?cè)趥?cè)通路上收集散射列表，并將其提交到內(nèi)核中的TCP堆棧，使其驅(qū)動(dòng)網(wǎng)絡(luò)驅(qū)動(dòng)程序推送傳輸數(shù)據(jù)包或讀取請(qǐng)求數(shù)據(jù)包。

在接收路徑上，當(dāng)數(shù)據(jù)包到達(dá)時(shí)，我們執(zhí)行完全相同的操作。當(dāng)一個(gè)數(shù)據(jù)包到達(dá)時(shí)，我們通過這個(gè)庫或這個(gè)堆棧，然后將數(shù)據(jù)放入接收隊(duì)列中。而且，數(shù)據(jù)實(shí)際上將要到達(dá)的緩沖區(qū)的內(nèi)存區(qū)域已經(jīng)為硬件所準(zhǔn)備，因此數(shù)據(jù)直接落在緩沖區(qū)所在的內(nèi)存區(qū)域。

因此，這實(shí)際上是一種混合體，與你在現(xiàn)有框架中看到的TCP實(shí)現(xiàn)有所不同。但有趣的是，這張圖表中的每一個(gè)元素都是真實(shí)存在的，我們只是對(duì)Linux堆棧中現(xiàn)有的方案和組件進(jìn)行了重新組合和重新連接。

那么在我們的系統(tǒng)上實(shí)際運(yùn)行起來是怎樣的效果呢？我們采用的模型與之前的描述是一致的。現(xiàn)在，你的機(jī)器學(xué)習(xí)應(yīng)用程序通過NIC與一個(gè)IB Verb堆棧進(jìn)行通信，工作隊(duì)列、發(fā)送和接收隊(duì)列都對(duì)這個(gè)應(yīng)用程序開放。應(yīng)用程序通過驅(qū)動(dòng)程序?qū)⑦@些操作傳輸?shù)皆贑PU上運(yùn)行的內(nèi)核實(shí)現(xiàn)。有效載荷就位于這里，稍后你會(huì)看到我們提供的數(shù)據(jù)，對(duì)比了它在GPU內(nèi)存區(qū)域和CPU內(nèi)存區(qū)域之間的表現(xiàn)。正如之前所提到的，提交隊(duì)列直接接入硬件，發(fā)送和接收工作請(qǐng)求通過內(nèi)核驅(qū)動(dòng)程序進(jìn)行傳遞，并轉(zhuǎn)換為我們的硬件隊(duì)列格式，然后進(jìn)行相應(yīng)的處理。

值得一提的是，數(shù)據(jù)路徑，特別是這個(gè)調(diào)用進(jìn)入TCP/IP堆棧的部分，避開了近年來內(nèi)核堆棧中大量的功能性增加。我們可以稱之為“功能性增加”，即人們一直在使用和添加的各種鉤子，用于劫持或接管數(shù)據(jù)移動(dòng)。我們繞過了所有這些，對(duì)調(diào)用的內(nèi)核函數(shù)進(jìn)行了非常精心的選擇。事實(shí)上，Linux堆棧始終建立在回調(diào)式設(shè)計(jì)的基礎(chǔ)上，因此許多事情可以被隔離并單獨(dú)調(diào)用，而不是從套接字的頂部一直到底部，以及反之亦然地獲取整個(gè)數(shù)據(jù)包。

雖然這個(gè)模塊顯示的是TCP，但另一個(gè)值得注意的地方是，這個(gè)模塊可以是任何東西。我們今天不會(huì)深入討論這一點(diǎn)，但我們所討論的結(jié)構(gòu)模型允許我們用RXE替換這個(gè)模塊。RXE是Linux內(nèi)核中的一個(gè)RoCE實(shí)現(xiàn)。在接下來的討論中，大部分內(nèi)容將保持不變。

我們之前討論過的一個(gè)問題是，在TCP字節(jié)流上放置消息時(shí)的無能或低效性。為了解決這一問題，過去的主要方法是使用iWARP，它位于RDMA堆棧的頂部。通過RDMA over DDP over MPA方案，在TCP的頂部構(gòu)建了RDMA堆棧，以便在正確位置獲得標(biāo)記，并實(shí)現(xiàn)零拷貝的直接數(shù)據(jù)放置。

另一個(gè)選擇，我指的是，這是一個(gè)L5協(xié)議，需要構(gòu)建相當(dāng)復(fù)雜的硬件。而我們正在添加或已實(shí)現(xiàn)的是這個(gè)概念：通過TCP進(jìn)行消息傳遞。我們的方法是在TCP頭部添加一個(gè)小的選項(xiàng)頭，我稱之為“BTH-like”，它就像一個(gè)信息頭，包含了BTH的所有內(nèi)容。假設(shè)它位于標(biāo)準(zhǔn)RoCE數(shù)據(jù)包中BTH標(biāo)頭所在的位置，它允許我們建立消息與隊(duì)列之間的關(guān)聯(lián)，以及確定傳遞消息的位置。特別地，它攜帶了兩個(gè)信息字段：一個(gè)告訴我們操作的階段，我們采用RoCE操作碼；另一個(gè)告訴我們這個(gè)特定字節(jié)集合屬于哪個(gè)消息，以及哪個(gè)字節(jié)偏移對(duì)應(yīng)于該消息的起始位置。

這個(gè)方案類似于MPA或MPF標(biāo)頭解決的問題，但它允許我們的硬件根據(jù)消息序列獲取緩沖區(qū)，除了字節(jié)序列外，還能正確處理消息，避免在消息疊加在字節(jié)流上時(shí)的混淆。這使我們相信這是一種更好的方法來解決問題，而不是iWARP。因?yàn)樗褂布３趾?jiǎn)單，允許基本的TCP正常工作。當(dāng)這個(gè)標(biāo)頭出現(xiàn)時(shí)，我們可以增強(qiáng)其功能并做一些更復(fù)雜的事情，而由此產(chǎn)生的效率提升是相當(dāng)明顯的。

然而，這種方法的一個(gè)缺點(diǎn)是我們目前將其添加為TCP選項(xiàng)頭，這意味著中間設(shè)備可能無法正確處理。但對(duì)于我們當(dāng)前關(guān)注的數(shù)據(jù)中心用例，我們認(rèn)為這不是問題。如果人們希望與我們合作，將其納入類似規(guī)范和標(biāo)準(zhǔn)的東西，以便中間設(shè)備可以配合，我們將非常感興趣。

如果沒有數(shù)據(jù)支持，談話就失去了意義。在這里，我為你提供一些相關(guān)數(shù)據(jù)。在查看圖表之前，我想先說明一下，我們展示的基準(zhǔn)系統(tǒng)正是我們正在介紹的FPGA系統(tǒng)。如果你僅在此系統(tǒng)上運(yùn)行TCP和iPerf，我們得到的延遲是幾百微秒。但令人驚訝的是，這個(gè)系統(tǒng)能夠以4K MTU或4K消息大小的速度達(dá)到每秒三百萬個(gè)數(shù)據(jù)包，足以填滿100G的帶寬。

基于這個(gè)背景，我們?cè)賮碜屑?xì)看看這些圖表。左邊的圖表對(duì)比了我們與標(biāo)準(zhǔn)的RoCE。我想那應(yīng)該是Mellanox CX-5，展示的是CPU到CPU或CPU到GPU之間的傳輸情況。這是針對(duì)熟悉GPU直通技術(shù)的人，其目的緩沖區(qū)來自GPU內(nèi)存。你可以看到，延遲顯然沒有達(dá)到生產(chǎn)中基于硬件的實(shí)現(xiàn)水平。這主要有兩個(gè)原因：一方面，我們?cè)谲浖矫孢€有很多工作要做以提高效率；但另一方面，硬件運(yùn)行的時(shí)鐘頻率只有我們所需的四分之一，并且缺乏許多優(yōu)化。因此，在達(dá)到目標(biāo)之前，我們的很多事務(wù)實(shí)際上需要多個(gè)DMA周期。

然而，我認(rèn)為仍然值得驕傲的是，當(dāng)你開始查看4K和16K的數(shù)字時(shí)，你會(huì)發(fā)現(xiàn)我們的延遲在這些范圍內(nèi)仍然相當(dāng)平穩(wěn)和穩(wěn)定，而這在運(yùn)行標(biāo)準(zhǔn)TCP時(shí)是無法看到的。在吞吐量方面，也許更有趣。同樣，如果你注意到，在4K的表現(xiàn)上，我們確實(shí)比RoCE NIC差得多。這同樣是目前軟件和調(diào)優(yōu)的問題，因?yàn)槲覀冎涝谶\(yùn)行標(biāo)準(zhǔn)TCP時(shí)我們可以達(dá)到100G的數(shù)值，所以這實(shí)際上是我們IB堆棧上的一個(gè)問題。

但更令人振奮的是，我們成功地掌握了曲線，達(dá)到了吞吐量。如果你看看4、16、64K大小的數(shù)據(jù)包，這是大部分機(jī)器學(xué)習(xí)工作重點(diǎn)關(guān)注的地方，我們的堆棧表現(xiàn)非常出色。另外，我應(yīng)該指出的是，我們傳遞給GPU的數(shù)據(jù)，由于其再次通過我們的解決方案，與其他解決方案相比，其延遲稍微低一些。

最后一個(gè)圖表將展示我們?cè)谶@里要強(qiáng)調(diào)的關(guān)鍵點(diǎn)。通過我們所做的工作，有效地將堆棧與應(yīng)用程序的其余部分以及服務(wù)這些操作的內(nèi)存（在我們的案例中為GPU）隔離開來。你會(huì)發(fā)現(xiàn)，這實(shí)際上會(huì)帶來更好的TCP性能。讓我為你解釋一下。

紅色和藍(lán)色的圖表再次展示了標(biāo)準(zhǔn)的CPU到CPU和CPU到GPU操作。而黃色和青色的圖表則揭示了當(dāng)存在內(nèi)存訪問競(jìng)爭(zhēng)者時(shí)，這兩條曲線會(huì)發(fā)生什么變化。為了模擬這種情況，我們?cè)谙到y(tǒng)上運(yùn)行了stress-ng，并在后臺(tái)最大限度地增加了DRAM的訪問量。你會(huì)看到，CPU到CPU路徑開始出現(xiàn)問題，有時(shí)甚至?xí)a(chǎn)生嚴(yán)重的性能下降。而CPU到GPU路徑則能夠保持其性能，因?yàn)镚PU存儲(chǔ)控制器并沒有受到stress-ng的太大影響。盡管藍(lán)色和黃色的曲線略有偏移，但它們的峰值仍然保持在預(yù)期的位置。

因此，這個(gè)隔離模型不僅有效，而且實(shí)際上解決了一些性能問題，特別是與TCP性能要求相關(guān)的問題。

總之，通過讓操作系統(tǒng)讓步，將RDMA應(yīng)用作為L(zhǎng)inux TCP堆棧之上的應(yīng)用程序接口，你將能夠看到性能上的顯著提升。

-----

可以支持RDMA讀寫流，那么可以支持的最大消息大小是多少？

是的，我們確實(shí)支持RDMA讀寫流。關(guān)于您提到的最大消息大小，我們的BTH頭部策略中包含一個(gè)OP code，這使得我們可以在硬件中靈活地處理不同的處理上下文或其他RDMA操作。目前，我們?cè)谠擃^部設(shè)定了一個(gè)24位消息大小，這一設(shè)計(jì)選擇是基于實(shí)現(xiàn)上的多種因素考慮，旨在達(dá)到一個(gè)性能與復(fù)雜性的平衡。即使在處理高達(dá)800G和TB級(jí)的消息吞吐量時(shí)，這一設(shè)計(jì)也不會(huì)成為性能瓶頸。同時(shí)，在重試或類似操作中，它也不會(huì)增加太多復(fù)雜性。

還有一些限制，也就是我們硬件的這種FPGA近似，有些事情我們的設(shè)備做得更好。

來自Peter Gotzman的問題，關(guān)于Lipsy控制路徑加IB verbs數(shù)據(jù)路徑，應(yīng)用程序是否需要采取特殊步驟來分配和固定緩沖區(qū)，我很好奇應(yīng)用程序需要改變多少。

對(duì)于RDMA應(yīng)用程序來說，它們可以正常工作，無需進(jìn)行其他更改。但如果你打算嘗試某種應(yīng)用程序級(jí)的混合操作，我建議你使用RDMA機(jī)制進(jìn)行注冊(cè)，然后按你的需要進(jìn)行。

Bernard的問題，你是否了解過軟件iWARP？它很好地印證了你對(duì)于PDU傳遞復(fù)雜性的觀點(diǎn)，然而，當(dāng)采用分段卸載的方式時(shí)，它的性能表現(xiàn)得相當(dāng)出色。

是的，這與我們的觀察結(jié)果相吻合。以NVMe-TCP為例，我們投入了大量時(shí)間去研究其內(nèi)在含義。在實(shí)際操作中，我們可以協(xié)助硬件進(jìn)行分段和分段信號(hào)的處理。然而，這些上層類型方案的問題在于，最壞情況下的性能可能會(huì)非常糟糕。尤其是當(dāng)在PDU邊界上進(jìn)行重傳時(shí)，而這部分操作已經(jīng)完成并跨越了多條消息。

實(shí)際上，有人提出這個(gè)問題，我感到很高興。因?yàn)槲乙蚕朐谶@方面發(fā)表一些看法。你的觀點(diǎn)是正確的。確實(shí)存在處理基于PDU的協(xié)議的方法，但其中存在一個(gè)基本的區(qū)別。那就是，如果你需要查看TCP流以找到PDU邊界，那么你需要全面查看TCP的完整負(fù)載。這將更加昂貴，并且不太適合無狀態(tài)的卸載。相比之下，如果數(shù)據(jù)包邊界與消息邊界對(duì)齊，那么處理起來會(huì)更加高效。

這意味著，由于你能夠獲得數(shù)據(jù)包邊界，因此你只需要在數(shù)據(jù)包傳輸過程中簡(jiǎn)單地處理其頭部信息。而有效負(fù)載部分可以更接近零拷貝，正如Shrijeet所提到的，這些數(shù)據(jù)可以直接發(fā)送到GPU或類似設(shè)備進(jìn)行處理。

還有一個(gè)問題來自Sean，關(guān)于RDMA的后續(xù)問題。在該頭部中沒有RKEY。

是的，我們?cè)谀抢锊]有放置完整的結(jié)構(gòu)。在RoCE中，RKEY并不位于BTH中，而是位于BTH后的擴(kuò)展頭部中。所以，我們的處理方式其實(shí)是類似的。如果TCP BTH中的OP code表示后面有一個(gè)用于RDMA操作的擴(kuò)展頭部，那么你會(huì)在那里查找任何內(nèi)存鍵或其他內(nèi)容。我們目前還沒有深入研究原子操作，但理論上來說，這也是可行的。當(dāng)然，我并不想過于預(yù)測(cè)未來，但理論上，你可以在那里放置一個(gè)原子擴(kuò)展頭部，或者任何與RoCE和InfiniBand類似的內(nèi)容。

至于我想說的，Sean，我們正在尋求關(guān)于這個(gè)頭部需要什么的參與或合作。另外，你關(guān)于層次結(jié)構(gòu)的具體問題，我認(rèn)為，引發(fā)了我們應(yīng)該放置什么以及是否放置過多的問題。這可能會(huì)導(dǎo)致TCPE選項(xiàng)頭部存在大小限制和擴(kuò)展的含義。

審核編輯：劉清