專利名稱：提高tcp重發(fā)處理速度的制作方法
技術(shù)領(lǐng)域：
本發(fā)明一般涉及數(shù)據(jù)傳輸，更具體地，涉及對對齊的DDP報文段實施切入直通的支持RDMA的網(wǎng)絡(luò)接口控制器(RNIC)。
背景技術(shù)：
1.概述參照圖1A，示出常規(guī)數(shù)據(jù)傳輸環(huán)境1的方框圖。數(shù)據(jù)傳輸環(huán)境1包括數(shù)據(jù)源2(即，對等節(jié)點)，其將數(shù)據(jù)傳輸3A經(jīng)過一個或是多個支持遠程數(shù)據(jù)存儲器存取(RDMA)的網(wǎng)絡(luò)接口控制器(RNIC)4發(fā)送到接收數(shù)據(jù)傳輸3B的數(shù)據(jù)宿5(即，對等節(jié)點)。RNIC4除其它外(下面將進一步解釋)包括重組緩沖器6。近年來網(wǎng)絡(luò)通信速度從10百萬比特每秒(Mbps)經(jīng)100Mbps迅速提高到1千兆比特每秒(Gbps)，直到現(xiàn)在速度接近10Gbps的范圍。然而，通信帶寬的增加現(xiàn)在開始超過中央處理器(CPU)有效處理數(shù)據(jù)的速度，這就導致產(chǎn)生例如是RNIC4的服務(wù)器處理器的瓶頸。例如，普通的1Gbps網(wǎng)絡(luò)連接如果完全利用的話，可對2Ghz CPU造成大的負荷。具體地，類似這種的CPU可擴展大約一半它的處理能力來處理來自網(wǎng)卡的數(shù)據(jù)的低層傳輸控制協(xié)議(TCP)處理。
解決該問題的一個方法是在硬件有限狀態(tài)機(FSM)中實施傳輸控制和Internet協(xié)議(TCP/IP)棧，而不是將其作為軟件由CPU來處理。該方法允許速度很快的包處理，從而產(chǎn)生對連續(xù)的短包的網(wǎng)速處理。此外，該方法提出了簡單有效且成本低的解決方案。不幸地是，由于對TCP/IP棧的定義和開發(fā)都是針對在軟件中實施，所以在硬件中生成TCP/IP棧會導致大范圍內(nèi)的新問題。例如，出現(xiàn)的問題包括如何在硬件FSM中實現(xiàn)基于軟件的協(xié)議并實現(xiàn)改進的性能，如何設(shè)計對上層協(xié)議(ULP)(例如，應用協(xié)議)有利和有效的接口，從而提供對ULP的迅速實施，以及如何避免在比例增大的實施中新的瓶頸。
為了解決這些新的問題，開發(fā)了新的通信層，使其設(shè)置在傳統(tǒng)的ULP和TCP/IP棧之間。不幸地是，放置在TCP/IP棧的協(xié)議通常需要大量的拷貝操作，因為ULP必須為間接的數(shù)據(jù)放置提供緩沖，這就增加了延遲并且消耗重要的CPU和存儲資源。為了減小拷貝操作的數(shù)量，一套稱為iWARP的新的協(xié)議，被開發(fā)出來。
2.協(xié)議現(xiàn)在參照圖1B對不同協(xié)議，包括iWARP協(xié)議和數(shù)據(jù)傳輸格式結(jié)構(gòu)，進行簡要描述。可以看出，每個數(shù)據(jù)傳輸可包括與許多不同協(xié)議有關(guān)的信息，每個協(xié)議都用來提供與該數(shù)據(jù)傳輸有關(guān)的不同功能。例如，如圖1B所示，以太網(wǎng)100提供由IEEE標準802.3定義的局域網(wǎng)(LAN)接入；Internet協(xié)議(IP)102添加所需的網(wǎng)絡(luò)路由信息；傳輸控制協(xié)議(TCP)104設(shè)定出站的TCP棧106并且滿足對傳送的保障；協(xié)議數(shù)據(jù)單元(PDU)對齊標志(MPA)協(xié)議108提供了MPA幀109，其包括以固定間隔(即，每512個字節(jié))通過DDP報文段112(僅示出一個，但可以是流)的靠后的MPA標志110，并且還向每個MPA幀109添加長度域114和循環(huán)冗余校驗(CRC)域116。此外，直接數(shù)據(jù)放置(DDP)協(xié)議120報文段向一個或多個DDP報文段112輸出消息，并將一個或多個DDP報文段重組成DDP消息113；而遠程數(shù)據(jù)存儲器存取(RDMA)協(xié)議122轉(zhuǎn)換RDMA寫、讀、發(fā)送入/出DDP消息。盡管為了清晰起見僅示出了一個DDP報文段112，應該認識到許多的DDP報文段112可被提供在每個TCP報文段106中。
具體地針對RDMA協(xié)議122而言，該協(xié)議由RDMA聯(lián)盟開發(fā)，通過允許一臺計算機以最小的存儲器總線帶寬需求和中央處理器(CPU)處理開銷向另一臺計算機的存儲器直接放置信息，可去除數(shù)據(jù)拷貝操作并減小延遲，而同時維持了存儲器的保護語義。TCP/IP承載的RDMA通過減小在處理器和存儲器上的開銷負擔來實現(xiàn)在數(shù)據(jù)中心內(nèi)的更有效地和可升級的計算和數(shù)據(jù)傳送，這使得處理器資源可用于其它的工作，例如用戶應用，以及提高基礎(chǔ)利用。在這種情況中，與較大的更昂貴的系統(tǒng)中的中央式操作相比，隨著網(wǎng)絡(luò)變得更加有效，通過在網(wǎng)絡(luò)中共享任務(wù)，應用也將變得更好衡量。依靠RDMA的功能性，發(fā)送方可使用組幀將報頭放在以太網(wǎng)字節(jié)流上，從而使這些字節(jié)流更容易被解碼并在接收方以失序的模式來執(zhí)行，這將會提高性能，尤其對于Internet小型計算機系統(tǒng)接口(iSCSI)和其它的存儲通信量類型來說。RDMA帶來的另一個優(yōu)點是能夠會聚較少類型的互連上的數(shù)據(jù)中心內(nèi)的功能。通過對較少類型互連上的功能進行會聚，得到的基礎(chǔ)結(jié)構(gòu)具有較低的復雜度、更便于管理并且提供了結(jié)構(gòu)冗余的機會，這就提高了系統(tǒng)的彈性。
具體地針對DDP協(xié)議而言，該協(xié)議引入了一種機制，通過該機制，數(shù)據(jù)可直接被放置到上層協(xié)議(ULP)的接收緩沖器中，而無需中間緩沖器。DDP減少并且在一些情況中消除了由支持RDMA的網(wǎng)絡(luò)接口控制器(RNIC)在處理進站的TCP報文段時所執(zhí)行的額外拷貝(去向和來自重組緩沖器)。
3.挑戰(zhàn)在硬件設(shè)置中有效實施具有RDMA和DDP的TCP/IP的一個挑戰(zhàn)是TCP/IP卸載引擎(TOE)的實施包括接收邏輯內(nèi)的重組緩沖器以設(shè)置失序的接收到的TCP流，這就增加了拷貝操作。此外，為了完成將數(shù)據(jù)直接放置到接收方的數(shù)據(jù)緩沖器中，RNIC必須能夠為每一個到達的TCP報文段凈荷127確定目標緩沖器。結(jié)果是，所有的TCP報文段都保存到重組緩沖器來確保他們是有序的并且目標緩沖器可被找到。為了解決該問題，iWARP規(guī)范強烈建議發(fā)送RNIC來以這樣的一種方式執(zhí)行RDMA消息的分段，即生成的DDP報文段應與TCP報文段“對齊”。然而，非對齊的DDP報文段經(jīng)常是不可避免的，尤其對于數(shù)據(jù)傳輸經(jīng)過了許多交換的地方。
參照圖1B，“對齊”意味著DDP報文段112緊跟著TCP報頭126(即，MPA報頭跟著TCP報頭，接著DDP報頭跟著MPA報頭)，并且DDP報文段112完全包含在一個TCP報文段106內(nèi)。更具體地，每個TCP報文段106包括TCP報頭126和TCP凈荷/TCP數(shù)據(jù)127?！癟CP洞”130是TCP數(shù)據(jù)流中丟失的TCP報文段。MPA標志提供了當接收到失序的TCP報文段106時，而接收方想知道位于TCP報文段106內(nèi)的MPA幀109是否與TCP報文段106對齊的數(shù)據(jù)。每個標志110以相等的間隔(512字節(jié))放置在TCP流中，其以具體連接的初始序列號開始，并且指向它游歷其中的MPA幀109的DDP/RDMA報頭124。第一順序識別號分配給第一TCP報文段106，而在隨后的TCP報文段106中每個初始序列號包括增加的序列號。
在圖1B中，實線示出對齊的數(shù)據(jù)傳輸?shù)睦?，其中TCP報頭126由MPA長度域114和DDP/RDMA報頭124緊跟著，并且DDP報文段112完全包含在TCP報文段106中。DDP協(xié)議120層中的虛線表示非對齊的DDP報文段112NA，其中MPA長度域114和DDP/RDMA報頭124沒有緊跟著TCP報頭126。非對稱的DDP報文段可例如來自由介于發(fā)送和接收RNIC之間的中間體的再分段，或是最大報文段大小(MSS)的迅速減小。由于發(fā)送方RNIC無法改變DDP分段(改變TCP流中DDP報頭的位置)，重發(fā)操作可能需要新的減小的MSS，盡管原始生成的DDP分段具有較大的MSS。在任意的情況中，拷貝操作的增加都會減小速度和效率。因此，現(xiàn)有技術(shù)中需要一種方法以不同的方式來解決對齊的DDP報文段的放置以及傳送，而不是非對齊DDP報文段的放置和傳送。
關(guān)于非對稱DDP報文段112NA處理的另一個挑戰(zhàn)是由這樣一種事實造成的，即通常確定什么導致了該非對稱是困難的。例如，單個的非對稱DDP報文段112NA可在兩個或是多個TCP報文段106之間分割，而它們中的一個可能會到達而另一個則可能不會到達。在另一種情況中，一些DDP報文段112NA可落入到MPA標志110之間，報頭可能丟失，或是段尾可能丟失(在后一種情況中，在它到達時，你可部分的放置該報文段并且需要保留一些信息來知道將剩余部分放置到什么位置)等。關(guān)于后一種情況，圖1C示出涉及用于一個或是多個非對稱DDP報文段112NA的MPA標志標注的可能情況的方框圖。情形A示出其中由先前處理過的DDP報文段166的MPA長度域164指向新接收到的DDP報文段162的DDP報文段報頭160的情況。情形B示出其中由位于新接收到的DDP報文段162內(nèi)的標志168指向的新接收到的DDP報文段報頭160的情況。即，標志168表示新接收到的DDP報文段162的開始。情形C示出其中標志168位于新接收到的DDP報文段162內(nèi)，但卻指向該報文段外部的情況。情形D示出其中標志168位于新接收到的DDP報文段162內(nèi)并指向該報文段內(nèi)部的情況。情形E示出其中沒有標志位于新接收到的DDP報文段162中的情況。無論如何，在無法確定DDP報文段非對稱原因的地方，RNIC不能執(zhí)行直接的數(shù)據(jù)放置，因為對于充分地尋址來說有太多的情況，并且要在中間存儲器內(nèi)保留太多的信息/部分報文段。因此，任何可提供對對稱和非對稱DDP報文段處理的方案應該能夠解決可能導致該非對稱的各種情況。
4.DDP/RDMA操作流程參照圖1D-1H，為了稍后的論述，在此對DDP/RDMA操作流程作簡要概述。具體地針對DDP協(xié)議120(圖1B)而言，DDP提供兩種類型的消息，稱之為標記消息和非標記消息。參照圖1D，在“標記消息”中，每個DDP報文段112(圖1B)攜帶有DDP/RDMA報頭124內(nèi)的轉(zhuǎn)向標記(“STag”)，用來識別數(shù)據(jù)可被直接放置的接收方上目標緩沖器內(nèi)的存儲區(qū)/窗口(例如，圖1G中的存儲區(qū)232)、該區(qū)域/窗口內(nèi)的目標偏移(TO)以及報文段凈荷(沒有示出)。在這種情況中，目標緩沖器的可用性經(jīng)Stag被“廣告”。參照圖1E，在“非標記消息”中，遠端的發(fā)送方不知道接收方的緩沖器并發(fā)送帶有隊列ID(QN)、消息序列號(MSN)和消息偏移(MO)的消息，這些消息可由接收方用來確定合適的緩沖器。
參照圖1F-1H，RDMA協(xié)議定義了四種類型的消息發(fā)送200、寫202、讀204以及讀響應206。返回到圖1A，動詞接口(verb interface)7向用戶提供RNIC4，包括分配和解除分配RNIC4資源的方法以及向RNIC4發(fā)送工作請求(WR)208。動詞接口7通常由動詞庫8來實施，該動詞庫具有兩個部分用于服務(wù)用戶空間消耗裝置的用戶空間庫9A以及服務(wù)內(nèi)核空間消耗裝置的內(nèi)核模塊9B。動詞接口7是與RNIC4硬件和固件一起工作的RNIC專用軟件。對在動詞接口7(動詞庫8)、硬件和固件中應該實施什么是沒有嚴格定義的。動詞接口7可以看作是向消耗裝置提供RNIC4業(yè)務(wù)的一個獨立數(shù)據(jù)包，因此消耗裝置可執(zhí)行主要兩種類型的操作對RNIC4資源的管理(分配和解除分配)以及向RNIC4發(fā)送工作請求(WR)。RNIC4資源管理的例子有隊列對的分配和解除分配、完成隊列(以下稱為“CQ”)的分配和解分配或是存儲區(qū)的分配和解除分配。下面將對這些管理任務(wù)進行更為詳細的描述。
如圖1F-1H所示，消耗裝置分配隊列對，工作請求208是向這個隊列對發(fā)送的?！瓣犃袑Α?以下稱為“QP”)是與TCP連接相關(guān)的并且包括一對工作隊列(例如，發(fā)送和接收)210、212和每個隊列的發(fā)送機制(未示出)。每個工作隊列210、212是工作隊列元素(WQE)216的列表，此處每個WQE保留一些描述一個工作請求(WR)208的控制信息并參考(指向)到消耗裝置的緩沖器。消耗裝置向工作隊列210、212發(fā)送工作請求(WR)208，以便使得動詞接口7(圖1A)和RNIC4(圖1A)來執(zhí)行發(fā)送的工作請求(WR)208。此外，還有資源可對消耗裝置無法直接進行相互作用的QP進行補償，例如讀隊列214(圖1H)和工作隊列元素(WQE)216。
可被WQE216保留的常規(guī)信息是消耗裝置工作請求(WR)類型(即，對于發(fā)送WR208S，它可以是RDMA發(fā)送、RDMA寫、RDMA讀等等，而對于接收WR 208R，它只能是RDMA接收)以及對攜帶數(shù)據(jù)以便發(fā)送或是表示接收到的數(shù)據(jù)的位置的消耗裝置的緩沖器的描述。WQE216總是描述/對應單個的RDMA消息。例如，當消耗裝置發(fā)送RMDA寫類型的發(fā)送工作請求(WR)208S時，動詞庫8(圖1A)建立WQE216S，其描述了數(shù)據(jù)需從中取出數(shù)據(jù)的消耗裝置緩沖器，所述數(shù)據(jù)利用RDMA寫消息被發(fā)送到響應方。在另一個例子中，存在接收工作請求(WR)208R(圖1F)。在這種情況中，動詞庫8(圖1A)向接收隊列(RQ)212添加WQE216R，該接收隊列212保留用來放置接收到的發(fā)送消息200凈荷的消耗裝置的緩沖器。
當動詞庫8(圖1A)向發(fā)送隊列(SQ)210或接收隊列(RQ)212添加新的WQE216時，它會向RNIC4通知(這里稱作為“響門鈴”)新的WQE216已經(jīng)被分別添加到發(fā)送隊列(SQ)/接收隊列(RQ)。該“門鈴響”操作通常是向RNIC存儲空間執(zhí)行寫的操作，并由RNIC硬件來檢測和解碼。因此，門鈴響通知RNIC對于指定的SQ/RQ，分別有新的工作要去做。
RNIC4(圖1A)保留具有未決的(被發(fā)送的)WQE216的發(fā)送隊列(SQ)210的列表。此外，RNIC在這些發(fā)送隊列(SQ)210之間進行仲裁并且對它們進行相繼地服務(wù)。當RNIC4選擇發(fā)送隊列(SQ)210來服務(wù)時，它讀取下一個WQE216來服務(wù)(WQE按照消耗裝置發(fā)過來的順序由RNIC進行處理)，并產(chǎn)生一個或是多個屬于被請求的RDMA消息的DDP報文段220。
現(xiàn)在參考圖1F-1H對處理具體類型的RDMA消息進行描述。如圖1F所示，RNIC(請求方)選擇要服務(wù)的具體發(fā)送隊列(SQ)210S。它從發(fā)送隊列(SQ)210S讀取WQE216S。如果該WQE216S對應于RDMA發(fā)送請求，則RNIC生成發(fā)送消息并將該消息發(fā)送到對等節(jié)點RNIC(響應方)。生成的消息可包括，例如，三個DDP報文段220。當RNIC(響應方)接收到發(fā)送消息，它從接收隊列(RQ)212讀取WQE216R，并將接收到的DDP報文段220的凈荷放置到由WQE216R表示的消耗裝置的緩沖器(即，響應方Rx緩沖器)230。如果發(fā)送消息200是有序接收到的，那么RNIC從接收隊列(RQ)212選取第一個未使用的WQE216R。WQE216R按照它們由消耗裝置發(fā)送的順序鏈接在請求隊列(RQ)212內(nèi)。就未標記的DDP消息來說，發(fā)送消息200攜帶消息序列號(MSN)(圖1E)，其初始化為1并由發(fā)送方隨著屬于相同DDP隊列的每個發(fā)送的DDP消息220而單調(diào)性的增加。(下面對涉及RDMA寫消息202的標記消息進行描述)。DDP隊列是由DDP報頭內(nèi)的隊列號(QN)來識別的。RDMA協(xié)議定義了三種DDP隊列用于進站的RDMA發(fā)送QN#0，用于進站RDMA讀請求的QN#1以及用于進站終止的QN#2。因此，當發(fā)送消息200是失序到達時，RNIC 4可利用該消息的MSN來找到對應于發(fā)送消息200的WQE216R。一個接收到的發(fā)送消息200消耗來自接收隊列(RQ)212的一個WQE216R。缺少發(fā)送的WQE，或是消息數(shù)據(jù)長度超過WQE緩沖器的長度被認為是嚴重的錯誤并且會導致連接的終止。
參照圖1G和1H，對利用標記操作的RDMA寫消息202和部分RDMA讀消息204進行描述。為了使用標記操作，消耗裝置需要登記存儲區(qū)232。存儲區(qū)232是接收方虛擬的連續(xù)的固定存儲塊，即圖1G中的響應方。存儲區(qū)232由它的起始虛擬地址(VA)、長度、訪問許可和與該存儲區(qū)232有關(guān)的物理頁列表來描述。登記存儲區(qū)232的結(jié)果是消耗裝置接收回導向標記(Stag)，其可用來訪問登記的存儲區(qū)232。遠端消耗裝置(例如，圖1G中的請求方)對存儲區(qū)232的訪問可由RNIC4在沒有與本地消耗裝置(例如，圖1G的響應方)的任何相互作用下執(zhí)行。當消耗裝置想訪問遠端的存儲區(qū)232時，它分別發(fā)送RDMA寫類型的發(fā)送工作請求(WR)208W或是RDMA讀類型的發(fā)送工作請求(WR)208R(圖1H)。動詞庫8(圖1A)分別向發(fā)送隊列(SQ)210W或210R添加相應的WQE216W(圖1G)或216R(圖1H)，并通知RNIC4。當連接贏得仲裁時，RNIC16分別讀取WQE216W或216R，并生成RDMA寫消息202或是RDMA讀消息204。
如圖1G所示，具體地針對RDMA寫消息202而言，當RDMA寫消息202被RNIC4接收時，RNIC利用STag和TO(圖1D)和DDP報文段報頭(屬于該消息)內(nèi)的長度來尋找登記了的存儲區(qū)232，并將RDMA寫消息202的凈荷放置到存儲器232。接收方軟件或CPU(即所示的響應方)不涉及該數(shù)據(jù)放置操作，并且不會意識到發(fā)生了該操作。
如圖1H所示，具體地針對RDMA讀消息204而言，當消息被RNIC4(圖1A)接收時，RNIC生成RDMA讀響應消息206，并將其發(fā)送回遠端主機，即所示的請求方。在這種情況中，接收隊列被稱作為讀隊列214。生成RDMA讀響應206的操作被執(zhí)行而不涉及本地消耗裝置(即響應方)，其也不會意識到發(fā)生了該操作。當RDMA讀響應206被接收到時，RNIC 4(圖1A)對該消息的處理類似于處理RDMA寫消息204。即，它在請求方側(cè)寫入到存儲區(qū)232。
除了處理消耗裝置的工作請求以外，RNIC4(圖1A)還通知消耗裝置關(guān)于這些請求的完成，如圖1F-1H所示。完成的通知是通過利用完成隊列240來實現(xiàn)的，該完成隊列是另一個RNIC資源并且是由消耗裝置來分配的(經(jīng)由動詞庫8提供的專用功能)。完成隊列240包括完成隊列元素(CQE)242。當CQE242在報告消耗裝置工作請求(WR)208S、208W和208RR完成時，它就被RNIC4(圖1A)放置到完成隊列(CQ)240。每個工作隊列(即，發(fā)送隊列(SQ)210、接收隊列(RQ)212)具有相關(guān)的完成隊列(CQ)240。(注意讀隊列214是由硬件所維持的內(nèi)部隊列，并且對軟件來說是不可見的。因此，沒有CQ240與該隊列相關(guān)，并且消耗裝置既不分配此隊列也不知道它的存在)。然而，應該注意到相同的完成隊列(CQ)240可與多于一個的發(fā)送隊列(SQ)210和接收隊列(RQ)212相關(guān)。相關(guān)是在隊列對(QP)的分配時間執(zhí)行的。在操作中，當消耗裝置向發(fā)送隊列(SQ)210發(fā)送工作請求WR208時，它可以指定在該請求完成時它是否想獲得通知。如果消耗裝置請求完成通知，RNIC4在完成工作請求(WR)時向與發(fā)送隊列(SQ)210相關(guān)的相關(guān)完成隊列(CQ)240放置完成隊列元素(CQE)242。RDMA協(xié)議定義了用于發(fā)送到發(fā)送隊列(SQ)210的工作請求(WR)208的很簡單的完成排序。具體地，RDMA發(fā)送工作請求(WR)208S和RDMA寫工作請求(WR)208W在它們被可靠的發(fā)送后就完成了。當相應的RDMA讀響應消息206被接收并放置到存儲區(qū)232時，RDMA讀工作請求(WR)208R就完成了。消耗裝置工作請求(WR)是按照它們被發(fā)送到發(fā)送隊列(SQ)210的順序來完成的。參照圖1F，每個發(fā)送到接收隊列(RQ)212的工作請求(WR)也請求完成通知。因此，當RNIC4(圖1A)完成接收到的發(fā)送消息200的放置時，它就向與接收隊列(RQ)212相關(guān)的完成隊列(CQ)240放置完成隊列元素(CQE)242。
鑒于上述的描述，現(xiàn)有技術(shù)中需要一種不同于非對齊DDP報文段的放置和傳送的方法來解決對齊的DDP報文段的放置以及傳送。

