提高tcp重發處理速度的制作方法

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

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


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