專利名稱：Rdma完成和重傳系統(tǒng)以及方法
技術(shù)領(lǐng)域：
本發(fā)明一般涉及遠(yuǎn)程數(shù)據(jù)存儲(chǔ)器存取(RDMA)完成和重傳系統(tǒng)，更具體地說(shuō)，涉及保持響應(yīng)輸出(ResponseOut)和請(qǐng)求輸出信道(RequestOut channel)間的排序的RDMA完成和重傳的實(shí)現(xiàn)。
背景技術(shù)：
RDMA(遠(yuǎn)程數(shù)據(jù)存儲(chǔ)器存取)是使一臺(tái)計(jì)算機(jī)直接把信息放入另一臺(tái)計(jì)算機(jī)的存儲(chǔ)器中的網(wǎng)絡(luò)接口卡(RIC)特征。通過(guò)使對(duì)帶寬和處理開(kāi)銷(xiāo)的要求最小化，該技術(shù)降低了等待時(shí)間。由于必須在內(nèi)核和應(yīng)用之間復(fù)制數(shù)據(jù)，傳統(tǒng)的硬件和軟件體系結(jié)構(gòu)對(duì)服務(wù)器的CPU和存儲(chǔ)器施加相當(dāng)大的負(fù)載。當(dāng)連接速度超過(guò)服務(wù)器的處理能力和存儲(chǔ)器帶寬時(shí)，存儲(chǔ)器瓶頸變得更嚴(yán)重。
通過(guò)在RNIC(RDMA網(wǎng)絡(luò)接口卡)上的硬件中實(shí)現(xiàn)可靠的傳送協(xié)議，和通過(guò)利用內(nèi)核旁路支持零復(fù)制連網(wǎng)，RDMA避免了該問(wèn)題。零復(fù)制連網(wǎng)使RNIC可以往來(lái)于應(yīng)用存儲(chǔ)器直接傳送數(shù)據(jù)，不需要在應(yīng)用存儲(chǔ)器和內(nèi)核間復(fù)制數(shù)據(jù)。
內(nèi)核旁路使應(yīng)用向RNIC發(fā)出命令，而不必執(zhí)行內(nèi)核調(diào)用。RDMA請(qǐng)求從用戶空間被發(fā)送給本地RNIC，并通過(guò)網(wǎng)絡(luò)發(fā)送給遠(yuǎn)程RNIC，而不需要涉及任何內(nèi)核。這減少了在處理網(wǎng)絡(luò)業(yè)務(wù)量(traffic)時(shí)內(nèi)核空間和用戶空間之間的上下文切換的數(shù)目。
RDMA消費(fèi)者(應(yīng)用)使用消息語(yǔ)義學(xué)來(lái)通信。用消息發(fā)布供傳送的數(shù)據(jù)，用消息接收數(shù)據(jù)，并且預(yù)期以消息為單位報(bào)告完成。TCP本身是面向字節(jié)流的協(xié)議，它不知道ULP數(shù)據(jù)的可能消息邊界。于是，消息-字節(jié)流語(yǔ)義學(xué)的變換的任務(wù)落到RDMA以及它們的卸載的實(shí)現(xiàn)(offloaded implementation)上。
RDMA是使用TCP可靠性服務(wù)的面向消息的ULP。RDMA向從面向消息的ULP到面向字節(jié)的TCP語(yǔ)義學(xué)的映射增加了另一層復(fù)雜性。RDMA使用相同的TCP連接來(lái)傳送由兩個(gè)獨(dú)立的源發(fā)布的消息·請(qǐng)求輸出-由本地消費(fèi)者發(fā)起的RDMA請(qǐng)求；和·響應(yīng)輸出-作為由遠(yuǎn)程消費(fèi)者發(fā)送的入站RDMA讀取請(qǐng)求的接收和處理的結(jié)果，由RNIC發(fā)起的RDMA響應(yīng)。
當(dāng)通過(guò)相同的TCP連接傳送請(qǐng)求輸出和響應(yīng)輸出消息時(shí)，RNIC交織請(qǐng)求輸出和響應(yīng)輸出消息。除了字節(jié)流-消息流映射之外，在完成和重傳過(guò)程期間，RNIC需要保持來(lái)自請(qǐng)求輸出和響應(yīng)輸出的消息間的“傳送排序”。
不同的RDMA請(qǐng)求(例如“Fence”)和完成排序規(guī)則(例如當(dāng)RNIC收到RDMA讀取響應(yīng)時(shí)，完成RDMA讀取請(qǐng)求)可掛起請(qǐng)求輸出中的傳送或完成過(guò)程。但是，這種掛起不會(huì)阻止響應(yīng)輸出進(jìn)行RDMA讀取響應(yīng)的傳送和完成。因此，為了保持RDMA請(qǐng)求隊(duì)列和RDMA響應(yīng)隊(duì)列之間的無(wú)關(guān)性，需要一種有效地保持這兩個(gè)隊(duì)列間的順序的系統(tǒng)。
解決該問(wèn)題的一種方法是建立利用控制結(jié)構(gòu)(描述符)和/或通過(guò)保持?jǐn)?shù)據(jù)的獨(dú)立副本實(shí)現(xiàn)的單一請(qǐng)求/響應(yīng)信道。這種方法具有幾個(gè)缺點(diǎn)，包括·需要另外的復(fù)制操作；·為了實(shí)現(xiàn)這種方法(數(shù)據(jù)/控制被復(fù)制到適配器存儲(chǔ)器)，需要更多的RNIC資源；·缺乏靈活性(適配器存儲(chǔ)器是有限的資源，它限制了線路上可能待處理的(outstanding)RDMA消息的數(shù)目)；和·強(qiáng)制執(zhí)行RDMA請(qǐng)求和RDMA響應(yīng)間的完成排序更困難。
因此，需要一種解決上述問(wèn)題的解決方案。