發(fā)明內(nèi)容
本發(fā)明包括RNIC的實施，該實施執(zhí)行將數(shù)據(jù)直接放置到存儲器，其中所有接收到的具體連接的DDP報文段都是對齊的，或是通過重組緩沖器來移動數(shù)據(jù)，其中具體連接的一些DDP報文段是非對齊的。不用接入到重組緩沖器進行切入直通的連接類型被稱作為“Fast”連接，而其它類型被稱為“Slow”連接。當消耗裝置建立連接時，它指定連接的類型。例如，經(jīng)Internet到達另外一個大洲的連接在到達目的地時具有對齊的報文段的可能性低，因此應該被消耗裝置指定為“Slow”連接類型。另一方面，存儲區(qū)域網(wǎng)絡(luò)(SAN)內(nèi)兩個服務(wù)器的連接使得所有的DDP報文段都對齊的可能性是很高的，因此應該由消耗裝置指定為“Fast”連接類型。連接類型可從Fast變到Slow然后再變回去。本發(fā)明減小了存儲器帶寬、延遲、利用TCP重發(fā)來進行的錯誤恢復并且提供來自空接收隊列的“適度恢復”，即，當對于進站的非標記DDP報文段接收隊列不具有發(fā)送的工作隊列元素(WQE)的情況。常規(guī)的實施是以連接的終止來結(jié)束。相比而言，根據(jù)本發(fā)明的快連接可丟棄此種報文段，并利用TCP重發(fā)方法從這種情況中恢復過來并避免連接的終止。該實施也可在發(fā)送TCP應答確認報文段接收之前對快連接中的大部分進站DDP報文段執(zhí)行循環(huán)冗余校驗(CRC)驗證。這就允許利用TCP可靠服務(wù)從CRC校驗檢測到的損壞數(shù)據(jù)中進行有效的恢復。
本發(fā)明的第一個方面是針對一種用于提高傳輸控制協(xié)議(TCP)重發(fā)處理速度的方法。該方法包括步驟生成涵蓋接收到的TCP報文段的第一重復TCP確認(Ack)，接收到的TCP報文段可由TCP確定為有效并且由TCP基于上層協(xié)議(ULP)判決來丟棄；以及發(fā)送該第一重復TCP Ack。
本發(fā)明的第二個方面是針對一種提高傳輸控制協(xié)議(TCP)重發(fā)處理速度的系統(tǒng)，該系統(tǒng)包括TCP確認(Ack)發(fā)生器，生成涵蓋接收到的TCP報文段的第一重復TCP確認(Ack)，該第一重復TCPAck可由TCP確定為有效并且由TCP基于上層協(xié)議(ULP)判決來丟棄。
本發(fā)明的第三個方面是提供一個計算機程序產(chǎn)品，包括其中具有用于提高傳輸控制協(xié)議重發(fā)速度的計算機可讀程序代碼的計算機可用介質(zhì)，該程序產(chǎn)品包括配置成生成涵蓋接收到的TCP報文段的第一重復TCP確認(Ack)的程序代碼，其中第一重復TCP確認可由TCP確定為有效并且由TCP基于上層協(xié)議(ULP)判決來丟棄。
通過下面對本發(fā)明實施方式的更為詳細的描述，本發(fā)明上述以及其它的特征將變得明顯。