發(fā)明內(nèi)容
通過(guò)提供一種用于RDMA流的完成和重傳的有效解決方案，而不需要額外復(fù)制數(shù)據(jù)或控制結(jié)構(gòu)來(lái)保持排序，本發(fā)明解決了上面提及的問(wèn)題以及其它問(wèn)題。在第一方面，本發(fā)明提供一種處理具有請(qǐng)求輸出信道和響應(yīng)輸出信道的遠(yuǎn)程數(shù)據(jù)存儲(chǔ)器存取(RDMA)環(huán)境中的完成請(qǐng)求的過(guò)程，包括每個(gè)信道的描述符列表，其中每個(gè)描述符列表包括信道中每個(gè)消息的消息描述符；每當(dāng)在請(qǐng)求輸出信道和響應(yīng)輸出信道間發(fā)生信道交換時(shí)，用消息中的最后字節(jié)的序號(hào)更新消息描述符中的消息長(zhǎng)度字段的更新機(jī)構(gòu)；檢查完成上下文中的值并比較下一要完成的消息的序號(hào)與最后確認(rèn)的序號(hào)，以確定該消息是否應(yīng)被完成的確認(rèn)(Ack)完成系統(tǒng)；和執(zhí)行讀取請(qǐng)求的完成的讀取請(qǐng)求完成系統(tǒng)。
在第二方面，本發(fā)明提供一種處理具有請(qǐng)求輸出信道和響應(yīng)輸出信道的遠(yuǎn)程數(shù)據(jù)存儲(chǔ)器存取(RDMA)環(huán)境中的完成過(guò)程的方法，包括利用下述步驟對(duì)每個(gè)信道執(zhí)行確認(rèn)完成如果下一要完成的消息的序號(hào)無(wú)效，那么斷定完成過(guò)程的處理結(jié)束；如果下一要完成的消息的序號(hào)大于最后確認(rèn)的序號(hào)，那么斷定完成過(guò)程的處理結(jié)束；如果下一要完成的消息的序號(hào)小于或等于最后確認(rèn)的序號(hào)，那么完成該信道中的信息。
在第三方面，本發(fā)明提供一種在具有請(qǐng)求輸出信道和響應(yīng)輸出信道的遠(yuǎn)程數(shù)據(jù)存儲(chǔ)器存取(RDMA)環(huán)境中，針對(duì)重傳請(qǐng)求定位待重傳的段的方法，包括識(shí)別請(qǐng)求輸出信道和響應(yīng)輸出信道的候選信息；從這兩個(gè)候選信息中選擇攜帶待傳送的段的消息；和確定指向(referto)待重傳的段的起點(diǎn)的指針描述符的位置。
在第四方面，本發(fā)明提供一種處理具有請(qǐng)求輸出信道和響應(yīng)輸出信道的遠(yuǎn)程數(shù)據(jù)存儲(chǔ)器存取(RDMA)環(huán)境中的傳送過(guò)程的系統(tǒng)，包括每個(gè)信道的描述符列表，其中每個(gè)描述符列表包括信道中每個(gè)消息的消息描述符；每當(dāng)在請(qǐng)求輸出信道和響應(yīng)輸出信道間發(fā)生信道交換時(shí)，用消息中的最后字節(jié)的序號(hào)更新消息描述符中的消息長(zhǎng)度字段的更新機(jī)構(gòu)。


結(jié)合附圖，根據(jù)本發(fā)明的各個(gè)方面的下述詳細(xì)說(shuō)明，將更易于理解本發(fā)明的這些和其它特征，其中圖1描述根據(jù)本發(fā)明的保持排序的完成和傳輸系統(tǒng)。
圖2描述根據(jù)本發(fā)明的消息描述符。
圖3描述根據(jù)本發(fā)明的完成算法的流程圖。
圖4描述根據(jù)本發(fā)明的更新請(qǐng)求輸出和響應(yīng)輸出信道中的序號(hào)的例子。
圖5描述表示Ack完成操作的流程圖。
圖6描述表示RDMA讀取請(qǐng)求完成操作的流程圖。
圖7描述根據(jù)本發(fā)明的保持請(qǐng)求輸出和響應(yīng)輸出信道中的完成排序的一對(duì)例子。
圖8描述根據(jù)本發(fā)明的三種重傳情況。
圖9描述根據(jù)本發(fā)明的保持請(qǐng)求輸出和響應(yīng)輸出信道中的重傳排序的一對(duì)例子。
具體實(shí)施例方式
下面描述的是實(shí)現(xiàn)RDMA完成和重傳的系統(tǒng)和方法。在RDMA協(xié)議內(nèi)，“完成”被定義成通知ULP(上層協(xié)議)，特定的RDMA操作已執(zhí)行針對(duì)RDMA操作規(guī)定的所有功能(包括放置和遞送)的過(guò)程。每個(gè)RDMA操作的完成語(yǔ)義被清楚定義。“重傳”被定義成通過(guò)信道重傳數(shù)據(jù)的過(guò)程。
如下所述，本發(fā)明利用雙信道實(shí)現(xiàn)(即一個(gè)信道用于響應(yīng)輸出，一個(gè)信道用于請(qǐng)求輸出)。為了完成這樣的實(shí)現(xiàn)，本發(fā)明提供一種每當(dāng)需要完成或重傳操作時(shí)，保持這兩個(gè)信道間的排序的方法。
對(duì)于本說(shuō)明來(lái)說(shuō)，假定讀者已理解RDMA協(xié)議及其在RNIC環(huán)境中的實(shí)現(xiàn)。RDMA協(xié)議可在網(wǎng)上從<www.rdmaconsortium.org/home>獲得。
背景-RDMA協(xié)議排序規(guī)則RDMA協(xié)議定義通過(guò)請(qǐng)求輸出信道傳送的消息的完成排序規(guī)則。這些規(guī)則略述如下所有RDMA請(qǐng)求必須按照消費(fèi)者發(fā)布(post)它們的順序來(lái)完成。RDMA具有三種請(qǐng)求(1)由單一RDMA消息(例如發(fā)送，寫(xiě)入)組成的RDMA操作。這些操作是用于把數(shù)據(jù)從本地主機(jī)傳送到遠(yuǎn)程主機(jī)，由從遠(yuǎn)程主機(jī)發(fā)送給本地主機(jī)的單一RDMA消息組成。當(dāng)RNIC能夠保證包含這些消息的所有TCP段會(huì)被可靠地傳送給TCP連接的另一端點(diǎn)時(shí)，發(fā)送和寫(xiě)入操作被認(rèn)為已完成。
(2)由幾個(gè)(一般為兩個(gè))RDMA消息組成的RDMA操作，例如讀取。這些操作是用來(lái)從遠(yuǎn)程存儲(chǔ)器讀取數(shù)據(jù)。這種操作由兩個(gè)RDMA消息組成讀取請(qǐng)求和讀取響應(yīng)。讀取請(qǐng)求是由請(qǐng)求始發(fā)者發(fā)送給數(shù)據(jù)源的消息。該消息攜帶從遠(yuǎn)程存儲(chǔ)器讀取數(shù)據(jù)和建立響應(yīng)消息所必需的全部信息。由遠(yuǎn)程主機(jī)產(chǎn)生的響應(yīng)消息是讀取響應(yīng)。該消息攜帶應(yīng)被寫(xiě)入請(qǐng)求者存儲(chǔ)器的數(shù)據(jù)，還包括數(shù)據(jù)應(yīng)被寫(xiě)入的位置的描述。當(dāng)RDMA讀取響應(yīng)消息已被讀取發(fā)起者成功接收時(shí)，認(rèn)為讀取操作已完成。RDMA讀取響應(yīng)不是獨(dú)立的RDMA操作(即，它是讀取操作的一部分)，于是當(dāng)傳輸層成功傳送RDMA讀取響應(yīng)時(shí)，該消息被認(rèn)為已完成。
(3)本地RDMA操作(例如綁定，快速登記)。這些操作不會(huì)導(dǎo)致任何數(shù)據(jù)(即，TCP段)的傳送。當(dāng)本地RDMA操作的處理由RNIC完成時(shí)，本地RDMA操作被看作完成。
概述參見(jiàn)圖1，圖中表示了保持響應(yīng)輸出和請(qǐng)求輸出信道間的排序的完成和重傳系統(tǒng)10。當(dāng)利用完成算法24或重傳算法26發(fā)出“完成請(qǐng)求”或者“重傳請(qǐng)求”時(shí)，排序被保持。為了便于執(zhí)行該過(guò)程，系統(tǒng)10(1)向請(qǐng)求輸出和響應(yīng)輸出信道16、18提供獨(dú)立的描述符列表12、14；和(2)利用出自這些描述符列表的信息，進(jìn)行傳送、完成和重傳操作。
在這種方法中，每個(gè)工作隊(duì)列項(xiàng)目(WQE)被處理(即，讀取)兩次，第一次是當(dāng)傳送該WQE時(shí)，第二次是當(dāng)完成該WQE時(shí)(注意重傳操作會(huì)要求額外讀取重傳的WQE)。
RNIC為每個(gè)RDMA連接保持維持該連接所需的信息。該信息被保存在連接上下文22中，在本實(shí)施例中，一組連接上下文字段被用于便于完成算法24和重傳算法26的實(shí)現(xiàn)。在一個(gè)例證實(shí)施例中，上下文字段由Context[Ch#]::FieldName指示。下述上下文字段與本發(fā)明相關(guān)1.Context[Ch#]::PendingCompletionRequest-用于表示RNIC具有待處理的未決(pending)Ack或者RDMA讀取完成請(qǐng)求的位。
2.Context[Ch#]::CompletedReadRequestsNum-用于表示完成的讀取請(qǐng)求的數(shù)目。
3.Context[Ch#]::ReqOutLastCompletedMsgSN-用于表示請(qǐng)求輸出信道中最后完成的消息的序號(hào)(SN)。
4.Context[Ch#]::ReqOutNextToCompleteMsgSN-用于表示請(qǐng)求輸出信道中下一待完成消息的序號(hào)(SN)。
5.Context[Ch#]::RespOutLastCompletedMsgSN-用于表示響應(yīng)輸出信道中最后完成的消息的序號(hào)(SN)。
6.Context[Ch#]::RespOutNextToCompleteMsgSN-用于表示響應(yīng)輸出信道中下一待完成消息的序號(hào)(SN)。
7、Context[Ch#]::LastAckedSN-最后接收的ACK的序號(hào)。
8、Context[Ch#]::PendingReadRequest-該位指示在執(zhí)行完成操作時(shí)，RNIC停止在RDMA讀取請(qǐng)求，并且必須等待接收邏輯進(jìn)行RDMA讀取響應(yīng)的接收和遞送，以完成該讀取請(qǐng)求，隨后著手任何后續(xù)RDMA請(qǐng)求的完成。
9.Context[Ch#]::PendingReadRequestsCount-用于表示傳送的但未完成的RDMA讀取請(qǐng)求的數(shù)目。
10.Context[Ch#]::PendingReadRequestCompletion-需要使用PendingReadRequest位。
11.Context[Ch#]::TotalPostedMsgCount-表示發(fā)布的但未傳送的消息。
12.Context[Ch#]::TotalPendingMsgCount-表示每個(gè)連接的等待完成的傳送消息的數(shù)目。
為了在描述符列表中表示RDMA消息，使用幾種描述符類(lèi)型。它們中的一個(gè)是如圖2中所示的消息描述符。該描述符啟動(dòng)每個(gè)RDMA消息，并攜帶消息描述和用于表示消息的其它描述符的有關(guān)信息。下述字段與本發(fā)明有關(guān)1.MessageDescriptor::MessageLength-用于攜帶消息長(zhǎng)度或者序號(hào)。
2.MessageDescriptor::SN/MsgLengthBit-用于描述MessageDescriptor::MessageLength字段的內(nèi)容。
完成算法根據(jù)本發(fā)明的完成算法24具有兩種完成觸發(fā)器(1)TCP確認(rèn)(ACK)的接收。這指示傳送的數(shù)據(jù)已在連接的另一端點(diǎn)被成功接收，該Ack涉及的RDMA操作(發(fā)送，寫(xiě)入)被完成。當(dāng)收到涉及該消息的Ack時(shí)，作為讀取操作的一部分的RDMA讀取響應(yīng)消息被完成。
(2)RDMA讀取響應(yīng)的接收和遞送。這指出對(duì)應(yīng)的RDMA讀取請(qǐng)求(或未決的讀取操作)被完成。
未決的完成請(qǐng)求指示被保存在連接上下文22中，包括Context[Ch#]::PendingCompletionRequest(它表示RNIC需要執(zhí)行完成操作；這實(shí)際上意味著接收邏輯接收了新的TCP Ack，或者接收并遞送了RDMA讀取響應(yīng)，并且完成邏輯應(yīng)弄清什么操作已被完成(如果有的話)并把這些操作的完成報(bào)告給消費(fèi)者)和Context[Ch#]::CompletedReadRequestsNum(它包含完成的讀取請(qǐng)求的數(shù)目)。該字段保存由接收邏輯接收和遞送的RDMA讀取響應(yīng)消息的數(shù)目。這實(shí)際上意味著完成邏輯能夠完成由消費(fèi)者發(fā)布的那么多未決RDMA讀取消息。從RNIC的觀點(diǎn)來(lái)看，完成邏輯完成那么多的RDMA讀取請(qǐng)求，并且仍然需要把該完成報(bào)告給消費(fèi)者。
圖3中表示了處理這些情況的總的方法。首先在步驟S1，檢查Context[Ch#]::CompletedReadRequestsNum。如果該值不為0(步驟S2)，那么指示連接具有未決的讀取請(qǐng)求完成。這種情況下，RNIC首先進(jìn)行下面描述的“讀取請(qǐng)求完成”操作，隨后執(zhí)行同樣如下面描述的“Ack完成”(步驟S3和S4)，而不考慮Context[Ch#]::PendingCompletionRequest位。如果Context[Ch#]::CompletedReadRequestsNum等于0并且Context[Ch#]::PendingCompletionRequest位被設(shè)定(步驟S5)，那么RNIC進(jìn)行同樣如下面所述的Ack完成(步驟S4)。
Ack完成接收的TCP Ack完成向請(qǐng)求輸出和響應(yīng)輸出信道16、18發(fā)布的RDMA請(qǐng)求。完成過(guò)程的主要挑戰(zhàn)是遵循從響應(yīng)輸出和請(qǐng)求輸出信道傳送消息的順序。為了保持該順序，RNIC利用選擇的消息的更新機(jī)構(gòu)25更新消息描述符，以便攜帶消息的最后字節(jié)的序號(hào)(SN)。當(dāng)RNIC傳送消息的最后一段時(shí)，執(zhí)行該更新過(guò)程(也稱為“寫(xiě)回”)。RNIC使用MessageDescriptor::MessageLength字段來(lái)攜帶消息長(zhǎng)度或序號(hào)。MessageDescriptor::SN/MsgLengthBit描述MessageDescriptor::MessageLength字段的內(nèi)容。
RNIC不更新所有消息，而只更新在信道被交換(swap)后使用的那些消息，即在交換信道之后，只有第一個(gè)消息被更新。當(dāng)傳送RDMA消息時(shí)，RNIC交織請(qǐng)求輸出和響應(yīng)輸出消息。RNIC在響應(yīng)輸出和請(qǐng)求輸出信道間進(jìn)行仲裁，并選擇信道之一來(lái)傳送下一消息。在傳送的消息的中間，信道不被交換。當(dāng)在信道間發(fā)生交換時(shí)，更新機(jī)構(gòu)25用信道交換之后信道中下一消息的SN更新消息描述符。在交換之后，只對(duì)新信道中的第一消息更新消息描述符，相關(guān)的SN被更新為該消息的最后傳送的字節(jié)的SN。如圖2中所示，隨后在完成和重傳過(guò)程中，使用保存在MessageLength字段中的信息(MessageLength或者SequenceNumber)。
圖4中表示了更新過(guò)程的一個(gè)例子。在該例子中，RNIC交換信道四次。它從請(qǐng)求輸出信道中的消息#1開(kāi)始，隨后交換到響應(yīng)輸出信道(消息#2)，并用消息#2的最后字節(jié)的SN更新該消息。在消息#3之后，RNIC交換到消息#4的請(qǐng)求輸出信道，RNIC更新消息#4。在消息#5之后，RNIC交換到消息#6的請(qǐng)求輸出信道，RNIC更新消息#6。在消息#7之后，RNIC交換到消息#8的請(qǐng)求輸出信道，RNIC更新消息#8。
只對(duì)利用兩個(gè)信道的連接進(jìn)行寫(xiě)回操作。如果連接只使用一個(gè)信道，那么不進(jìn)行任何寫(xiě)回操作。
RNIC把幾個(gè)序號(hào)保存在每個(gè)信道的連接上下文22中Context[Ch#]::ReqOutLastCompletedMsgSN，Context[Ch#]::ReqOutNextToCompleteMsgSN，Context[Ch#]::RespOutLastCompletedMsgSN，和Context[Ch#]::RespOutNextToCompleteMsgSN，它們分別攜帶每個(gè)信道中的最后完成的和第一個(gè)未完成的消息的序號(hào)(SN)。它們被初始化以攜帶初始的連接序號(hào)，并在完成操作中被更新。
Ack完成流程通過(guò)RNIC分別針對(duì)請(qǐng)求輸出和響應(yīng)輸出信道循環(huán)經(jīng)過(guò)一系列的步驟，實(shí)現(xiàn)完成流程。下面說(shuō)明該過(guò)程。注意最后接收的ACK的序號(hào)在Context[Ch#]::LastAckedSN中指出。
下面參考圖5的流程圖概述各個(gè)步驟。
步驟1(S10)如果信道正在等待RDMA讀取請(qǐng)求的完成(即，Context[Ch#]::PendingReadRequest被設(shè)定)，那么RNC忽略完成請(qǐng)求(S11)。注意該規(guī)則和響應(yīng)輸出信道不相關(guān)，因?yàn)轫憫?yīng)輸出信道只攜帶RDMA讀取響應(yīng)。
步驟2(S12)如果Context[Ch#]::NextToCompleteMsgSN無(wú)效，那么結(jié)束對(duì)該信道的完成請(qǐng)求的處理。這種情況發(fā)生在沒(méi)有發(fā)布更多的消息或者下一發(fā)布的消息完全未被傳送時(shí)。
步驟3(S13)如果Context[Ch#]::NextToCompleteMsgSN＞Context[Ch#]::LastAckedSN，那么接收的完成請(qǐng)求不完成該信道中的任何消息，并且針對(duì)該信道的完成請(qǐng)求的處理結(jié)束(S13)。
步驟4(S15)否則，完成請(qǐng)求完成該信道中的至少一個(gè)消息，RNIC如下更新連接上下文·Context[Ch#]::LastCompletedMsgSN由Context[Ch#]::NextToCompleteMsgSN更新；和·Context[Ch#]::NextToCompleteMsgSN由該信道中的下一消息的最后SN更新?？砂凑障率龇绞街粰z索下一消息的最后SN(1)當(dāng)MessageDescriptor::SN/MsgLengthBit指示MessageDescriptor::MessageLength/SN字段攜帶序號(hào)時(shí)，在MessageDescriptor::MessageLength/SN字段中明確地檢索下一消息的最后SN；(2)利用MessageDescriptor∷MessageLength作為應(yīng)用有效負(fù)載的大小，并增加協(xié)議報(bào)頭、腳注和控制信息(DDP報(bào)頭、標(biāo)記、填充、CRC)，默示地檢索下一消息的最后SN；和(3)當(dāng)信道不具有下一傳送的消息時(shí)，無(wú)效。這包括當(dāng)沒(méi)有發(fā)布任何消息時(shí)的情況，以及當(dāng)消息已被發(fā)布但是未被完全傳送時(shí)的情況。
注意如果完成的消息不是RDMA讀取請(qǐng)求，那么RNIC執(zhí)行RDMA操作的完成，其細(xì)節(jié)與本發(fā)明的主題無(wú)關(guān)。
就RDMA讀取請(qǐng)求來(lái)說(shuō)，RNIC等待RDMA讀取響應(yīng)以實(shí)現(xiàn)完成，并設(shè)定Context[Ch#]::PendingReadRequest位。
步驟5返回步驟1。
RDMA讀取請(qǐng)求完成當(dāng)收到涉及發(fā)布的RDMA請(qǐng)求的TCP Ack時(shí)，RNIC完成該請(qǐng)求。RDMA讀取請(qǐng)求是當(dāng)收到對(duì)應(yīng)的RDMA讀取響應(yīng)時(shí)完成的例外情況。
RDMA排序規(guī)則要求按照RDMA請(qǐng)求被發(fā)送的順序完成RDMA請(qǐng)求。這意味著在完成RDMA讀取請(qǐng)求后的RDMA請(qǐng)求之前，RNIC需要等待接收RDMA讀取響應(yīng)。接收的RDMA讀取響應(yīng)的處理示于圖6中的流程圖中，并且包含下述步驟步驟1(S20)如有必要，執(zhí)行在RDMA讀取請(qǐng)求之前的RDMA請(qǐng)求的完成。
這是非常罕見(jiàn)的情況，并且當(dāng)在收到RDMA讀取響應(yīng)之前，完成請(qǐng)求一直未被處理時(shí)發(fā)生這種情況。從而，RNIC需要首先完成在RDMA讀取請(qǐng)求之前的所有請(qǐng)求。這種情況由非零的Context[Ch#]::PendingReadRequestsCount和清除的(clear)Context[Ch#]::PendingReadRequest位指出。
步驟2(S21)執(zhí)行RDMA讀取請(qǐng)求本身的完成。
RNIC執(zhí)行RDMA讀取操作的完成；其細(xì)節(jié)與本發(fā)明無(wú)關(guān)。
步驟3(S22)執(zhí)行在完成的RDMA讀取請(qǐng)求后的任意RDMA請(qǐng)求的完成。
上面在“Ack完成”部分中描述了該過(guò)程。
步驟4(S23)重復(fù)步驟2-3N次，其中N是由Context[Ch#]::CompletedReadRequestsNum定義的完成的RDMA讀取請(qǐng)求的數(shù)目。
圖7中也描述了這些過(guò)程的一個(gè)例子。
重傳請(qǐng)求流程重傳請(qǐng)求的處理涉及解決下述問(wèn)題問(wèn)題1RNIC需要處理該連接的所有未決的完成請(qǐng)求。于是，如果一個(gè)連接具有未決的完成請(qǐng)求，那么RNIC被請(qǐng)求處理該請(qǐng)求。只有在該連接的完成處理已結(jié)束之后，才恢復(fù)重傳請(qǐng)求的處理。
問(wèn)題2可歸因于快速重傳機(jī)構(gòu)，或者歸因于超時(shí)，請(qǐng)求重傳。歸因于超時(shí)的重傳涉及所有傳送的但是未完成的TCP段的重傳。歸因于快速重傳機(jī)構(gòu)的重傳只涉及第一個(gè)未完成的TCP段的重傳。RNIC使用不同的重傳請(qǐng)求類(lèi)型。重傳請(qǐng)求的處理取決于下面說(shuō)明的請(qǐng)求類(lèi)型。
問(wèn)題3重傳請(qǐng)求處理的關(guān)鍵部分之一是請(qǐng)求輸出或響應(yīng)輸出描述符列表中待重傳的段的位置。下面描述了該過(guò)程。
重傳不必保持傳送的段的邊界。應(yīng)從其開(kāi)始重傳的位置由LastAckedSN指示。套接字和iSCSI對(duì)傳送的段邊界的變化不敏感。iSCSI假定TCP不提交對(duì)未傳送的數(shù)據(jù)進(jìn)行重傳的請(qǐng)求。這允許iSCSI數(shù)據(jù)處理邏輯假定在重傳期間，所有入站中間命令描述符攜帶在傳送期間計(jì)算的有效iSCSI CRC。
RDMA保持傳送的DDP段的邊界，從而可從不同于LastAckedSN的位置開(kāi)始重傳。
重傳請(qǐng)求類(lèi)型如圖8中所示，TCP發(fā)布三種重傳請(qǐng)求(1)歸因于快速重傳的重傳；(2)歸因于超時(shí)的開(kāi)始重傳；以及(3)繼續(xù)進(jìn)行超時(shí)重傳。
所有類(lèi)型的重傳請(qǐng)求涉及單個(gè)TCP段的重傳。RNIC按請(qǐng)求輸出和響應(yīng)輸出信道，利用NextToCompletion和NextToSend指針，保持完成的、等待完成的和等待傳送的消息的邊界。RNIC還保存每個(gè)連接的發(fā)布的但未傳送的消息的數(shù)目(Context[Ch#]::TotalPostedMsgCount)和等待完成的傳送消息的數(shù)目(Context[Ch#]::TotalPendingMsgCount)。注意，為每個(gè)連接保持Context[Ch#]::TotalPostedMsgCount和Context[Ch#]::Total PendingMsgCount，并且它們被用于響應(yīng)輸出和請(qǐng)求輸出信道。在快速重傳的情況下，RNIC只重傳第一個(gè)未完成的段(即，在NextToComplete引用的消息內(nèi)的TCP段)，而不更新上面提及的任何指針或計(jì)數(shù)器。如下所述選擇開(kāi)始重傳的信道。
就歸因于超時(shí)的開(kāi)始重傳來(lái)說(shuō)，RNIC更新一個(gè)或兩個(gè)信道的NextToSend指針，以便指向由NextToComplete(N2C)指向的消息內(nèi)該信道中第一個(gè)未完成的TCP段，并從該位置開(kāi)始重傳單一的TCP段。Context[Ch#]::TotalPostedMsgCount和Context[Ch#]::TotalPendingMsgCount被分別更新。NextToSend(N2S)信道指針向前移動(dòng)，以指向?qū)⒃谠撔诺乐兄貍?或者傳送)的下一段。就繼續(xù)進(jìn)行超時(shí)重傳來(lái)說(shuō)，RNIC從NextToSend指向的位置重傳單一TCP段，并分別更新NextToSend和Context[Ch#]::TotalPendingMsgCount。注意，TCP并不請(qǐng)求未被傳送的TCP數(shù)據(jù)的重傳。
待重傳段的定位通過(guò)使兩個(gè)信道請(qǐng)求輸出和響應(yīng)輸出保持傳送的消息，實(shí)現(xiàn)待重傳的TCP段的定位(location)。待重傳段的定位由下面概述的幾個(gè)步驟組成步驟1找出請(qǐng)求輸出信道中的第一個(gè)未完成的消息。
在該步驟之后，每個(gè)信道(請(qǐng)求輸出和響應(yīng)輸出)具有一個(gè)候選消息。只有當(dāng)信道等待未決RDMA讀取請(qǐng)求的完成(即Context[Ch#]::PendingReadRequest位被設(shè)定)時(shí)，該步驟才是相關(guān)的，因此該步驟只對(duì)請(qǐng)求輸出信道相關(guān)。
這涉及和上面在“完成流程”部分中的計(jì)算選項(xiàng)的討論中描述的信道消息過(guò)程的常規(guī)完成走查(walk-through)非常類(lèi)似的過(guò)程。此過(guò)程的目標(biāo)是找出具有超過(guò)Context[Ch#]::LastAckedSN的最后序號(hào)的消息。該消息可能攜帶待重傳的段。如圖9中所示，在例A中，該消息是消息#5，在例B中，該消息是消息#8。走查過(guò)程涉及消息的最后序號(hào)的計(jì)算。注意針對(duì)請(qǐng)求輸出描述符的走查與由于如上所述的TCPAck的接收導(dǎo)致的針對(duì)常規(guī)完成操作描述的走查的一個(gè)重要差別。該差別是在歸因于重傳的走查中，RNIC忽略RDMA排序規(guī)則，把RDMA讀取請(qǐng)求看作單向RDMA操作(例如，發(fā)送或RDMA寫(xiě)入)。這樣做是因?yàn)槟康脑谟诘竭_(dá)未被TCP成功傳送的第一個(gè)RDMA消息。
在上面針對(duì)歸因于RDMA讀取響應(yīng)接收的完成的情況描述的圖9的例子中，對(duì)于兩個(gè)例子，常規(guī)的完成處理過(guò)程都會(huì)以ReqOut::NCSN＝100、ReqOut::LCSN＝0、ReqOut::NCSN＝600、ReqOut::LCSN＝300結(jié)束(注意RespOut已指向候選的WQE)。在這兩個(gè)例子的ReqOut信道中，完成過(guò)程會(huì)停在第一個(gè)未決的RDMA讀取請(qǐng)求(在這些例子中，它是第一個(gè)WQE#)上。這兩個(gè)例子間的差別在于對(duì)于例A來(lái)說(shuō)，最后接收的Ack的AckSN為450，對(duì)于例B來(lái)說(shuō)則為550。這是重傳操作的初始條件。重傳操作以ReqOut信道中的走查開(kāi)始。在例A中，RNIC走查WQE#1和WQE#4，并到達(dá)WQE#5，它以大于LastAckedSN(450)的SN(500)結(jié)束。在例B中，走查停在WQE#8。隨后分別針對(duì)每個(gè)例子更新NCSN和LCSN。
注意，走查過(guò)程與具有未決的RDMA讀取請(qǐng)求的請(qǐng)求輸出信道相關(guān)。否則，在無(wú)讀取請(qǐng)求的情況下，或者在響應(yīng)輸出信道的情況下，NextToComplete(N2C)總是指向候選消息。注意，在重傳請(qǐng)求的執(zhí)行前，必須針對(duì)兩個(gè)信道執(zhí)行常規(guī)完成，只是確保不存在未決的完成操作。
步驟2在兩個(gè)候選消息(分別屬于請(qǐng)求輸出信道和響應(yīng)輸出信道)間選擇帶有待重傳的段的消息。
為了選擇擁有待重傳段的消息，RNIC比較Context[Ch#]::ReqOutNextToCompleteMsgSN和Context[Ch#]::RespOutNextToCompleteMsgSN。較小的值屬于擁有具有待重傳的段的消息的信道。
圖9證明了兩個(gè)例子。在例A(ReqOut::NCSN＝500，RespOut::NCSN＝600)中，選擇的消息屬于請(qǐng)求輸出信道，即，消息#5。在例B(ReqOut::NCSN＝800，RespOut::NCSN＝600)中，選擇的消息屬于響應(yīng)輸出信道，即消息#6。
步驟3找出屬于從其開(kāi)始重傳的消息的數(shù)據(jù)緩沖區(qū)。
在消息選擇之后，該步驟確定指向待重傳段的起點(diǎn)的指針描述符的位置。為了找到指針描述符，RNIC需要計(jì)算消息的起始序號(hào)。注意，消息的起始SN可被用于幫助找出消息內(nèi)的緩沖區(qū)偏移量，該偏移量可被用于找出從其開(kāi)始重傳的緩沖區(qū)。消息的最后序號(hào)已知，并被保存在連接上下文中(Context[Ch#]::ReqOutNextToCompleteMsgSN或Context[Ch#]::RespOutNextToCompleteMsgSN)。
為了計(jì)算消息的起始序號(hào)，RNIC比較Context[Ch#]::ReqOutLastCompletedMsgSN與Context[Ch#]::RespOutLastCompletedMsgSN。較大的值指示消息的起始序號(hào)，更準(zhǔn)確地說(shuō)，消息的起始序號(hào)等于max(Context[Ch#]::ReqOutLastCompletedMsgSN，Context[Ch#]::RespOutLastCompletedMsgSN)+1。
如圖9中所示，在例A中，起始序號(hào)為401，在例B中，起始序號(hào)為501。一旦找到消息的起始序號(hào)，RNIC走查指針描述符，并尋找持有待重傳段的起點(diǎn)的指針描述符。注意一般來(lái)說(shuō)，LastAckedSN指示待重傳段的起點(diǎn)。
這里描述的系統(tǒng)、功能、機(jī)構(gòu)、方法、引擎和模塊可用硬件、軟件或硬件和軟件的組合來(lái)實(shí)現(xiàn)。它們可由任意類(lèi)型的計(jì)算機(jī)系統(tǒng)或者適合于執(zhí)行這里描述的方法的其它設(shè)備來(lái)實(shí)現(xiàn)。硬件和軟件的典型組合可以是具有計(jì)算機(jī)程序的通用計(jì)算機(jī)系統(tǒng)，當(dāng)被加載和執(zhí)行時(shí)，所述計(jì)算機(jī)程序控制計(jì)算機(jī)系統(tǒng)執(zhí)行這里描述的方法?；蛘撸梢岳冒糜趫?zhí)行本發(fā)明的一個(gè)或多個(gè)功能任務(wù)的專用硬件的專用計(jì)算機(jī)。本發(fā)明還可被嵌入計(jì)算機(jī)程序產(chǎn)品中，所述計(jì)算機(jī)程序產(chǎn)品包含能夠?qū)崿F(xiàn)這里描述的方法和功能的所有特征，并且當(dāng)被裝入計(jì)算機(jī)系統(tǒng)中時(shí)，能夠執(zhí)行這些方法和功能。本文中的計(jì)算機(jī)程序、軟件程序、程序、程序產(chǎn)品或軟件意味著一組指令的用任意語(yǔ)言、代碼或符號(hào)表示的任意表述，所述一組指令意圖使具有信息處理能力的系統(tǒng)直接地，或者在下述任一或下述二者之后執(zhí)行特定的功能a)轉(zhuǎn)換成另一種語(yǔ)言，代碼或符號(hào)；b)用不同的材料形式再現(xiàn)。
上面出于舉例說(shuō)明的目的，給出了本發(fā)明的優(yōu)選實(shí)施例的說(shuō)明。優(yōu)選實(shí)施例的上述說(shuō)明不是窮盡的，也不打算把本發(fā)明局限于公開(kāi)的明確形式，顯然鑒于上述教導(dǎo)，許多修改和變化是可能的。對(duì)本領(lǐng)域的技術(shù)人員來(lái)說(shuō)顯而易見(jiàn)的這種修改和變化包括在由附加的權(quán)利要求限定的本發(fā)明的范圍內(nèi)。
權(quán)利要求
1.一種處理具有請(qǐng)求輸出信道(16)和響應(yīng)輸出信道(18)的遠(yuǎn)程數(shù)據(jù)存儲(chǔ)器存取(RDMA)環(huán)境中的完成過(guò)程的系統(tǒng)，包括每個(gè)信道的描述符列表(12、14)，其中每個(gè)描述符列表(12、14)包括信道中每個(gè)消息的消息描述符；每當(dāng)在請(qǐng)求輸出信道(16)和響應(yīng)輸出信道(18)間發(fā)生信道交換時(shí)，用消息中最后字節(jié)的序號(hào)更新消息描述符中的消息長(zhǎng)度字段的更新機(jī)構(gòu)(25)；檢查完成上下文(22)中的值并比較下一要完成的消息的序號(hào)與最后確認(rèn)的序號(hào)，以確定該消息是否應(yīng)被完成的確認(rèn)(Ack)完成系統(tǒng)；和執(zhí)行讀取請(qǐng)求的完成的讀取請(qǐng)求完成系統(tǒng)。
2.按照權(quán)利要求1所述的系統(tǒng)，其中確認(rèn)完成系統(tǒng)包括獨(dú)立應(yīng)用于請(qǐng)求輸出信道(16)和響應(yīng)輸出信道(18)中每個(gè)的一系列重復(fù)的邏輯步驟。
3.按照權(quán)利要求2所述的系統(tǒng)，其中所述重復(fù)的邏輯步驟包括如果下一要完成的消息的序號(hào)無(wú)效，那么斷定完成過(guò)程的處理結(jié)束；如果下一要完成的消息的序號(hào)大于最后確認(rèn)的序號(hào)，那么斷定完成過(guò)程的處理結(jié)束；和如果下一要完成的消息的序號(hào)小于或等于最后確認(rèn)的序號(hào)，那么完成該信道中的信息。
4.按照權(quán)利要求3所述的系統(tǒng)，其中所述重復(fù)的邏輯步驟還包括下述步驟如果請(qǐng)求輸出信道(16)正在等待讀取請(qǐng)求的完成，那么終止請(qǐng)求輸出信道(16)中的完成過(guò)程。
5.按照權(quán)利要求3所述的系統(tǒng)，其中完成信道中的消息的步驟還包括下述步驟用下一要完成的消息的序號(hào)更新最后完成的消息的序號(hào)；和用信道中的下一消息的最后序號(hào)更新下一要完成的消息的序號(hào)。
6.按照權(quán)利要求5所述的系統(tǒng)，其中完成信道中的消息的步驟還包括下述步驟如果完成的消息不是讀取請(qǐng)求消息，那么執(zhí)行操作的完成；如果消息是讀取請(qǐng)求消息，那么在執(zhí)行完成之前，等待讀取響應(yīng)的接收和傳送以便執(zhí)行完成，隨后設(shè)定完成上下文中的未決的讀取請(qǐng)求位。
7.按照權(quán)利要求2所述的系統(tǒng)，其中讀取請(qǐng)求完成系統(tǒng)提供第二系列的邏輯步驟，所述第二系列的邏輯步驟包括完成在讀取請(qǐng)求前的任何請(qǐng)求；完成該讀取請(qǐng)求；和完成在該讀取請(qǐng)求后的任何請(qǐng)求。
8.按照權(quán)利要求7所述的系統(tǒng)，其中第二組邏輯步驟中的最后兩個(gè)步驟被重復(fù)N次，其中N是保存在完成上下文中的表示完成的讀取請(qǐng)求的數(shù)目的值。
9.按照權(quán)利要求1所述的系統(tǒng)，還包括處理重傳請(qǐng)求的系統(tǒng)，包括定位待重傳的段的第三系列的邏輯步驟，其中所述第三系列的邏輯步驟包括執(zhí)行完成操作，以確保沒(méi)有未決的完成；識(shí)別請(qǐng)求輸出信道(16)和響應(yīng)輸出信道(18)的候選消息；從這兩個(gè)候選消息中選擇攜帶待傳送的段的消息；和確定指向待重傳的段的起點(diǎn)的指針描述符的位置。
10.按照權(quán)利要求9所述的系統(tǒng)，其中如果請(qǐng)求輸出信道(16)正在等待未決的讀取請(qǐng)求的完成，那么請(qǐng)求輸出信道(16)中的候選消息包含請(qǐng)求輸出信道(16)中的第一個(gè)未完成的消息；其中如果請(qǐng)求輸出信道(16)不是正在等待未決的讀取請(qǐng)求的完成，那么請(qǐng)求輸出信道(16)中的候選消息由下一要完成(N2C)指針給出；和其中響應(yīng)輸出信道(18)中的候選消息由下一要完成(N2C)指針給出。
11.按照權(quán)利要求9所述的系統(tǒng)，其中攜帶待傳送的段的消息是駐留于具有下一要完成消息的最低序號(hào)的信道中的候選消息。
12.按照權(quán)利要求9所述的系統(tǒng)，其中指向待重傳的段的起點(diǎn)的指針描述符的位置是下述序號(hào)中的最大值加1請(qǐng)求輸出信道(16)中的最后完成的消息的序號(hào)；和響應(yīng)輸出信道(18)中的最后完成的消息的序號(hào)。
13.一種處理具有請(qǐng)求輸出信道(16)和響應(yīng)輸出信道(18)的遠(yuǎn)程數(shù)據(jù)存儲(chǔ)器存取(RDMA)環(huán)境中的完成過(guò)程的方法，包括利用下述步驟對(duì)每個(gè)信道執(zhí)行確認(rèn)完成如果下一要完成的消息的序號(hào)無(wú)效，那么斷定完成過(guò)程的處理結(jié)束；如果下一要完成的消息的序號(hào)大于最后確認(rèn)的序號(hào)，那么斷定完成過(guò)程的處理結(jié)束；如果下一要完成的消息的序號(hào)小于或等于最后確認(rèn)的序號(hào)，那么完成該信道中的信息；和如果請(qǐng)求輸出信道(16)正在等待讀取請(qǐng)求的完成，那么終止請(qǐng)求輸出信道(16)中的完成過(guò)程。
14.按照權(quán)利要求13所述的方法，其中完成信道中的消息的步驟還包括下述步驟用下一要完成的消息的序號(hào)更新最后完成的消息的序號(hào)；和用信道中的下一消息的最后序號(hào)更新下一要完成的消息的序號(hào)。
15.按照權(quán)利要求14所述的方法，其中完成信道中的消息的步驟還包括下述步驟如果完成的消息不是讀取請(qǐng)求消息，那么執(zhí)行操作的完成；如果消息是讀取請(qǐng)求消息，那么等待讀取響應(yīng)以便執(zhí)行完成，并設(shè)定未決讀取請(qǐng)求位。
16.按照權(quán)利要求13所述的方法，還包括讀取請(qǐng)求完成方法，所述讀取請(qǐng)求完成方法包括下述步驟完成在讀取請(qǐng)求前的任何請(qǐng)求；完成該讀取請(qǐng)求；完成在該讀取請(qǐng)求后的任何請(qǐng)求；和重復(fù)上兩個(gè)步驟N次，其中N是表示完成的讀取請(qǐng)求的數(shù)目的值。
17.一種在具有請(qǐng)求輸出信道(16)和響應(yīng)輸出信道(18)的遠(yuǎn)程數(shù)據(jù)存儲(chǔ)器存取(RDMA)環(huán)境中，針對(duì)重傳請(qǐng)求定位待重傳的段的方法，包括執(zhí)行完成操作；識(shí)別請(qǐng)求輸出信道(16)和響應(yīng)輸出信道(18)的候選信息；從這兩個(gè)候選信息中選擇攜帶待傳送的段的消息；和確定指向待重傳的段的起點(diǎn)的指針描述符的位置。
18.按照權(quán)利要求17所述的方法，其中如果請(qǐng)求輸出信道(16)正在等待未決的讀取請(qǐng)求的完成，那么請(qǐng)求輸出信道(16)中的候選消息包含請(qǐng)求輸出信道(16)中的第一未完成的消息；其中如果請(qǐng)求輸出信道(16)不是正在等待未決的讀取請(qǐng)求的完成，那么請(qǐng)求輸出信道(16)中的候選消息由下一要完成(N2C)指針給出；和其中響應(yīng)輸出信道(18)中的候選消息由下一要完成(N2C)指針給出。
19.按照權(quán)利要求18所述的方法，其中攜帶待傳送的段的消息是駐留于具有下一要完成消息的最低序號(hào)的信道中的候選消息。
20.按照權(quán)利要求18所述的方法，其中指向待重傳的段的起點(diǎn)的指針描述符的位置是下述序號(hào)中的最大值加1請(qǐng)求輸出信道(16)中的最后完成的消息的序號(hào)；和響應(yīng)輸出信道(18)中的最后完成的消息的序號(hào)。
21.一種處理具有請(qǐng)求輸出信道和響應(yīng)輸出信道的遠(yuǎn)程數(shù)據(jù)存儲(chǔ)器存取(RDMA)環(huán)境中的傳送過(guò)程的系統(tǒng)，包括每個(gè)信道的描述符列表(12、14)，其中每個(gè)描述符列表(12、14)包括信道中每個(gè)消息的消息描述符；和每當(dāng)在請(qǐng)求輸出信道(16)和響應(yīng)輸出信道(18)間發(fā)生信道交換時(shí)，用消息中的最后字節(jié)的序號(hào)更新消息描述符中的消息長(zhǎng)度字段的更新機(jī)構(gòu)(25)。
全文摘要
一種保持RDMA環(huán)境中的完成和重傳操作的排序的系統(tǒng)和方法。提供一種處理具有請(qǐng)求輸出信道(16)和響應(yīng)輸出信道(18)的遠(yuǎn)程數(shù)據(jù)存儲(chǔ)器存取(RDMA)環(huán)境中的完成過(guò)程的系統(tǒng)，包括每個(gè)信道的描述符列表(12、14)，其中每個(gè)描述符列表(12、14)包括信道中的每個(gè)消息的消息描述符；每當(dāng)在請(qǐng)求輸出信道(16)和響應(yīng)輸出信道(18)間發(fā)生信道交換時(shí)，用消息中的最后字節(jié)的序號(hào)更新消息描述符中的消息長(zhǎng)度字段的更新機(jī)構(gòu)(25)；檢查完成上下文(22)中的值并比較下一要完成的消息的序號(hào)與最后確認(rèn)的序號(hào)，以確定該消息是否應(yīng)被完成的確認(rèn)(Ack)完成系統(tǒng)；和執(zhí)行讀取請(qǐng)求的完成的讀取請(qǐng)求完成系統(tǒng)。
文檔編號(hào)G06F9/46GK1890657SQ200480035688
公開(kāi)日2007年1月3日 申請(qǐng)日期2004年12月2日 優(yōu)先權(quán)日2003年12月2日
發(fā)明者吉奧拉·比拉恩, 佐里克·馬儲(chǔ)爾斯基, 瓦迪姆·馬克瓦克斯 申請(qǐng)人:國(guó)際商業(yè)機(jī)器公司