下面參考附圖對本發(fā)明的實施方式進行更為詳細的描述，其中相同的標號代表了相同的組件，其中圖1A示出常規(guī)數(shù)據(jù)傳輸環(huán)境和RNIC的方框圖；圖1B示出常規(guī)TCP/IP承載MPA/RDMA/DDP的數(shù)據(jù)傳輸架構(gòu)的方框圖；圖1C示出指向一個或是多個DDP報文段的可能MPA標志參考的方框圖；圖1D示出常規(guī)標記DDP報頭的方框圖；圖1E示出常規(guī)未標記的DDP報頭的方框圖；圖1F-1H示出不同的常規(guī)RDMA消息數(shù)據(jù)傳輸?shù)姆娇驁D；
圖2A示出根據(jù)本發(fā)明的數(shù)據(jù)傳輸環(huán)境和RNIC的方框圖；圖2B示出圖2A的RNIC的連接上下文的方框圖；圖2C示出圖2A的驗證單元的方框圖；圖3示出RNIC輸入邏輯(即，InLogic)功能的流程圖；圖4A-4B示出用于圖3的InLogic的有限重發(fā)嘗試模式實施例的流程圖；圖5示出根據(jù)可選實施方式的在連接降級后處理TCP報文段的方框圖；圖6示出用于圖3的InLogic的連接升級實施方式的流程圖；圖7示出為了循環(huán)冗余校驗(CRC)計算和驗證而結(jié)合初始序列號協(xié)商實施來使用的MPA請求/回復幀；圖8示出用于CRC計算和驗證的可選的修改后的MPA長度實施的流程圖；圖9示出利用用于CRC計算和驗證的無標志切入直通實施的InLogic的第一可選實施方式的流程圖；圖10示出利用用于CRC計算和驗證的無標志切入直通實施的InLogic的第二可選實施方式的流程圖；圖11示出根據(jù)本發(fā)明的包括讀隊列的RDMA讀消息和讀響應消息數(shù)據(jù)傳輸?shù)姆娇驁D；圖12示出由RNIC輸出邏輯(即，OutLogic)處理的消息的工作隊列元素(WQE)和TCP洞的方框圖；圖13示出根據(jù)本發(fā)明的包括完成隊列元素(CQE)的RDMA發(fā)送消息數(shù)據(jù)傳輸?shù)姆娇驁D；圖14示出圖13的CQE的方框圖。
具體實施例方式
下面提供的提綱僅為了便于組織的目的I.綜述，II.InLogic，III.OutLogic以及IV.總結(jié)I.綜述
A.環(huán)境參照附圖，圖2A是根據(jù)本發(fā)明的一個實施方式的數(shù)據(jù)傳輸環(huán)境10的方框圖。數(shù)據(jù)傳輸環(huán)境10包括數(shù)據(jù)源12(即，對等節(jié)點)，其通過一個或是多個支持遠端存儲器數(shù)據(jù)存取(RDMA)的網(wǎng)絡(luò)接口控制器(RNIC)16向接收數(shù)據(jù)傳輸14B的數(shù)據(jù)宿18(即，對等節(jié)點)發(fā)送數(shù)據(jù)傳輸14A。為了描述的目的，啟動數(shù)據(jù)傳輸?shù)膶嶓w在這里稱為“請求方”，而響應該數(shù)據(jù)傳輸?shù)囊环骄头Q為“響應方”。類似地，發(fā)送數(shù)據(jù)的實體可稱為“發(fā)送方”，而接收數(shù)據(jù)傳輸?shù)膶嶓w可稱為“接收方”。應該可以認識到每個數(shù)據(jù)源12和數(shù)據(jù)宿18在不同的時刻可以是數(shù)據(jù)的發(fā)送方或接收方、或是請求方或響應方，而提供的標注“源”和“宿”僅用于表明初始哪一方實體持有待發(fā)送的數(shù)據(jù)。下面的描述也將上面的所述實體中的一方稱作為“消耗裝置”(因為它們消耗了RNIC16的資源)，此處沒有必要使用更具體的標注?！澳繕司彌_器”可看作是在接收方最終接收數(shù)據(jù)的數(shù)據(jù)存儲器，即，數(shù)據(jù)源12或數(shù)據(jù)宿18的數(shù)據(jù)緩沖器50。每個數(shù)據(jù)源12和數(shù)據(jù)宿18包括用于存儲數(shù)據(jù)的數(shù)據(jù)緩沖器50。
從硬件方面來看，RNIC16可以是任意的網(wǎng)絡(luò)接口控制器，例如網(wǎng)絡(luò)I/O適配器或是具有iWARP和動詞功能的嵌入式控制器。RNIC16還包括動詞接口20、接入控制30、RNIC輸入邏輯(以下稱為“InLogic”)32，重組緩沖器34、內(nèi)部數(shù)據(jù)緩沖器38、RNIC輸出邏輯(以下稱為“OutLogic”)40、連接上下文42、驗證單元44和其它組件46。在實施通過結(jié)合RNIC硬件和RNIC驅(qū)動器(未示出)來執(zhí)行操作時，對于消耗裝置來說，動詞接口20代表了RNIC16。動詞接口20包含動詞庫22，后者具有兩個部分用戶空間庫24和內(nèi)核模塊26。接入控制30可包括任何現(xiàn)在已知的或是后續(xù)開發(fā)的控制到InLogic的接入的邏輯。重組緩沖器34可包括涉及數(shù)據(jù)發(fā)送14A、14B數(shù)據(jù)的臨時存儲的任意機制。具體地，重組緩沖器34通常用于失序TCP流的臨時存儲，如下將對其進行更為詳細的描述。其它組件46可包括其它任意的邏輯、硬件、軟件等，這些對于RNIC16的操作是所需的，但在此不進行描述。
參照圖2B，連接上下文42包括用于存儲特定連接數(shù)據(jù)的多個域。其它上下文數(shù)據(jù)60提供特定連接數(shù)據(jù)，這里不對之進行解釋，但對于本領(lǐng)域的技術(shù)人員來說是可認識到的。根據(jù)本發(fā)明定義了兩種類型的連接快(以下稱為“FAST”)連接和慢(以下稱為“SLOW”)連接。術(shù)語“快”和“慢”指的是傳送對齊的DDP報文段的連接的可能性。連接類型在稱為連接類型62的連接上下文域中識別。SLOW連接可用于RDMA連接，該RDMA連接可作為SLOW連接建立，或由RNIC16在處理進站數(shù)據(jù)期間進行降級，如下對其進行更為詳細的描述。如圖2B中所示的其它域?qū)⒃诒竟_中涉及它們的相關(guān)處理的地方進行描述。參照圖2C，驗證單元44包括對于驗證處理是所需的循環(huán)冗余校驗(CRC)邏輯64、TCP校驗和邏輯66和存儲轉(zhuǎn)發(fā)緩沖器68。
B.RNIC常規(guī)操作返回到圖2A，在操作中，RNIC16經(jīng)控制接入到InLogic32的接入控制30來接收數(shù)據(jù)傳輸14A。正如常規(guī)的操作，用于維持該連接的信息保留在連接上下文42的其它上下文數(shù)據(jù)60(圖2B)中。InLogic32處理數(shù)據(jù)傳輸14A中的進站TCP報文段，執(zhí)行對經(jīng)TCP校驗和邏輯66(圖2C)接收到的TCP報文段的驗證操作，計算經(jīng)CRC邏輯64(圖2C)的MPA CRC，并將FAST連接數(shù)據(jù)流與SLOW連接數(shù)據(jù)流分離。關(guān)于后一個功能，如下將進行更為全面的描述，InLogic32將所有由RNIC16在SLOW連接上接收到的數(shù)據(jù)引導至重組緩沖器34，并以許多種不同的方式來處理FAST連接。關(guān)于FAST連接，如果InLogic32檢測到違反了對齊(即，DDP報頭沒有緊跟在TCP報頭后，并且DDP報文段沒有完全包含在一個TCP報文段內(nèi))，則該連接被降級為SLOW連接，而數(shù)據(jù)被引導至重組緩沖器34。相反，如果沒有出現(xiàn)違反對齊的情況，則InLogic32將對齊的進站DDP流引導至內(nèi)部數(shù)據(jù)緩沖器38，接著引導至OutLogic40，以便直接放置到目標數(shù)據(jù)緩沖器50。可選地，TCP報文段106可被丟棄，并且沒有確認(Ack)發(fā)出，因此就需要對該報文段進行重發(fā)。
OutLogic40在FAST和SLOW連接之間進行仲裁，并執(zhí)行將這兩種類型的流放置到數(shù)據(jù)宿18的數(shù)據(jù)緩沖器50。其中將FAST連接上的對齊的DDP報文段引導至內(nèi)部數(shù)據(jù)緩沖器38以便直接放置到目標緩沖器的情況被稱之為“切入-直通模式”，這是因為具有對齊的DDP報文段的FAST連接旁路了重組緩沖器34而直接由OutLogic40放置。然而，對于這兩種連接類型來說，只有有序接收到的數(shù)據(jù)流才經(jīng)OutLogic40傳送到數(shù)據(jù)宿18。
II.InLogic參照圖3，將對根據(jù)本發(fā)明的InLogic32的流程圖(圖2A)以及其對數(shù)據(jù)傳輸14A的處理進行進一步的詳細描述。正如上面指出的，InLogic32處理進站的TCP報文段，對接收到的報文段執(zhí)行TCP驗證，計算MPA CRC，以及將FAST連接數(shù)據(jù)流與SLOW連接數(shù)據(jù)流分離。如果沒有特別指出，沒有帶“S”的標號代表圖2A-2C中所示的結(jié)構(gòu)。
在第一步驟S1中，InLogic32過濾屬于RNIC16連接的數(shù)據(jù)傳輸14A的TCP報文段106，并且為接收到的報文段獲取具有經(jīng)過計算的CRC驗證(經(jīng)驗證單元44)的包。(注意CRC驗證應該在InLogic32判定處理前進行。在步驟S2中將TCP報文段106識別為屬于FAST連接的連接之前，CRC驗證也可以與TCP校驗和計算同時進行)在步驟S2中，InLogic32檢測TCP報文段106是否屬于SLOW連接。在這種情況中，InLogic32確定發(fā)送方如何標注該連接。如果為YES，則在步驟S3中，TCP報文段106被引導至重組緩沖器34，并且TCP邏輯認為該報文段被成功接收。
如果是NO，則在步驟S4中，InLogic32繼續(xù)確定TCP報文段106的長度是否大于聲明的MPA報文段長度。也就是說，在TCP報頭126中聲明的TCP報文段106的長度是否大于在MPA長度域114中聲明的MPA長度。如果是YES，這就表示TCP報文段106包括多個DDP報文段112，該處理將在下面進行描述。如果是NO，這就表示TCP報文段106包括單個的DDP報文段112或是112NA。
在后一種情況中，InLogic32在步驟S5確定MPA長度是否大于TCP報文段106長度。如果是YES，則表示這三種情況之一1)單個的DDP報文段112NA沒有對齊TCP報文段106，被認為是MPA長度域的域不是長度域；2)單個DDP報文段112的起始與TCP報文段106對齊，但單個DDP報文段的長度超過了TCP報文段106的凈荷大??；或3)接收到的單個DDP報文段112與TCP報文段106對齊，但具有損壞了的MPA長度域114。前兩種情況(1和2)表明非對齊的單個DDP報文段112NA在FAST連接上被接收，從而在步驟S3中該連接被降級為SLOW連接。第三種情況(3)不需要連接的降級。然而，由于導致MPA幀109的長度超過TCP報文段106長度的原因無法被識別和確認，所以將該TCP報文段106丟棄(即，撤銷和不傳輸)是不明智的，因為這會導致死鎖(上述的情況2)。即，如果這類TCP報文段確實攜帶有非對齊的DDP報文段，發(fā)送方將按照相同的流程重發(fā)相同的非對齊DDP報文段，這將由接收方重復的丟棄而導致死鎖。因此，在步驟S3中，InLogic32引導TCP報文段106的數(shù)據(jù)傳輸至重組緩沖器34，安排Ack來確認TCP報文段106被順利接收，并將該連接降級至SLOW連接(即，圖2B中的連接類型域62從FAST轉(zhuǎn)為SLOW)。如下所描述的，如果OutLogic40檢測到MPA長度域114被損壞(上述情況3)，則該連接將會因為由驗證單元44檢測到發(fā)生CRC錯誤而被關(guān)閉。因此，在步驟S3該連接的降級不會因為在對齊的DDP報文段112中出現(xiàn)數(shù)據(jù)損壞而導致FAST連接永久性地成為SLOW連接。
返回到步驟S5，如果MPA長度沒有大于TCP長度，即是NO，這就表示MPA幀109長度匹配(相等)于TCP報文段106長度。InLogic32在步驟S6繼續(xù)確定是否該CRC驗證結(jié)果對于該TCP報文段106是有效的。即，是否CRC邏輯64返回“有效”的表示。如果是YES，則表明單個DDP報文段112恰好合適TCP報文段106的邊界(即，長度是彼此相等的)，并且對該報文段沒有檢測到數(shù)據(jù)損壞。結(jié)果是，在步驟S7，單個DDP報文段112通過將接收到的TCP報文段106放置到RNIC16的內(nèi)部數(shù)據(jù)緩沖器38來用于OutLogic40的處理而以“快速通道模式”被處理，這將接收到的TCP報文段106直接放置到例如數(shù)據(jù)宿18的接收方的目標緩沖器50。此外，Ack被安排用來確定該TCP報文段106的成功接收。
如果CRC邏輯64返回“無效”的表示，即，在步驟S6是NO，這表示根據(jù)本發(fā)明可確定存在著五種可能情況中的一種。圖1C示出五種可能的情況，步驟S8-S10示出InLogic32如何處理每一種情況。在任何情況下，處理的目標是1)避免非對齊連接的終止，即使是那些被發(fā)送方聲明為FAST連接的；2)減小由于屬于FAST連接的非對齊的DDP報文段中的數(shù)據(jù)被損壞而導致連接終止的可能性；3)維持InLogic32盡可能的簡易，并且同時將分別處理的情況數(shù)減至最小。
在步驟S8，如圖1C所示的情形A，InLogic32確定先前處理的DDP報文段166的MPA長度域164是否指向新接收到的DDP報文段162的DDP報文段報頭160。在這種情況中，在對新接收到的DDP報文段162的MPA CRC驗證期間先前處理的DDP報文段166的MPA長度被檢測，因此就指出了下一報文段中的DDP報頭160的正確位置。在步驟S6，對情形A的CRC驗證意味著單個DDP報文段162的數(shù)據(jù)或是報頭160被損壞了。新接收到的報文段162的TCP重發(fā)解決了該問題。因此，在步驟S9，TCP報文段106被丟棄并且報文段接收被認為是沒有被確認。
如果先前處理的DDP報文段166的MPA長度域164沒有指向新接收到的DDP報文段162的報頭160(即，在步驟S8是NO)，如圖1C所示的情形B，InLogic32在步驟S10繼續(xù)確定新接收到的DDP報文段162內(nèi)的標志168是否指向新接收到的DDP報文段162的報頭160。即，標志168代表了新接收到的DDP報文段162的開始。在這種情況中，在步驟S6，CRC無效表示1)標志168攜帶正確的值，而新接收到的DDP報文段162具有損壞了的DDP報頭160或是數(shù)據(jù)，或2)位于新接收到的報文段162內(nèi)的標志168已經(jīng)被損壞。在這兩種情況中，新接收到的DDP報文段162的重發(fā)解決了該問題。因此，在步驟S9，該TCP報文段被丟棄并且報文段接收沒有被確認。
如果位于新接收到的DDP報文段162內(nèi)的標志168沒有指向新接收到的DDP報文段162的報頭160，即，在步驟S10是NO，那么就存在著三種情況之一。首先，如圖1C中的情形C所示，標志168位于新接收到的DDP報文段162內(nèi)，但卻指向該報文段外。其次，如圖1C中的情形D，標志168位于新接收到的DDP報文段162內(nèi)，但指向了該報文段的內(nèi)部。再次，如圖1C中的情形E，沒有標志位于新接收到的DDP報文段162內(nèi)。
在情形C、D和E中，CRC邏輯64返回無效表示的原因是不確定的并且可以是數(shù)據(jù)損壞和/或是非對齊DDP報文段112NA的接收造成的結(jié)果(圖1B)。無限制的重發(fā)此類報文段可導致非對齊DDP報文段112NA情況中的死鎖。為了避免潛在的死鎖，如步驟S3所示，InLogic32通過將新接收到的DDP報文段162引導至重組緩沖器34，安排Ack來確認對該報文段的成功接收，并將該連接降級成SLOW連接，來處理情形C、D和E。如果CRC邏輯64由于對齊DDP報文段112內(nèi)的數(shù)據(jù)損壞而返回無效表示，則當處理該SLOW連接的數(shù)據(jù)時，該錯誤如下所述可由OutLogic40檢測，并且該連接將被終止。否則，該連接將永遠保持SLOW連接。然而，下面將描述的有限次重發(fā)嘗試模式可防止該問題。
返回到圖3的步驟S4，如果InLogic32確定TCP報文段106長度大于MPA幀109長度，這就表明TCP報文段106包括多個DDP報文段112。在這種情況中，在步驟S11，從第一個到最后一個DDP報文段112對CRC邏輯64的驗證結(jié)果按順序執(zhí)行檢測。如果所有的DDP報文段112具有有效的CRC，即，是YES，則所有的DDP報文段112都全部包含在TCP報文段106中，并且所有的都是有效的、嚴格對齊的DDP報文段112。在這種情況中，在步驟S7，InLogic32通過將接收到的TCP報文段106放置到RNIC16的內(nèi)部數(shù)據(jù)緩沖器38以便由OutLogci40來處理，從而以快通道模式處理DDP報文段112，其中，OutLogci40將接收到的TCP報文段106放置到例如數(shù)據(jù)宿18的數(shù)據(jù)緩沖器50的目標緩沖器。此外，安排Ack來確認該TCP報文段106的成功接收。當?shù)谝粋€錯誤被檢測到時，InLogic32停止檢測CRC驗證結(jié)果，對該操作管理的描述涉及步驟S12-S13。
在步驟S12，InLogic32確定由CRC邏輯64確定的第一個DDP報文段112是否具有無效的CRC。如果是YES，則InLogic32以類似于處理單個DDP報文段的無效CRC情況的方式(步驟S8)來處理該第一DDP報文段112。即，InLogic32將具有無效CRC的第一DDP報文段112作為單個DDP報文段112并繼續(xù)確定是什么導致該CRC無效，即，圖1C的情形A-E中的哪一個適用，以及如何適當?shù)靥幚碓撉闆r。
如果步驟S12結(jié)果是NO，即，第一DDP報文段112具有有效的CRC，則接著在步驟S13中確定當檢測中間或是最后的DDP報文段112時，CRC的無效性是否已經(jīng)被檢測出。如果是YES，則InLogic32(圖1)前進到步驟S9，因為該錯誤表示導致CRC無效的DDP報文段112的數(shù)據(jù)或是報頭已經(jīng)被損壞(即，先前具有有效CRC的DDP報文段的長度)。即，該CRC錯誤在相同TCP報文段106內(nèi)的中間或是最后一個DDP報文段112中被檢測出，這意味著先前的DDP報文段具有有效的CRC，因此之前的DDP報文段的長度指向具有無效CRC的報文段的報頭。這與對情形A(圖1C)的描述是匹配的。因此，如情形A所述，該報頭的位置是已知的，因此可以知道CRC錯誤是數(shù)據(jù)或是報頭的損壞而導致的。因此，對整個TCP報文段的重發(fā)應該可以解決該問題，而不會有發(fā)生死鎖情況的危險。在步驟S9，該TCP報文段被丟棄，而報文段接收沒有得到確認。
如果步驟S13的結(jié)果是NO，即中間或最后一個DDP報文段112沒有導致CRC無效，那么這就表示最后一個DDP報文段112的MPA長度域114超過了TCP報文段106的邊界，即，最后一個DDP報文段位于TCP報文段106邊界的外部或是太長了。在這種情況中，InLogic32處理該情況的方式與處理太長的單個DDP報文段112相同。具體地，InLogic32在步驟S3繼續(xù)將TCP報文段106的數(shù)據(jù)傳輸14A引導至重組緩沖器34，安排Ack來確認該TCP報文段106被成功接收，并將該連接降級為SLOW連接。通過這種方式，死鎖被避免。如果RNIC16決定丟棄包含在TCP報文段106中多個DDP報文段112中的一個，則整個TCP報文段106都被丟棄，這就簡化了實施并且減小了需處理的情況數(shù)。
盡管在上面沒有明確的討論，但應該認識到其它的數(shù)據(jù)傳輸處理也可結(jié)合上述描述的InLogic32的操作來實施。例如，執(zhí)行屬于RNIC16的TCP報文段的過濾以及接收到的報文段的TCP/IP驗證也可包括經(jīng)TCP校驗和邏輯66(圖2C)的校驗和驗證。對進站的TCP報文段106的處理還可包括對MPA CRC的計算以及經(jīng)CRC邏輯64(圖2C)對該CRC的驗證。一個CRC計算和驗證的具體實施方式
將在下面進一步進行描述。
A.有限次重發(fā)嘗試模式作為涉及檢測到的錯誤的原因的不確定性的可選實施方式(例如，圖3的步驟S10的NO就是可以導致此類情況產(chǎn)生的一個示例性確定)，可實施“有限次重發(fā)嘗試模式”來限制重發(fā)嘗試的次數(shù)從而避免死鎖并可減小FAST連接的次數(shù)而無需降級為SLOW連接。具體地，如上所指出的，情形C、D和E代表幾種情況，其中由于檢測到的錯誤的原因的不確定性，當該錯誤是由數(shù)據(jù)損壞而不是DDP報文段112對齊的失敗造成時，該連接可被降級至具有潛在的連接終止(由OutLogic40執(zhí)行)的SLOW連接(步驟S3)。
為了限制重發(fā)嘗試次數(shù)，本發(fā)明向連接上下文42(圖2B)提供額外的域，從而在降級該連接之前允許一定次數(shù)的重發(fā)。具體地，如圖2B所示，連接上下文42包含一組域290，包括多個恢復嘗試域(RecoveryAttemptsNum)292，最后一個恢復序列號域(LastRecoverySN)294和最大恢復嘗試次數(shù)域(MaxRecoveryAttemptsNum)296。RecoveryAttemptsNum域292保留自從上次更新以來對該連接所執(zhí)行的恢復嘗試的次數(shù)；LastRecoverySN域294保留最后一次啟動的恢復操作的序列號(SN)；而MaxRecoveryAttemptsNum域296定義了在降級該連接之前應該由InLogic32執(zhí)行的最大恢復嘗試次數(shù)。
參照圖4A，在操作過程中，當InLogic32檢測到新的按順序接收到的數(shù)據(jù)傳輸包含有錯誤時(一般地由圖4A中步驟S101示出)，它不是直接將連接降級為SLOW連接(圖3中的步驟S3)，而是為該包含錯誤的數(shù)據(jù)傳輸提供一定次數(shù)的重發(fā)操作。應該可以認識到步驟S101對于由非對齊的DDP報文段112NA或是數(shù)據(jù)損壞導致的多次錯誤確定來說是普遍的做法(步驟S101可適用于，例如，圖3的步驟S5的YES，或是圖3的步驟S10的NO)。在步驟S102，InLogic通過對RecoveryAttemptsNum加1來繼續(xù)記錄該步驟S102包含錯誤的數(shù)據(jù)的傳輸?shù)陌l(fā)送嘗試。此外，InLogic更新LastRecoverySN來存儲先前這里接收到的序列號和新接收的(但丟棄的)數(shù)據(jù)傳輸?shù)男蛄刑柖咧g的最大序列號。即，InLogic更新LastRecoverySN來存儲至少一個先前接收到的包含錯誤的數(shù)據(jù)傳輸和新接收到的包含錯誤(但丟棄的)數(shù)據(jù)傳輸之間的最大序列號。通過比較新接收到的包含錯誤數(shù)據(jù)傳輸?shù)男蛄刑柵c已存儲的最大序列號，新接收到的包含錯誤的數(shù)據(jù)傳輸被確定是具有大于最大序列號的序列號。LastRecoverySN記錄的重要性將在下面變得明顯。
下一步，在步驟S103，InLogic32確定RecoveryAttemptsNum(域292)是否超過MaxRecoveryAttemptsNum(域296)。如果是NO，則在步驟S104，InLogic32丟棄TCP報文段106并且不確認該接收的成功完成，這將導致該TCP報文段的重發(fā)。接著處理返回到步驟S1(圖3)。如果TCP報文段106被損壞，那么重發(fā)將校正該損壞，這樣數(shù)據(jù)傳輸14A就以FAST連接直接放置到存儲器(圖3的步驟S7)?？蛇x地，如果處理持續(xù)返回其它的錯誤檢測(例如，圖3的步驟S10)，則RecoveryAttemptsNum(域292)最終將超過MaxRecoveryAttemptsNum(域296)并在步驟S106產(chǎn)生YES。在這種情況中，InLogic32前進到步驟S105，在該步驟InLogic32將該連接降級為SLOW連接，把包含錯誤的數(shù)據(jù)傳輸14A放置到重組緩沖器34并安排Ack來確認該TCP報文段的成功接收。上述的處理發(fā)生在每一個包含錯誤的數(shù)據(jù)傳輸中。
圖4B表示有限次重發(fā)嘗試模式的另一個組成，該組成針對這樣一種事實，即數(shù)據(jù)損壞通常不是發(fā)生在多個連續(xù)的TCP報文段中，但非對齊的報文段可影響幾個隨后的TCP報文段。例如，F(xiàn)AST連接可維持在一段很長的時間，例如，五個小時，而有時，例如，每一個小時可能有數(shù)據(jù)損壞使得CRC驗證失敗。由于這種情況的發(fā)生，每當包含錯誤的數(shù)據(jù)傳輸(即，損壞的報文段)被丟棄時RecoveryAttemptsNum(域292)都會增加。該處理解決了這樣一種情況，即不同的報文段由于不同期間內(nèi)的數(shù)據(jù)損壞而被丟棄，而在幾次(可能一次)重發(fā)操作之后這些報文段被成功接收并被放置到存儲器。因此，對于這些報文段的恢復操作就成功完成，而不對恢復的數(shù)據(jù)損壞的情況進行計數(shù)，即，當由于新的錯誤報文段的接收而進入到新的恢復模式。
為了從有限次重發(fā)模式中退出，在步驟S105做出對新接收到的按順序的數(shù)據(jù)傳輸?shù)腡CP報文段的序列號(SN)(即，InOderTCPSegmentSN)是否大于LastRecovery序列號(SN)(圖2B中的域294)的判斷。即，屬于FAST連接的每個新接收到的按順序的TCP報文段的序列號與從一個或是多個先前接收到的包含錯誤的數(shù)據(jù)傳輸中選擇出的存儲的最大序列號進行比較。(注意，接收到具有較大SN的失序報文段不意味著錯誤恢復已完成。)然而，恢復完成的一個指標是接收到的TCP報文段在那些導致進入恢復模式的報文段之后被發(fā)送的。這種情況可通過比較InOrderTCPSegmentSN與LastRecoverySN來確定。該確定事實上可在為該連接處理接收到的TCP報文段的任何階段做出。例如，在圖3中的步驟S9之后或是圖4A中的步驟S102之前。當按順序的報文段SN大于LastRecoverySN，即，接收到新的TCP報文段時，在步驟S105確定為YES，在步驟S106，RecoveryAttemptsNum(圖2B中的域292)被復位，即被重置為零。關(guān)于上述的例子，步驟S105防止了在一段較長的時間后，例如，五個小時，將FAST連接不必要地降級為SLOW連接(即，因為RecoveryAttemptsNum超過MaxRecoveryAttemptsNum)，其中丟棄的報文段由于數(shù)據(jù)損壞被丟棄，然后在發(fā)送方重新發(fā)送該報文段后，其被成功接收并作為對齊的報文段來處理。如果在步驟S105或是在步驟S106后是NO，則報文段處理按正常繼續(xù)，例如圖3的步驟S1。
利用上述的處理，允許重發(fā)的次數(shù)可由用戶通過設(shè)置MaxRecoveryAttemptsNum域296來定義。應該可以認識到，盡管上述對涉及到圖4A-4B的有限次重發(fā)嘗試模式和涉及圖3的步驟S10的錯誤檢測進行了描述，但是該有限次重發(fā)嘗試模式不僅僅是適用于步驟S10的錯誤檢測，如下將對其進一步描述。注意，該有限次重發(fā)嘗試模式還可有利的應用于D部分，即加速TCP重發(fā)處理，下面將對其描述，當報文段由于考慮到ULP而被丟棄時，其發(fā)送即時的復制Ack。
B.連接的降級參照圖5，將對在一個或是多個接收到的DDP報文段112以快速通道模式被放置到目標緩沖器50之后連接被降級(圖3中的步驟S3)的特殊情況的處理進行描述。如圖5所示，四個TCP報文段標記包(Pkt)被失序的接收，即，按3、4、1和2的順序。當連接被降級為SLOW連接時，所有從降級時刻接收到的數(shù)據(jù)將被放置到重組緩沖器34并被按順序重組，即，Pkt 1、2、3和4。在這種情況中，根據(jù)TCP協(xié)議，InLogic32保留接收到那些報文段的記錄。
盡管很少，但報文段，例如，Pkt#3(涂有陰影)被直接放置到目標緩沖器50的情況也可能出現(xiàn)。這種情況將導致重組緩沖器34中那些保存數(shù)據(jù)包3(Pkt#3)的位置填滿“垃圾”數(shù)據(jù)，即，間隙或是洞，即使InLogic32認為所有的數(shù)據(jù)都被接收了。如果允許不正確的處理繼續(xù)下去，當OutLogic40向目標數(shù)據(jù)緩沖器50傳輸重組緩沖器34時，早先以快速通路模式傳輸?shù)臄?shù)據(jù)包3(Pkt#3)將會被改寫成“垃圾”數(shù)據(jù)，這將損壞數(shù)據(jù)。
為了解決該問題，但又不增加硬件的復雜度，在可選的實施方式中，當連接為FAST連接時，InLogic32控制TCP邏輯忽略接收到的失序的報文段(即，圖5的Pkt#3)。具體地，當在步驟S3將該連接降級為SLOW連接時，InLogic32被配置成為失序的放置的數(shù)據(jù)清除TCP洞(圖3)，并停止向發(fā)送方發(fā)送這些包被接收到的報告(SACK選項)。結(jié)果是，發(fā)送方重發(fā)所有沒有被確認的數(shù)據(jù)，包括那些直接放置到目標數(shù)據(jù)緩沖器50的失序的報文段，即，Pkt#3。當重發(fā)的數(shù)據(jù)被接收到時，它將被寫入到重組緩沖器34，而當OutLogic40從重組緩沖器34傳輸數(shù)據(jù)時，任何失序的直接放置的報文段在目標數(shù)據(jù)緩沖器50被改寫。這個功能實際上意味著RNIC16在該連接中“丟棄”失序放置到目標緩沖器50的報文段。該方法排除了重組緩沖器34中的“有空隙的”有序的流的情況，并且由于很少有情況能導致此類行為，所以不會引起明顯性能上的惡化。
C.連接升級作為另一個可選實施方式，本發(fā)明可包括如圖6中所示的連接升級過程。上述描述的快速通道模式方法的目的是為攜帶對齊的DDP報文段112的連接而允許旁路重組緩沖器34。然而，即使在FAST連接中，數(shù)據(jù)宿12或是中間網(wǎng)絡(luò)設(shè)備可產(chǎn)生間歇的非對齊DDP報文段112NA，根據(jù)上述描述的技術(shù)這將導致FAST連接降級為SLOW連接。該間歇性的行為可由例如TCP重發(fā)期間最大報文段大小(MSS)的變化或是其它偶發(fā)性的情況導致。
如圖6所示，為了從這種情況中恢復過來，本發(fā)明還提供從例如在步驟S3(圖3)早期降級之后從SLOW連接到FAST連接的連接升級。為了能適應該升級，必然存在許多種情況。在可選實施方式的第一步驟S31中，InLogic32確定重組緩沖器34是否為空。如果是NO，則在步驟S32沒有升級發(fā)生。如果在步驟S31確定是YES，那么在步驟S33，InLogic32確定對齊的DDP報文段112是否被接收到。如果是NO，則在步驟S32沒有升級發(fā)生。如果在步驟S33確定為YES，則在步驟S34，InLogic32確定該連接是否由例如數(shù)據(jù)宿12的發(fā)送方作為FAST連接啟動。如果在步驟S24確定為NO，則在步驟S32沒有升級發(fā)生。如果在步驟S34確定為YES，則該連接在步驟S35被升級為FAST連接。
D.加速TCP重發(fā)處理另一個可選實施方式針對這樣的情況，其中TCP報文段106被接收，但是因為RDMA或是ULP的因素而被丟棄，這些因素包括例如損壞、無效的DDP報文段的CRC等。根據(jù)上述描述的過程，有多次TCP報文段196被接收到并且通過TCP校驗和，但是沒有發(fā)送涵蓋該報文段的TCP Ack而被InLogic32丟棄(即，圖3的步驟S9)。常規(guī)的過程將導致這些包的重發(fā)嘗試。具體地，在基礎(chǔ)策略中(所謂的“Reno協(xié)議”)，當TCP發(fā)送方接收到三個重復的Ack(即，沒有提前于按順序接收到的數(shù)據(jù)的序列號的Ack)時，它就開始了“快速重發(fā)”模式。例如，假設(shè)兩個TCP報文段A和B，在TCP順序上是報文段B跟著報文段A。如果報文段A被丟棄，那么接收方只有在它接收到報文段B才會發(fā)送重復的Ack。該重復的Ack表示“我正在等待報文段A，但接收到了另一個報文段”，即，報文段B。在Reno協(xié)議下的“快速重發(fā)模式”中，發(fā)送方發(fā)送一個報文段，接著它等待另外三個重復的Ack來重發(fā)另一個包。更高級的策略(像所謂的“New-Reno協(xié)議”)允許在它的“快速恢復”模式中為每一個接收到的重復重發(fā)報文段。該過程背后的邏輯是這樣的，即如果一個報文段離開了網(wǎng)絡(luò)，那么發(fā)送方可將另一個包放入到網(wǎng)絡(luò)中。
為了便于重發(fā)，根據(jù)本發(fā)明的可選實施方式，InLogic32產(chǎn)生第一個涵蓋接收到的TCP報文段的重復的TCP確認(Ack)，該確認由TCP確定為有效并基于上層協(xié)議(ULP)判決而被丟棄(例如，圖3的步驟S9)；并且發(fā)送重復的TCP Ack。如上所指出的，ULP可包括一個或是多個MPA協(xié)議、DDP協(xié)議以及RDMA協(xié)議。為TCP報文段而產(chǎn)生第一個重復TCP Ack而不管該TCP報文段是有序或是失序，即使在沒有接收到下一個有序的TCP報文段處。InLogic32還產(chǎn)生涵蓋下一個失序的接收到的TCP報文段的第二個重復的TCP確認(Ack)并發(fā)送該第二個重復的TCP Ack。
上述處理實際上意味著即使下一個有序的報文段(例如，上述例子中的報文段B)還沒有接收到就產(chǎn)生重復的Ack(例如，用于上述例子中的報文段A)，因此在上述的重發(fā)規(guī)則下應該加速發(fā)送方重新進入到快速通道模式的過程。更具體地，即使報文段B沒有被接收到，發(fā)送方也將知道報文段A這一有效的TCP報文段被接收了并且由于ULP因素而被丟棄。結(jié)果是，額外的重復Ack迫使發(fā)送方更早的開始重發(fā)過程，而在此處許多重復的Ack必須在重發(fā)開始前被接收。該方法沒有違反TCP原理，因為TCP報文段106已經(jīng)被成功傳送到ULP，并且由于ULP因素而被丟棄(無效的CRC)。因此，該包不會被IP協(xié)議丟棄或是重排序。當RNIC16實施有限重發(fā)嘗試模式時，如關(guān)于圖4A所做的論述，即，Ack在步驟S103被發(fā)送，該方法是相當有價值的。
E.CRC計算和驗證進入的以太網(wǎng)幀的常規(guī)處理開始于過濾過程。該過濾的目的是把有效的以太網(wǎng)幀和從無效的以太網(wǎng)幀分開。“無效幀”不是損壞的幀，而是不應由RNIC16接收的幀，例如，基于MAC地址的MAC過濾幀選擇、基于VLAD標簽的虛擬局域網(wǎng)(VLAN)過濾幀選擇等。允許進入RNIC16的那些有效幀也被分成了不同的類型。這些類型中的一種是TCP報文段。過濾過程是很快就完成的，不需要執(zhí)行整個以太網(wǎng)幀的存儲轉(zhuǎn)發(fā)處理。
TCP報文段處理的下一個步驟是TCP校驗和計算和驗證。校驗和計算通過計算發(fā)送的值來檢測發(fā)送的數(shù)據(jù)是否沒有錯誤，這通常是利用數(shù)據(jù)塊中的二進制數(shù)值，利用一些算法和使用用于與接收時以同樣方式計算出的值進行比較的數(shù)據(jù)存儲其結(jié)果。校驗和計算和驗證需要整個TCP報文段的存儲轉(zhuǎn)發(fā)處理，因為它涵蓋了整個TCP報文段的凈荷。常規(guī)地，循環(huán)冗余校驗(CRC)的計算和驗證通常是跟著TCP校驗和驗證的，即，在連接被認為是RDMA連接后并且利用先前DDP報文段的長度或是MPA標志對DDP報文段的邊界進行檢測了之后。CRC計算和驗證通過將消息分割成預定的長度，該長度作為被除數(shù)由固定的除數(shù)來除，從而來檢測數(shù)據(jù)是否被正確的發(fā)送了。該計算的余數(shù)被附加到消息上，用于與接收方所執(zhí)行的相同的計算進行比較。CRC計算和驗證還需要對整個DDP報文段的存儲和轉(zhuǎn)發(fā)，這就增加了延遲并需要大的數(shù)據(jù)緩沖器來存儲。CRC計算的一個需求是要知道DDP報文段的邊界，這將通過利用先前的DDP報文段的長度或是利用MPA標志110(圖1B)來確定。基于標志的確定是很復雜的，因為會有許多意想不到和不常見的情況。對部分接收到的DDP報文段的CRC計算也是復雜的過程。
為了解決上述問題，如圖2C所示，本發(fā)明利用相同的存儲轉(zhuǎn)發(fā)緩沖器68，并行于經(jīng)TCP校驗和邏輯66執(zhí)行TCP校驗和計算和驗證，經(jīng)CRC邏輯64執(zhí)行CRC計算和驗證。此外，本發(fā)明沒有立即確定DDP報文段的邊界，并且隨后計算和驗證DDP報文段CRC。相反，本發(fā)明通過先計算CRC后確定DDP邊界來轉(zhuǎn)換操作的順序。為了做出這種轉(zhuǎn)換，CRC邏輯64假設(shè)每個TCP報文段(在確知該報文段是屬于RDMA連接前)都開始于對齊的DDP報文段。此外，本發(fā)明假設(shè)TCP凈荷127的起始兩個字節(jié)(圖1B)走MPA幀的MPA長度域114(圖1B)。接著該長度被用于識別DDP報文段邊界和為該報文段計算CRC。在驗證單元44識別了TCP報文段106中的第一個可能的DDP報文段112的邊界后，它在對該DDP報文段進行計算和驗證CRC的同時進行對TCP報文段凈荷127的該部分的校驗和計算，接著再繼續(xù)下一個包含于相同TCP報文段106內(nèi)的下一個潛在的DDP報文段112(如果有的話)。對于每個在TCP報文段106中發(fā)現(xiàn)的“潛在”DDP報文段，CRC驗證結(jié)果可能是有效的、無效的或是太長。CRC驗證的結(jié)果被存儲以便如上面與圖3相關(guān)的描述使用。
為了實際上如上所述那樣計算CRC，當TCP報文段106的凈荷被處理時，InLogic32需要知道MPA標志110在TCP報文段106中的位置。如上與圖1B相關(guān)的論述，MPA標志110在TCP報文段106中是每隔512個字節(jié)放置的，并且第一個MPA標志距離TCP報頭126(圖1B)中的初始序列號512個字節(jié)，該序列號是作為上下文42的StartNum域248(圖2B)存儲的。不幸的是，對每個MPA標志110的評估都沒有顯示出它相對于StartNum248的位置。此外，MPA標志110是由CRC數(shù)據(jù)116涵蓋的，但是卻沒有包含在MPA長度域114中，其僅包括MPA幀的凈荷。因此，為了識別MPA標志110，RNIC16需要知道必須從連接上下文42中提取的StartNum248(圖2B)。不幸的是，在TCP處理期間執(zhí)行讀連接上下文42是非常不方便的，因為在處理中它發(fā)生的非常早并且破壞或是阻止包處理。
為了減少或是消除連接上下文42提取，本發(fā)明提供四個可選方式，允許對DDP報文段112長度的正確計算，這對于該報文段的MPA CRC的計算和驗證是所需的。這些選擇將在下面的部分進行描述。
1.連接上下文預提取方法第一個用于正確計算DDP報文段112長度的可選實施方式包括實施作為StartNum域248(圖2B)存儲的初始序列號的連接上下文42的預提取。這里不建議對MPA規(guī)范做出改動。當前的MPA規(guī)范需要知道初始序列號(StartNum)以便識別TCP報文段106中MPA標志110的位置。初始序列號是TCP連接的屬性，其對于不同的連接是不同的，并且在連接建立時間被協(xié)商。因此，StartNum248(圖2B)在每個連接基礎(chǔ)上保留。為了識別MPA標志110的位置，CRC邏輯64(圖2C)檢查具體報文段的序列號(SeqNum)和StartNum(SeqNum-StartNum)模512的余數(shù)是否為零。即，因為每個TCP報文段106報頭攜帶它的凈荷的第一個字節(jié)的序列號，所以CRC邏輯64可通過利用具體報文段的序列號和StartNum248之間的差值來確定到什么位置尋找標志，接著從該位置起每512個字節(jié)放置一個標志。MPA規(guī)范定義了上述的標志檢測方法。通過這種方式，Hash查詢(基于TCP元組)和連接上下文42預取可在執(zhí)行TCP校驗和驗證前被執(zhí)行。這是正常的連接上下文42提取流程。如果RNIC16想得到連接上下文42，它首先要知道該上下文位于什么位置，或是得到連接ID。TCP報文段106報頭攜帶TCP元組(IP地址(源和目標)和TCP端口(源和目標))。元組是Hash函數(shù)的輸入。Hash函數(shù)的輸出是連接ID。當然，對于不同的元組可能會產(chǎn)生相同的連接ID，這被稱為“碰撞”。為了解決碰撞，RNIC16讀取連接上下文42，利用包中的元組來檢查連接上下文42中的元組，如果不匹配，則RNIC16獲得下一個連接上下文42的指針。RNIC16持續(xù)檢查元組直到它找到該匹配或該報文段被認為是不屬于任何已知連接的報文段。該處理允許定位TCP流中的MPA標志110。結(jié)果是，CRC計算和驗證可與TCP校驗和驗證一起執(zhí)行。
2.初始序列號協(xié)商方法在第二個可選實施方式中，通過對MPA規(guī)范做出多個改動而不需要連接上下文的提取就可正確計算DDP報文段長度。首先，對MPA規(guī)范中MPA標志110放置的定義進行改動。上述連接上下文預取方法的一個缺點是需要執(zhí)行Hash查詢和連接上下文42的預取，從而來識別TCP報文段106中MPA幀109的邊界。為了防止這一點，本發(fā)明每512個字節(jié)放置MPA標志110而不是以初始序列號(SN)(作為StartNum248存儲)為起始每512個字節(jié)來放置(其需要上述的SN-StartNum模512的處理)。在這種方式中，MPA標志110的位置可通過序列號模512來確定以定位MPA標志110，而無需連接上下文42的提取。
根據(jù)本實施方式對MPA規(guī)范的第二個改動所起的作用是避免出現(xiàn)一個標志在兩個DDP報文段112之間被分開的情況，即，初始序列號沒有字對齊。結(jié)果是，序列號模512的處理不會在所有的情況中都適用，因為標準TCP實施允許初始SN具有隨機產(chǎn)生的字節(jié)對齊的值。即，RNIC16無法控制初始序列號是否是字對齊的。結(jié)果是，對于給定連接的TCP流可以不需要以MPA標志110開始。因此，如果CRC邏輯64只是通過利用序列號模512處理來拾取標志110的位置，它可得到放置到字節(jié)對齊位置的標志，這是無法接受的。為了避免這種情況，本發(fā)明向在MPA協(xié)商階段交換的MPA幀添加填充字節(jié)，即，所謂的“MPA請求/回復幀”，從而在它轉(zhuǎn)向RDMA模式時使得RDMA連接的初始SN字對齊。即，如圖7中所示，校正因子150被插入到包括使得初始SN字對齊所需字節(jié)的TCP報文段106的MPA請求/回復幀152中。應該可以認識到校正因子150的確切位置不是非要被示出。通過這種方式，CRC邏輯64可實施序列號模512的處理來獲得TCP流中MPA標志110的確切位置而無需提取連接上下文。通過利用MPA規(guī)范的上述改進方式，本發(fā)明可確定MPA標志110的位置并可正確計算出MPA報文段的長度而無需預提取連接上下文42。
3.MPA長度域修改方法在第三個用于無需連接上下文的提取而正確計算DDP報文段112長度的可選實施方式中，在MPA規(guī)范中對MPA長度域114的定義進行了改動。常規(guī)地，MPA長度域114被定義成攜帶相應的MPA幀109的ULP凈荷的長度，不包括標志110、填充字節(jié)121(圖1B)和由MPA層所添加的CRC數(shù)據(jù)116。不幸的是，該信息不允許利用由TCP報文段106提供的信息來對MPA幀邊界進行定位。為了解決該問題，根據(jù)本可選實施方式，MPA規(guī)范中對MPA長度的定義被修改成指定整個MPA幀109的長度，包括MPA長度域114的14個最高有效位(MSB)、ULP凈荷118長度、MPA標志110、CRC數(shù)據(jù)116、MPA長度域114的兩個最低有效位(LSB)以及填充字節(jié)121內(nèi)的有效比特。
該修改后的定義允許無需定位所有嵌入在該MPA幀內(nèi)的MPA標志而利用MPA長度域114來檢測MPA幀109的邊界。MPA層協(xié)議負責剝離標志110、CRC數(shù)據(jù)116和填充字節(jié)121并且提供具有ULP凈荷長度的ULP(DDP層)。
參照圖8，利用該MPA長度的定義，CRC邏輯64通過下面的處理來確定MPA幀109邊界的位置在步驟S100，CRC邏輯64確定MPA幀109的第一個字是否等于零。如果是YES，那么InLogic32(圖2A)在步驟S102從下一個字讀取MPA長度域114。這是當標志110落入到兩個MPA幀109之間的情況。在這種情況中，MPA長度域如步驟S104所表示的位于下一個字中。如果在步驟S100的確定是NO，則該字占據(jù)該MPA長度域114。在步驟S106中，MPA長度被用來尋找涵蓋該MPA幀109的CRC數(shù)據(jù)116的位置。接著重復上述的步驟來確定嵌入到TCP報文段106中其它MPA幀109的位置。該實施方式無需從連接上下文42得到任何額外信息就可允許確定MPA幀109的邊界位置。
4.無標志切入直通實施在第四個可選實施方式中，針對CRC計算和驗證采用了無標志的切入直通實施，如下將進行描述。如上所述的三個用于正確計算DDP報文段長度的可選實施方式的缺點在于每個實施方式都需要改動MPA的規(guī)范或是連接上下文42的預提取。本實施方式對進站的報文段實施切入直通處理，而無需預提取連接上下文42來計算到達MPA幀的CRC以及對MPA規(guī)范做出任意額外的改動。此外，該實施方式無需利用MPA標志就可允許失序的直接數(shù)據(jù)放置。本實施方式部分基于根據(jù)MPA規(guī)范的最近的升級版本對給定的連接接收方可協(xié)商“無標志”選項。具體地，升級的MPA規(guī)范允許MPA接收方來決定對于給定的連接是否使用標志，并且發(fā)送方必須要遵守接收方的決定。本實施方式改變驗證單元44邏輯來允許CRC與TCP校驗和同時立即執(zhí)行，并且無需預提取連接上下文42。
CRC計算正如所述的具有標志的情況那樣被完成。即，本發(fā)明假設(shè)TCP報文段以對齊的DDP報文段開始，并且利用MPA長度域來尋找CRC的位置，接著計算和驗證CRC。然而，本實施方式不同之處在于，對于給定MPA報頭的MPA長度域，當計算DDP報文段長度時，無需考慮標志。
參照圖9，示出了關(guān)于本發(fā)明第一個可選實施方式的InLogic32的功能。應該認識到許多InLogic32的功能與上面關(guān)于圖3的描述基本類似。為了清楚的目的，對于InLogic32的功能與上面關(guān)于圖3的描述相類似的地方，這些步驟將被重復并以虛線框繪出。
在升級的MPA規(guī)范下，在連接初始化時刻接收方對具體地連接協(xié)商“無標志”選項。如圖9所示，在本實施方式中，在步驟S201InLogic32確定進站TCP報文段106是否包括標志110。如果是YES，則InLogic32接著如圖3中那樣處理，并且其它一些CRC計算和驗證方法將如上所述那樣被用到。如果是NO，則在步驟S202進站的MPA幀109利用與TCP校驗和邏輯66相同的存儲和轉(zhuǎn)發(fā)緩沖器68來立即對它們的CRC進行計算和驗證，但不會提取連接上下文42。還可以完成對連接是否為SLOW連接的確定，即步驟S2，以及S3。CRC驗證的結(jié)果可以是下面的一種1)MPA幀109的長度與TCP報文段106的長度匹配，并且MPA幀109具有有效的MPA CRC；2)MPA幀109的長度與TCP報文段106的長度匹配，但MPA幀109具有無效的CRC；3)MPA幀109的長度超出TCP報文段的長度；以及4)MPA幀109的長度小于TCP報文段106的長度。
在情況1)中，InLogic32的功能基本上是類似于圖3中的步驟S4-S7。這也就說，在此處MPA幀109具有與TCP報文段106相同的長度(圖3的步驟S4和S5)，并攜帶有有效的MPA CRC(步驟S6)，該幀被認為是有效的MPA幀，經(jīng)過內(nèi)部緩沖器38傳送到OutLogic40用于進一步的處理，并以快速通道模式傳送至目標數(shù)據(jù)緩沖器50。
在情況2)中，此處MPA幀109具有與TCP報文段106相同的長度(圖3的步驟S4和步驟S5)，但具有無效的CRC(圖3的步驟S6)，InLogic32的功能不同于關(guān)于圖3所做的描述。具體地，由于接收到的MPA幀109不含有MPA標志110，與標志有關(guān)的信息將不能用于恢復(如圖3中的步驟S10)。這樣就僅有兩種情況需要解決Case A當MPA幀109涉及到先前接收到的報文段(并驗證的)MPA幀109的長度(如圖3的步驟S8所檢測的)；和Case B所有其它的情況。在Case A中，MPA幀109被損壞了，而在Case B中，MPA幀109可能被損壞或是沒有對齊。在這兩種情況中，接收到的TCP報文段106被丟棄(圖3的步驟S9)，并且接收沒有得到確認。在這種情況中，關(guān)于圖4所述的有限的重發(fā)嘗試模式可用來實施，以便恢復該丟棄的TCP報文段106，它允許發(fā)送方重發(fā)丟棄的TCP報文段106并解決任何潛在的數(shù)據(jù)損壞。如果MPA幀109沒有對齊TCP幀106，那么有限重發(fā)嘗試模式如上所述以將該連接降級為SLOW連接而結(jié)束。
在情況3)中，此處MPA幀109的長度超過了TCP報文段106的長度(圖3的步驟S5)，或者MPA幀109沒有對齊TCP報文段106，或者該長度被損壞了。在這種情況中，接收到的TCP報文段106被丟棄(圖3的步驟S9)，并且TCP不會確認接收。依然是在這種情況中，可實施關(guān)于圖4所述的有限重發(fā)嘗試模式來恢復丟棄的TCP報文段106，這就允許發(fā)送方重發(fā)丟棄的TCP報文段并解決任何潛在的數(shù)據(jù)損壞。再一次，如果MPA幀109沒有對齊TCP報文段106，則有限重發(fā)嘗試模式如上所述以將該連接降級為SLOW連接而結(jié)束。
在情況4)中，此處MPA幀109的長度小于TCP報文段106的長度(圖3的步驟S4)，或TCP報文段106潛在的攜帶多個MPA幀109(發(fā)送方使用打包選項)，InLogic32按順序檢查嵌入到接收到的TCP報文段106中的所有DDP報文段112的CRC(圖3的步驟S11-S13)。如果所有的DDP報文段112具有有效的CRC，則InLogic32就準許接收該TCP報文段106，并且所有的MPA幀在快速通道模式上被轉(zhuǎn)發(fā)以便進一步的處理(圖3的步驟S7)。如果一個DDP報文段112具有無效的CRC，或最后一個報文段沒有完全包含在TCP報文段中(圖3的步驟S12-S13)，則整個TCP報文段被丟棄(圖3的步驟S9)，并且InLogic32不對該TCP報文段的接收進行確認。如上所述，可實施關(guān)于圖4所述的有限重發(fā)嘗試模式來恢復丟棄的TCP報文段106，這就允許發(fā)送方重發(fā)丟棄的TCP報文段并解決任何潛在的數(shù)據(jù)損壞。如果MPA幀109沒有對齊TCP報文段106，則有限重發(fā)嘗試模式如上所述以將該連接降級為SLOW連接而結(jié)束。
轉(zhuǎn)向圖10，其示出了關(guān)于本實施方式的InLogic32的另一可選流程圖，同時也包括有限重發(fā)嘗試模式和TCP重發(fā)加速的情況。與圖9相比，InLogic32的功能與圖3相比較大大簡化了功能。為了清楚起見，對于InLogic32功能與上面關(guān)于圖3的描述相類似的地方，這些步驟被重復并以虛線框繪出。
在圖10中，步驟S151-S153基本是與圖3的步驟S1-S3相同。在步驟S154，InLogic32確定是否通過CRC驗證。該評價與圖3中的步驟S4的不同之處在于，CRC邏輯54不是每DDP報文段就提供指示，而是提供CRCValidationPassed比特來表示接收到的TCP報文段中所有的DDP報文段的CRC驗證是成功或是失敗。如果對于所有包含于接收到的TCP報文段中的DDP報文段，CRC驗證通過，則該比特被設(shè)置，如果對于其中一個報文段的CRC驗證失敗，或最后一個(僅有的)報文段太長，則該比特被清除。如果是NO，則InLogic32前進到步驟S155，此處將確定RecoveryAttemptsNum(圖2B的域292)是否大于MaxRecoveryAttemptsNum(圖2B的域296)。如果是YES，則InLogic前進到步驟S153，將DDP報文段放置到重組緩沖器34，Ack被發(fā)送，并且連接被降級為SLOW連接(如果它是FAST連接)。如果在步驟S155是NO，則在步驟S156，TCP報文段106被丟棄并且不安排確認。此外，RecoveryAttemptsNum(圖2B的域292)增加1，而LastRecoverySN(圖2B的域294)被更新。
返回到步驟S154，如果確定結(jié)果為YES，則InLogic32在步驟S157接著確定新接收到的有序的數(shù)據(jù)傳輸?shù)男蛄刑?In-order SN)是否大于LastRecoverySN(圖1B的域294)。如果是YES，則在步驟S158，InLogic32清除RecoveryAttemptsNum(圖1B的域292)，即，將其設(shè)置為零。如果在步驟S157為NO，或是隨后到步驟S158，在步驟S159，該報文段在“快速通道模式”上通過被放置到目標數(shù)據(jù)緩沖器50而被處理。如上面關(guān)于TCP重發(fā)加速選項所述，步驟S159還包括重復Ack的實施。
上述圖10的實施方式實施了本發(fā)明的切入直通模式加上沒有使用MPA標志的有限重發(fā)嘗試模式和TCP重發(fā)加速選項。
III.OutLogicOutLogic40(圖2A)執(zhí)行有序的RDMA消息的傳送，而沒有每個RDMA消息都保留信息。這解決了兩種情況1)除了發(fā)送消息以外的所有RDMA消息，和2)RDMA發(fā)送消息。
返回到圖1F-1H，現(xiàn)在對OutLogic40(圖2A)的操作進行描述。如上所述，OutLogic處理以快速通道模式放置到內(nèi)部數(shù)據(jù)緩沖器38(圖2A)上的對齊的DDP報文段220，并且執(zhí)行數(shù)據(jù)的放置和向接收方的數(shù)據(jù)緩沖器傳送對齊的DDP報文段。正如在這里所使用的，“放置”表示真正將數(shù)據(jù)放入到緩沖器中的處理，而“傳送”表示確認數(shù)據(jù)傳輸完成的處理?！胺胖谩笨蛇m用于報文段和消息，而“傳送”僅適用于消息。在RDMA協(xié)議下，對齊的DDP報文段可以失序的方式來放置，而傳送在所有對齊的DDP報文段都有序放置前是不會發(fā)生的。例如，對于三個對齊的DDP報文段1、2和3，此處在沒有報文段1的情況下報文段2和報文段3首先被放置，傳送在報文段1被放置前是不會發(fā)生的。
A.放置關(guān)于放置，OutLogic40除了關(guān)于RDMA讀消息以外提供RDMA消息的常規(guī)放置，如下將進行描述。
例如關(guān)于標記的DDP報文段，返回到圖1D，根據(jù)RDMA協(xié)議，標記的DDP報文段的報頭124攜帶接收方先前登記的存儲區(qū)的地址(例如，圖1G中的存儲區(qū)232)。如上所表示的，該地址包括表示位于存儲區(qū)/窗口(例如，圖1G中用于RDMA寫消息的存儲區(qū)232)內(nèi)的目標緩沖器的起始標記(STag)、該區(qū)域/窗口內(nèi)的目標偏移(TO)以及事務(wù)長度(報文段凈荷)。在這種情況中，數(shù)據(jù)放置由OutLogic40以常規(guī)方式執(zhí)行，而無需從連接上下文42(圖2A)檢索任何額外的信息。在由OutLogic40進行數(shù)據(jù)放置之前，進行常規(guī)的地址譯和保護(ATP)處理，其中Stag和TO被譯成描述目標緩沖器的存儲區(qū)的物理緩沖器列表。
關(guān)于例如是RDMA讀消息的未標記DDP報文段，參照圖1H，RDMA協(xié)議定義未決的進站的讀請求222的最大數(shù)目，其是在協(xié)商的時刻進行交換的。每個RDMA讀消息204消耗單個的DDP報文段222。當RNIC16接收到RDMA讀消息204時，它向讀隊列214發(fā)送RDMA讀響應WQE216RR。在另一個例子中，參照圖1F，每個發(fā)送消息200被放置到例如是數(shù)據(jù)宿18(圖2A)的響應方的接收隊列(RQ)212。如上所指出的，每個接收隊列(RQ)212是放置控制指令的緩沖器，并且包括放置了凈荷的WQE216R。接收隊列(RQ)212包括WQE216R。每個WQE216R保留描述由消耗裝置發(fā)送的接收WR208R的控制信息。每個WQE216R也指向被發(fā)送到WR208R內(nèi)的消耗裝置緩沖器。這些緩沖器是用來放置凈荷的。因此，每個消息200消耗WQE216R。
參照圖11，示出表示類似圖1H的RDMA讀消息204和RDMA讀響應206。然而根據(jù)本發(fā)明，讀隊列414作為特殊工作隊列(WQ)提供，該特殊工作隊列作為循環(huán)緩沖器實施，該循環(huán)緩沖器的每個輸入是描述需要由發(fā)送邏輯產(chǎn)生的RDMA讀響應的WQE216RR。這就可以容易和有效的對失序的RDMA讀請求222進行放置，因為對于每個進站的RDMA讀請求，在讀隊列414中都有已知的位置，即WQE216RR。例如，當RDMA讀消息#3被接收而RDMA讀消息#2被丟失時，RDMA讀消息#3被放置。該放置是在接收到RDMA讀請求消息222時完成的，即，消息由于在請求方發(fā)送讀WR208R而被發(fā)送。讀隊列414中WQE216RR的位置由RDMA讀消息報頭124(圖1D)中的MSN來識別。
B.傳送RDMA協(xié)議允許失序的數(shù)據(jù)放置但需要有序的傳送。因此，常規(guī)的實施需要維持放置(部分或是全部)到存儲器的關(guān)于每個消息的信息，但是還不能被傳送。然而丟失單個的TCP報文段將導致接收到許多失序的RDMA消息，它們將被放置到目標緩沖器，直到丟失的報文段被重發(fā)該操作才會完成并且成功地被放置到存儲器。在常規(guī)情況下，有限的資源可應用于存儲失序的流，這樣在失序的流被接收后只有一定數(shù)量的后續(xù)消息可被存儲。
然而，根據(jù)本發(fā)明，不是為每個沒有傳送的RDMA消息保留一些信息并因此限制支持失序接收到的消息的數(shù)量，而是通過基于每個TCP洞存儲信息來支持不限制沒有傳送的RDMA消息的數(shù)量?！癟CP洞”是描述由于接收到失序的TCP報文段而在TCP流中生成的空缺的術(shù)語。
參照圖12，白色的方框表示形成TCP洞130A-130C的TCP報文段400，而陰影/灰色方框402表示連續(xù)接收到的TCP流。每個TCP洞130A-130C信息存儲在上下文42(圖2B)中。所支持的有限數(shù)量的TCP的洞130A-130C是從TCP協(xié)議實施繼承的特性。具體地，TCP協(xié)議通常將所支持的TCP洞的數(shù)量限制在例如一、二或是三個洞。典型地，有限數(shù)量的TCP洞130A-130C的支持實際上意味著當失序的TCP報文段到達打開新的TCP洞時，該報文段被TCP邏輯丟棄。圖12示出三個TCP洞實施情況。在這種情況中，如果新的報文段是在底部的TCP洞130C之后到達，即，在兩個底部丟失報文段400之后，則該報文段將“打開”第四個不支持的洞。結(jié)果是該報文段將會被丟棄。
為了解決該情況，本發(fā)明實施經(jīng)連接上下文42(圖2A和2B)追蹤TCP洞130(圖12)，而不是追蹤失序的消息/報文段。具體地，如圖2B所示，本發(fā)明存儲PendingReadResponseNum域300來計數(shù)完成的RDMA讀請求，CompletedSendsNum域302來計數(shù)完成的發(fā)送消息以及CompletedReadResponseNum域306來計數(shù)完成的RDMA讀響應。本領(lǐng)域技術(shù)人員應該可以認識到對于每個洞也可能需要其它的域，而為了簡短起見沒有對它們進行描述。該方法允許不對等待完成和有序傳送的失序接收到的RDMA消息的數(shù)量進行限制。該方法在沒有任何限制情況下不會對由接收212和發(fā)送210隊列共享完成隊列240(圖1F-1H)進行限制?，F(xiàn)在將詳細描述具體類型消息的處理。
首先，應該可以認識到RDMA寫消息202(圖1G)的傳送不會導致任何向響應方的報告，或是因為該操作的屬性而向其它硬件邏輯發(fā)出通告。因此，關(guān)于這種類型的RDMA消息不存在傳送考慮。
其次，返回到圖11，關(guān)于RDMA讀響應消息206，該操作代表未決的RDMA讀消息204的完成。在這種情況中，在包括每TCP洞130具有多個完成的RDMA讀響應消息206的連接上下文42中存儲CompletedReadResponseNum域306(圖2B)足以向請求方完成處理邏輯提供充分的信息來完成未決的RDMA讀工作請求208R。當TCP洞關(guān)閉時，與該洞有關(guān)的完成的RDMA讀響應的數(shù)目將被報告給請求方的完成處理邏輯來表示對未決的RDMA讀工作請求208R的完成。
關(guān)于RDMA讀請求，WQE216RR發(fā)送的操作包括兩個步驟將WQE216RR放置到讀隊列414，和通告，即，門鈴響，來通告RNIC16該WQE能被處理。對WQE216RR的放置可以是失序的執(zhí)行。然而，如上所指出的，WQE處理的起始(并且因此門鈴響)必須要適應RDMA的排序規(guī)則。即，RDMA協(xié)議需要對進站的RDMA讀消息204的處理進行延遲，直到所有先前發(fā)送的任意類型的RDMA消息都完成。因此，門鈴響，即通告，應該被延遲到所有有序的先前的RDMA讀消息204被完成。單獨的門鈴響，即通告，可表示幾個WQE216RR的發(fā)送。
為了解決上述問題，根據(jù)本發(fā)明的RNIC16在連接上下文42(PendingReadResponseNum域300(圖2B))中存儲等待每個TCP洞130(圖1B)的門鈴響(通告)的發(fā)送的RDMA讀響應WQE216RR的數(shù)目。當TCP洞130被關(guān)閉時，RNIC16響門鈴(通告)來確認PendingReadResponseNum WQE216RR被發(fā)送到讀隊列214。這表示所有先前的讀消息204都被完成，并且RNIC16可以開始處理發(fā)送的讀響應WQE216RR。
參照圖13，RDMA發(fā)送消息500表現(xiàn)出一種獨特的情況。具體地，發(fā)送完成的發(fā)送消息包括將CQE542放置到CQ540。CQE542攜帶描述完成的消息的信息(例如，長度、無效的STag等等)。該信息是消息指定信息，并且因此應該為每個未決的發(fā)送消息500保留。RNIC16不能在發(fā)送消息500完成前放置CQE542(類似于在接收到的讀工作請求508R中放置RDMA讀響應WQE508RR)，因為如上所示CQ540可被幾個發(fā)送510和接收512隊列來共享。
為了解決該問題同時不消耗額外的RNIC資源，并且可提供可升級的實施，根據(jù)本發(fā)明的OutLogic40向由發(fā)送消息500所消耗的WQE516R放置需要被包含在CQE542中的所有信息。當接收到Poll-For-Completion請求時，該信息就重新由動詞接口20從WQE516R中提取出。RNIC16需要保留在連接上下文42中每個洞130的完成發(fā)送信息500的數(shù)目(在CompletedSendsNum域302中)，其在當相應的TCP洞關(guān)閉時被用于向CQ540發(fā)送CQE542。當TCP洞130關(guān)閉時，RNIC16將CQE542放置到CQ540。要放置的CQE542的數(shù)目等于為該洞所計數(shù)的完成的發(fā)送消息500的數(shù)目。當N是完成發(fā)送消息500的數(shù)目時，該方法涉及2N次的寫操作。
上述提到的關(guān)于RDMA發(fā)送信息500的傳送的方法的一個缺點是它將由RNIC16執(zhí)行的寫操作擴大了一倍。即，對于每個完成的發(fā)送消息500，都有一次寫入到WQE516R和一次CQE542的寫。為了解決該問題，如圖14所示，根據(jù)本發(fā)明的一個可選實施方式，CQE542的內(nèi)容變成攜帶由具體CQE542完成的WQE516R的引用計數(shù)器544。引用計數(shù)器544被RNIC16初始化成為給定TCP洞130完成的發(fā)送消息500的數(shù)目。對于每一個Poll-For-Completion操作，動詞接口20減小引用計數(shù)器544并且僅在該計數(shù)器變?yōu)榱銜r從CQ540移去CQE542。此外，RNIC16僅在WQE516S保留了大于門限(M)的等待完成的發(fā)送消息500時才對WQE516S更新。M為可配置的參數(shù)，表示分配用于保存未決的進站發(fā)送消息500的信息的內(nèi)部資源量。如果M等于零，則任意失序的接收到的發(fā)送消息500涉及WQE516R的更新(對于有序的接收到的發(fā)送消息500是無需更新的)。
該實施方式還包括定義兩類CQE542，以及提供具有CQE542的指示器546，用來表示CQE是否在該CQE的主體中攜帶有所有完成數(shù)據(jù)，或是攜帶有部分完成的數(shù)據(jù)，該部分完成數(shù)據(jù)具有存儲在與一個或是多個RDMA發(fā)送消息相關(guān)的WQE516R中的剩余完成信息。該可選實施方式將寫操作的數(shù)目減小至N+1，其中N是所完成的發(fā)送消息500的數(shù)目，它們在TCP洞130被關(guān)閉前是未決的。
IV.總結(jié)在先前的討論中，可以理解本方法步驟可通過專用計算機來優(yōu)選實施，該專用計算機即有限狀態(tài)機，包含用于執(zhí)行一個或是多個本發(fā)明的功能任務(wù)的專用硬件。然而，本方法步驟也可由處理器來執(zhí)行，例如CPU，執(zhí)行存儲于存儲器中的程序產(chǎn)品的指令。可以理解此處描述的各種設(shè)備、模塊、機制和系統(tǒng)可在硬件、軟件、或是硬件和軟件的結(jié)合中來實現(xiàn)，也可被不同于所示的那樣進行劃分。它們可以被任何類型的計算機系統(tǒng)或是其它適于執(zhí)行這里所述方法的設(shè)備來執(zhí)行。典型結(jié)合硬件和軟件的是具有計算機程序的通用計算機系統(tǒng)，當被加載和運行時，計算機程序控制計算機使其執(zhí)行這里所述的方法。本發(fā)明還可嵌入到計算機程序產(chǎn)品中，其包括所有能夠?qū)嵤┻@里所述方法和功能的特征，并且其在加載在計算機系統(tǒng)內(nèi)時，能夠執(zhí)行這些方法和功能。在本上下文中的計算機程序、軟件程序、程序、程序產(chǎn)品或是軟件意味著任意的一組指令以不同的語言、代碼或是符號的表達，該組指令旨在使得具有信息處理能力的系統(tǒng)來直接或是在下面步驟后執(zhí)行具體地功能(a)轉(zhuǎn)換為另一種語言、代碼或是符號；和/或(b)以不同的物質(zhì)形式復制。
盡管本發(fā)明結(jié)合概括的具體實施方式
進行了描述，但對于本領(lǐng)域技術(shù)人員來說許多的可選方式、改進方式和變形都是顯而易見的。因此，本發(fā)明上述提出的實施方式旨在起示例性而不是限制性的作用?？梢赃M行各種改變而不脫離本發(fā)明在后面權(quán)利要求中所定義的精神和范圍。具體地，所述的步驟的順序可在由不同組的步驟提供的某些環(huán)境或是功能中改變并且沒有脫離本發(fā)明的范圍。
工業(yè)實用性本發(fā)明具有在數(shù)據(jù)傳輸領(lǐng)域內(nèi)的工業(yè)實用性。
權(quán)利要求
1.一種提高傳輸控制協(xié)議(TCP)重發(fā)處理速度的方法，該方法包括步驟生成涵蓋接收到的TCP報文段的第一重復TCP確認(Ack)，所述接收到的TCP報文段由TCP確定為有效并被TCP基于上層協(xié)議(ULP)判決來丟棄(S9)；以及發(fā)送所述第一重復TCP Ack。
2.權(quán)利要求1所述的方法，其中所述ULP包括至少以下之一協(xié)議數(shù)據(jù)單元對齊標志(MPA)協(xié)議、直接數(shù)據(jù)放置(DDP)協(xié)議和遠端直接存儲器存取(RDMA)協(xié)議。
3.權(quán)利要求1所述的方法，其中為TCP報文段生成所述第一重復TCP Ack，而無論所述TCP報文段是否失序或有序。
4.權(quán)利要求1所述的方法，其中所述第一重復TCP Ack甚至在下一個有序TCP報文段還沒有被接收到時也被生成。
5.權(quán)利要求1所述的方法，進一步包括生成涵蓋下一個失序接收到的TCP報文段的第二重復TCP確認(Ack)并且發(fā)送所述第二個重復TCP Ack。
6.一種用于提高傳輸控制協(xié)議(TCP)重發(fā)處理速度的系統(tǒng)，該系統(tǒng)包括TCP確認(Ack)發(fā)生器，其生成涵蓋接收到的TCP報文段的第一重復TCP Ack，所述接收到的TCP報文段由TCP確認為有效并且被TCP基于上層協(xié)議(ULP)判決而丟棄；
7.權(quán)利要求6所述的系統(tǒng)，進一步包括用于發(fā)送所述第一重復TCP Ack的裝置。
8.權(quán)利要求6所述的系統(tǒng)，其中所述ULP包括至少以下之一協(xié)議數(shù)據(jù)單元對齊標志(MPA)協(xié)議、直接數(shù)據(jù)放置(DDP)協(xié)議和遠端直接存儲器存取(RDMA)協(xié)議。
9.權(quán)利要求6所述的系統(tǒng)，其中所述發(fā)生器為TCP報文段生成所述第一重復TCP Ack，而無論所述TCP報文段是否失序或有序。
10.權(quán)利要求6所述的系統(tǒng)，其中所述發(fā)生器甚至在下一個有序TCP報文段沒有被接收到時也生成所述第一重復TCP Ack。
11.權(quán)利要求6所述的系統(tǒng)，進一步包括生成涵蓋下一個失序接收到的TCP報文段的第二重復TCP確認(Ack)的TCP Ack發(fā)生器和用于發(fā)送所述第二個重復TCP Ack的裝置。
全文摘要
一種RNIC實施，其執(zhí)行向存儲器的直接數(shù)據(jù)放置，其中具體連接的所有報文段都是對齊的，或是經(jīng)重組緩沖器來轉(zhuǎn)移數(shù)據(jù)，其中具體連接的所有報文都是非對齊的。沒有接入重組緩沖器的切入直通的連接類型被稱作為“快”連接，因為它最有可能是被對齊的，而另一種類型就被稱作為“慢”連接。當消耗裝置建立起連接時，它指定連接類型(S2)。這連接類型可從快變成為慢和在變回來。本發(fā)明減小了存儲器帶寬、延遲、利用TCP重發(fā)的錯誤恢復以及提供來自空接收隊列的“降級恢復”。本實施還可在發(fā)送確認報文段接收的TCP確認(Ack)前以快連接來執(zhí)行大部分進站DDP報文段的CRC驗證(S11，S6)。
文檔編號G06F15/16GK1997982SQ200480035603
公開日2007年7月11日 申請日期2004年12月6日 優(yōu)先權(quán)日2003年12月11日
發(fā)明者瓦迪姆·馬克赫瓦克斯, 佐里克·馬丘爾斯凱, 喬拉·伯安, 利厄·沙列夫 申請人:國際商業(yè)機器公司