专利名称：Rdma完成和重传系统以及方法
技术领域：
本发明一般涉及远程数据存储器存取(RDMA)完成和重传系统，更具体地说，涉及保持响应输出(ResponseOut)和请求输出信道(RequestOut channel)间的排序的RDMA完成和重传的实现。
背景技术：
RDMA(远程数据存储器存取)是使一台计算机直接把信息放入另一台计算机的存储器中的网络接口卡(RIC)特征。通过使对带宽和处理开销的要求最小化，该技术降低了等待时间。由于必须在内核和应用之间复制数据，传统的硬件和软件体系结构对服务器的CPU和存储器施加相当大的负载。当连接速度超过服务器的处理能力和存储器带宽时，存储器瓶颈变得更严重。
通过在RNIC(RDMA网络接口卡)上的硬件中实现可靠的传送协议，和通过利用内核旁路支持零复制连网，RDMA避免了该问题。零复制连网使RNIC可以往来于应用存储器直接传送数据，不需要在应用存储器和内核间复制数据。
内核旁路使应用向RNIC发出命令，而不必执行内核调用。RDMA请求从用户空间被发送给本地RNIC，并通过网络发送给远程RNIC，而不需要涉及任何内核。这减少了在处理网络业务量(traffic)时内核空间和用户空间之间的上下文切换的数目。
RDMA消费者(应用)使用消息语义学来通信。用消息发布供传送的数据，用消息接收数据，并且预期以消息为单位报告完成。TCP本身是面向字节流的协议，它不知道ULP数据的可能消息边界。于是，消息-字节流语义学的变换的任务落到RDMA以及它们的卸载的实现(offloaded implementation)上。
RDMA是使用TCP可靠性服务的面向消息的ULP。RDMA向从面向消息的ULP到面向字节的TCP语义学的映射增加了另一层复杂性。RDMA使用相同的TCP连接来传送由两个独立的源发布的消息·请求输出-由本地消费者发起的RDMA请求；和·响应输出-作为由远程消费者发送的入站RDMA读取请求的接收和处理的结果，由RNIC发起的RDMA响应。
当通过相同的TCP连接传送请求输出和响应输出消息时，RNIC交织请求输出和响应输出消息。除了字节流-消息流映射之外，在完成和重传过程期间，RNIC需要保持来自请求输出和响应输出的消息间的“传送排序”。
不同的RDMA请求(例如“Fence”)和完成排序规则(例如当RNIC收到RDMA读取响应时，完成RDMA读取请求)可挂起请求输出中的传送或完成过程。但是，这种挂起不会阻止响应输出进行RDMA读取响应的传送和完成。因此，为了保持RDMA请求队列和RDMA响应队列之间的无关性，需要一种有效地保持这两个队列间的顺序的系统。
解决该问题的一种方法是建立利用控制结构(描述符)和/或通过保持数据的独立副本实现的单一请求/响应信道。这种方法具有几个缺点，包括·需要另外的复制操作；·为了实现这种方法(数据/控制被复制到适配器存储器)，需要更多的RNIC资源；·缺乏灵活性(适配器存储器是有限的资源，它限制了线路上可能待处理的(outstanding)RDMA消息的数目)；和·强制执行RDMA请求和RDMA响应间的完成排序更困难。
因此，需要一种解决上述问题的解决方案。
发明内容
通过提供一种用于RDMA流的完成和重传的有效解决方案，而不需要额外复制数据或控制结构来保持排序，本发明解决了上面提及的问题以及其它问题。在第一方面，本发明提供一种处理具有请求输出信道和响应输出信道的远程数据存储器存取(RDMA)环境中的完成请求的过程，包括每个信道的描述符列表，其中每个描述符列表包括信道中每个消息的消息描述符；每当在请求输出信道和响应输出信道间发生信道交换时，用消息中的最后字节的序号更新消息描述符中的消息长度字段的更新机构；检查完成上下文中的值并比较下一要完成的消息的序号与最后确认的序号，以确定该消息是否应被完成的确认(Ack)完成系统；和执行读取请求的完成的读取请求完成系统。
在第二方面，本发明提供一种处理具有请求输出信道和响应输出信道的远程数据存储器存取(RDMA)环境中的完成过程的方法，包括利用下述步骤对每个信道执行确认完成如果下一要完成的消息的序号无效，那么断定完成过程的处理结束；如果下一要完成的消息的序号大于最后确认的序号，那么断定完成过程的处理结束；如果下一要完成的消息的序号小于或等于最后确认的序号，那么完成该信道中的信息。
在第三方面，本发明提供一种在具有请求输出信道和响应输出信道的远程数据存储器存取(RDMA)环境中，针对重传请求定位待重传的段的方法，包括识别请求输出信道和响应输出信道的候选信息；从这两个候选信息中选择携带待传送的段的消息；和确定指向(referto)待重传的段的起点的指针描述符的位置。
在第四方面，本发明提供一种处理具有请求输出信道和响应输出信道的远程数据存储器存取(RDMA)环境中的传送过程的系统，包括每个信道的描述符列表，其中每个描述符列表包括信道中每个消息的消息描述符；每当在请求输出信道和响应输出信道间发生信道交换时，用消息中的最后字节的序号更新消息描述符中的消息长度字段的更新机构。
结合附图，根据本发明的各个方面的下述详细说明，将更易于理解本发明的这些和其它特征，其中图1描述根据本发明的保持排序的完成和传输系统。
图2描述根据本发明的消息描述符。
图3描述根据本发明的完成算法的流程图。
图4描述根据本发明的更新请求输出和响应输出信道中的序号的例子。
图5描述表示Ack完成操作的流程图。
图6描述表示RDMA读取请求完成操作的流程图。
图7描述根据本发明的保持请求输出和响应输出信道中的完成排序的一对例子。
图8描述根据本发明的三种重传情况。
图9描述根据本发明的保持请求输出和响应输出信道中的重传排序的一对例子。
具体实施例方式
下面描述的是实现RDMA完成和重传的系统和方法。在RDMA协议内，“完成”被定义成通知ULP(上层协议)，特定的RDMA操作已执行针对RDMA操作规定的所有功能(包括放置和递送)的过程。每个RDMA操作的完成语义被清楚定义。“重传”被定义成通过信道重传数据的过程。
如下所述，本发明利用双信道实现(即一个信道用于响应输出，一个信道用于请求输出)。为了完成这样的实现，本发明提供一种每当需要完成或重传操作时，保持这两个信道间的排序的方法。
对于本说明来说，假定读者已理解RDMA协议及其在RNIC环境中的实现。RDMA协议可在网上从<www.rdmaconsortium.org/home>获得。
背景-RDMA协议排序规则RDMA协议定义通过请求输出信道传送的消息的完成排序规则。这些规则略述如下所有RDMA请求必须按照消费者发布(post)它们的顺序来完成。RDMA具有三种请求(1)由单一RDMA消息(例如发送，写入)组成的RDMA操作。这些操作是用于把数据从本地主机传送到远程主机，由从远程主机发送给本地主机的单一RDMA消息组成。当RNIC能够保证包含这些消息的所有TCP段会被可靠地传送给TCP连接的另一端点时，发送和写入操作被认为已完成。
(2)由几个(一般为两个)RDMA消息组成的RDMA操作，例如读取。这些操作是用来从远程存储器读取数据。这种操作由两个RDMA消息组成读取请求和读取响应。读取请求是由请求始发者发送给数据源的消息。该消息携带从远程存储器读取数据和建立响应消息所必需的全部信息。由远程主机产生的响应消息是读取响应。该消息携带应被写入请求者存储器的数据，还包括数据应被写入的位置的描述。当RDMA读取响应消息已被读取发起者成功接收时，认为读取操作已完成。RDMA读取响应不是独立的RDMA操作(即，它是读取操作的一部分)，于是当传输层成功传送RDMA读取响应时，该消息被认为已完成。
(3)本地RDMA操作(例如绑定，快速登记)。这些操作不会导致任何数据(即，TCP段)的传送。当本地RDMA操作的处理由RNIC完成时，本地RDMA操作被看作完成。
概述参见图1，图中表示了保持响应输出和请求输出信道间的排序的完成和重传系统10。当利用完成算法24或重传算法26发出“完成请求”或者“重传请求”时，排序被保持。为了便于执行该过程，系统10(1)向请求输出和响应输出信道16、18提供独立的描述符列表12、14；和(2)利用出自这些描述符列表的信息，进行传送、完成和重传操作。
在这种方法中，每个工作队列项目(WQE)被处理(即，读取)两次，第一次是当传送该WQE时，第二次是当完成该WQE时(注意重传操作会要求额外读取重传的WQE)。
RNIC为每个RDMA连接保持维持该连接所需的信息。该信息被保存在连接上下文22中，在本实施例中，一组连接上下文字段被用于便于完成算法24和重传算法26的实现。在一个例证实施例中，上下文字段由Context[Ch#]::FieldName指示。下述上下文字段与本发明相关1.Context[Ch#]::PendingCompletionRequest-用于表示RNIC具有待处理的未决(pending)Ack或者RDMA读取完成请求的位。
2.Context[Ch#]::CompletedReadRequestsNum-用于表示完成的读取请求的数目。
3.Context[Ch#]::ReqOutLastCompletedMsgSN-用于表示请求输出信道中最后完成的消息的序号(SN)。
4.Context[Ch#]::ReqOutNextToCompleteMsgSN-用于表示请求输出信道中下一待完成消息的序号(SN)。
5.Context[Ch#]::RespOutLastCompletedMsgSN-用于表示响应输出信道中最后完成的消息的序号(SN)。
6.Context[Ch#]::RespOutNextToCompleteMsgSN-用于表示响应输出信道中下一待完成消息的序号(SN)。
7、Context[Ch#]::LastAckedSN-最后接收的ACK的序号。
8、Context[Ch#]::PendingReadRequest-该位指示在执行完成操作时，RNIC停止在RDMA读取请求，并且必须等待接收逻辑进行RDMA读取响应的接收和递送，以完成该读取请求，随后着手任何后续RDMA请求的完成。
9.Context[Ch#]::PendingReadRequestsCount-用于表示传送的但未完成的RDMA读取请求的数目。
10.Context[Ch#]::PendingReadRequestCompletion-需要使用PendingReadRequest位。
11.Context[Ch#]::TotalPostedMsgCount-表示发布的但未传送的消息。
12.Context[Ch#]::TotalPendingMsgCount-表示每个连接的等待完成的传送消息的数目。
为了在描述符列表中表示RDMA消息，使用几种描述符类型。它们中的一个是如图2中所示的消息描述符。该描述符启动每个RDMA消息，并携带消息描述和用于表示消息的其它描述符的有关信息。下述字段与本发明有关1.MessageDescriptor::MessageLength-用于携带消息长度或者序号。
2.MessageDescriptor::SN/MsgLengthBit-用于描述MessageDescriptor::MessageLength字段的内容。
完成算法根据本发明的完成算法24具有两种完成触发器(1)TCP确认(ACK)的接收。这指示传送的数据已在连接的另一端点被成功接收，该Ack涉及的RDMA操作(发送，写入)被完成。当收到涉及该消息的Ack时，作为读取操作的一部分的RDMA读取响应消息被完成。
(2)RDMA读取响应的接收和递送。这指出对应的RDMA读取请求(或未决的读取操作)被完成。
未决的完成请求指示被保存在连接上下文22中，包括Context[Ch#]::PendingCompletionRequest(它表示RNIC需要执行完成操作；这实际上意味着接收逻辑接收了新的TCP Ack，或者接收并递送了RDMA读取响应，并且完成逻辑应弄清什么操作已被完成(如果有的话)并把这些操作的完成报告给消费者)和Context[Ch#]::CompletedReadRequestsNum(它包含完成的读取请求的数目)。该字段保存由接收逻辑接收和递送的RDMA读取响应消息的数目。这实际上意味着完成逻辑能够完成由消费者发布的那么多未决RDMA读取消息。从RNIC的观点来看，完成逻辑完成那么多的RDMA读取请求，并且仍然需要把该完成报告给消费者。
图3中表示了处理这些情况的总的方法。首先在步骤S1，检查Context[Ch#]::CompletedReadRequestsNum。如果该值不为0(步骤S2)，那么指示连接具有未决的读取请求完成。这种情况下，RNIC首先进行下面描述的“读取请求完成”操作，随后执行同样如下面描述的“Ack完成”(步骤S3和S4)，而不考虑Context[Ch#]::PendingCompletionRequest位。如果Context[Ch#]::CompletedReadRequestsNum等于0并且Context[Ch#]::PendingCompletionRequest位被设定(步骤S5)，那么RNIC进行同样如下面所述的Ack完成(步骤S4)。
Ack完成接收的TCP Ack完成向请求输出和响应输出信道16、18发布的RDMA请求。完成过程的主要挑战是遵循从响应输出和请求输出信道传送消息的顺序。为了保持该顺序，RNIC利用选择的消息的更新机构25更新消息描述符，以便携带消息的最后字节的序号(SN)。当RNIC传送消息的最后一段时，执行该更新过程(也称为“写回”)。RNIC使用MessageDescriptor::MessageLength字段来携带消息长度或序号。MessageDescriptor::SN/MsgLengthBit描述MessageDescriptor::MessageLength字段的内容。
RNIC不更新所有消息，而只更新在信道被交换(swap)后使用的那些消息，即在交换信道之后，只有第一个消息被更新。当传送RDMA消息时，RNIC交织请求输出和响应输出消息。RNIC在响应输出和请求输出信道间进行仲裁，并选择信道之一来传送下一消息。在传送的消息的中间，信道不被交换。当在信道间发生交换时，更新机构25用信道交换之后信道中下一消息的SN更新消息描述符。在交换之后，只对新信道中的第一消息更新消息描述符，相关的SN被更新为该消息的最后传送的字节的SN。如图2中所示，随后在完成和重传过程中，使用保存在MessageLength字段中的信息(MessageLength或者SequenceNumber)。
图4中表示了更新过程的一个例子。在该例子中，RNIC交换信道四次。它从请求输出信道中的消息#1开始，随后交换到响应输出信道(消息#2)，并用消息#2的最后字节的SN更新该消息。在消息#3之后，RNIC交换到消息#4的请求输出信道，RNIC更新消息#4。在消息#5之后，RNIC交换到消息#6的请求输出信道，RNIC更新消息#6。在消息#7之后，RNIC交换到消息#8的请求输出信道，RNIC更新消息#8。
只对利用两个信道的连接进行写回操作。如果连接只使用一个信道，那么不进行任何写回操作。
RNIC把几个序号保存在每个信道的连接上下文22中Context[Ch#]::ReqOutLastCompletedMsgSN，Context[Ch#]::ReqOutNextToCompleteMsgSN，Context[Ch#]::RespOutLastCompletedMsgSN，和Context[Ch#]::RespOutNextToCompleteMsgSN，它们分别携带每个信道中的最后完成的和第一个未完成的消息的序号(SN)。它们被初始化以携带初始的连接序号，并在完成操作中被更新。
Ack完成流程通过RNIC分别针对请求输出和响应输出信道循环经过一系列的步骤，实现完成流程。下面说明该过程。注意最后接收的ACK的序号在Context[Ch#]::LastAckedSN中指出。
下面参考图5的流程图概述各个步骤。
步骤1(S10)如果信道正在等待RDMA读取请求的完成(即，Context[Ch#]::PendingReadRequest被设定)，那么RNC忽略完成请求(S11)。注意该规则和响应输出信道不相关，因为响应输出信道只携带RDMA读取响应。
步骤2(S12)如果Context[Ch#]::NextToCompleteMsgSN无效，那么结束对该信道的完成请求的处理。这种情况发生在没有发布更多的消息或者下一发布的消息完全未被传送时。
步骤3(S13)如果Context[Ch#]::NextToCompleteMsgSN＞Context[Ch#]::LastAckedSN，那么接收的完成请求不完成该信道中的任何消息，并且针对该信道的完成请求的处理结束(S13)。
步骤4(S15)否则，完成请求完成该信道中的至少一个消息，RNIC如下更新连接上下文·Context[Ch#]::LastCompletedMsgSN由Context[Ch#]::NextToCompleteMsgSN更新；和·Context[Ch#]::NextToCompleteMsgSN由该信道中的下一消息的最后SN更新。可按照下述方式之一检索下一消息的最后SN(1)当MessageDescriptor::SN/MsgLengthBit指示MessageDescriptor::MessageLength/SN字段携带序号时，在MessageDescriptor::MessageLength/SN字段中明确地检索下一消息的最后SN；(2)利用MessageDescriptor∷MessageLength作为应用有效负载的大小，并增加协议报头、脚注和控制信息(DDP报头、标记、填充、CRC)，默示地检索下一消息的最后SN；和(3)当信道不具有下一传送的消息时，无效。这包括当没有发布任何消息时的情况，以及当消息已被发布但是未被完全传送时的情况。
注意如果完成的消息不是RDMA读取请求，那么RNIC执行RDMA操作的完成，其细节与本发明的主题无关。
就RDMA读取请求来说，RNIC等待RDMA读取响应以实现完成，并设定Context[Ch#]::PendingReadRequest位。
步骤5返回步骤1。
RDMA读取请求完成当收到涉及发布的RDMA请求的TCP Ack时，RNIC完成该请求。RDMA读取请求是当收到对应的RDMA读取响应时完成的例外情况。
RDMA排序规则要求按照RDMA请求被发送的顺序完成RDMA请求。这意味着在完成RDMA读取请求后的RDMA请求之前，RNIC需要等待接收RDMA读取响应。接收的RDMA读取响应的处理示于图6中的流程图中，并且包含下述步骤步骤1(S20)如有必要，执行在RDMA读取请求之前的RDMA请求的完成。
这是非常罕见的情况，并且当在收到RDMA读取响应之前，完成请求一直未被处理时发生这种情况。从而，RNIC需要首先完成在RDMA读取请求之前的所有请求。这种情况由非零的Context[Ch#]::PendingReadRequestsCount和清除的(clear)Context[Ch#]::PendingReadRequest位指出。
步骤2(S21)执行RDMA读取请求本身的完成。
RNIC执行RDMA读取操作的完成；其细节与本发明无关。
步骤3(S22)执行在完成的RDMA读取请求后的任意RDMA请求的完成。
上面在“Ack完成”部分中描述了该过程。
步骤4(S23)重复步骤2-3N次，其中N是由Context[Ch#]::CompletedReadRequestsNum定义的完成的RDMA读取请求的数目。
图7中也描述了这些过程的一个例子。
重传请求流程重传请求的处理涉及解决下述问题问题1RNIC需要处理该连接的所有未决的完成请求。于是，如果一个连接具有未决的完成请求，那么RNIC被请求处理该请求。只有在该连接的完成处理已结束之后，才恢复重传请求的处理。
问题2可归因于快速重传机构，或者归因于超时，请求重传。归因于超时的重传涉及所有传送的但是未完成的TCP段的重传。归因于快速重传机构的重传只涉及第一个未完成的TCP段的重传。RNIC使用不同的重传请求类型。重传请求的处理取决于下面说明的请求类型。
问题3重传请求处理的关键部分之一是请求输出或响应输出描述符列表中待重传的段的位置。下面描述了该过程。
重传不必保持传送的段的边界。应从其开始重传的位置由LastAckedSN指示。套接字和iSCSI对传送的段边界的变化不敏感。iSCSI假定TCP不提交对未传送的数据进行重传的请求。这允许iSCSI数据处理逻辑假定在重传期间，所有入站中间命令描述符携带在传送期间计算的有效iSCSI CRC。
RDMA保持传送的DDP段的边界，从而可从不同于LastAckedSN的位置开始重传。
重传请求类型如图8中所示，TCP发布三种重传请求(1)归因于快速重传的重传；(2)归因于超时的开始重传；以及(3)继续进行超时重传。
所有类型的重传请求涉及单个TCP段的重传。RNIC按请求输出和响应输出信道，利用NextToCompletion和NextToSend指针，保持完成的、等待完成的和等待传送的消息的边界。RNIC还保存每个连接的发布的但未传送的消息的数目(Context[Ch#]::TotalPostedMsgCount)和等待完成的传送消息的数目(Context[Ch#]::TotalPendingMsgCount)。注意，为每个连接保持Context[Ch#]::TotalPostedMsgCount和Context[Ch#]::Total PendingMsgCount，并且它们被用于响应输出和请求输出信道。在快速重传的情况下，RNIC只重传第一个未完成的段(即，在NextToComplete引用的消息内的TCP段)，而不更新上面提及的任何指针或计数器。如下所述选择开始重传的信道。
就归因于超时的开始重传来说，RNIC更新一个或两个信道的NextToSend指针，以便指向由NextToComplete(N2C)指向的消息内该信道中第一个未完成的TCP段，并从该位置开始重传单一的TCP段。Context[Ch#]::TotalPostedMsgCount和Context[Ch#]::TotalPendingMsgCount被分别更新。NextToSend(N2S)信道指针向前移动，以指向将在该信道中重传(或者传送)的下一段。就继续进行超时重传来说，RNIC从NextToSend指向的位置重传单一TCP段，并分别更新NextToSend和Context[Ch#]::TotalPendingMsgCount。注意，TCP并不请求未被传送的TCP数据的重传。
待重传段的定位通过使两个信道请求输出和响应输出保持传送的消息，实现待重传的TCP段的定位(location)。待重传段的定位由下面概述的几个步骤组成步骤1找出请求输出信道中的第一个未完成的消息。
在该步骤之后，每个信道(请求输出和响应输出)具有一个候选消息。只有当信道等待未决RDMA读取请求的完成(即Context[Ch#]::PendingReadRequest位被设定)时，该步骤才是相关的，因此该步骤只对请求输出信道相关。
这涉及和上面在“完成流程”部分中的计算选项的讨论中描述的信道消息过程的常规完成走查(walk-through)非常类似的过程。此过程的目标是找出具有超过Context[Ch#]::LastAckedSN的最后序号的消息。该消息可能携带待重传的段。如图9中所示，在例A中，该消息是消息#5，在例B中，该消息是消息#8。走查过程涉及消息的最后序号的计算。注意针对请求输出描述符的走查与由于如上所述的TCPAck的接收导致的针对常规完成操作描述的走查的一个重要差别。该差别是在归因于重传的走查中，RNIC忽略RDMA排序规则，把RDMA读取请求看作单向RDMA操作(例如，发送或RDMA写入)。这样做是因为目的在于到达未被TCP成功传送的第一个RDMA消息。
在上面针对归因于RDMA读取响应接收的完成的情况描述的图9的例子中，对于两个例子，常规的完成处理过程都会以ReqOut::NCSN＝100、ReqOut::LCSN＝0、ReqOut::NCSN＝600、ReqOut::LCSN＝300结束(注意RespOut已指向候选的WQE)。在这两个例子的ReqOut信道中，完成过程会停在第一个未决的RDMA读取请求(在这些例子中，它是第一个WQE#)上。这两个例子间的差别在于对于例A来说，最后接收的Ack的AckSN为450，对于例B来说则为550。这是重传操作的初始条件。重传操作以ReqOut信道中的走查开始。在例A中，RNIC走查WQE#1和WQE#4，并到达WQE#5，它以大于LastAckedSN(450)的SN(500)结束。在例B中，走查停在WQE#8。随后分别针对每个例子更新NCSN和LCSN。
注意，走查过程与具有未决的RDMA读取请求的请求输出信道相关。否则，在无读取请求的情况下，或者在响应输出信道的情况下，NextToComplete(N2C)总是指向候选消息。注意，在重传请求的执行前，必须针对两个信道执行常规完成，只是确保不存在未决的完成操作。
步骤2在两个候选消息(分别属于请求输出信道和响应输出信道)间选择带有待重传的段的消息。
为了选择拥有待重传段的消息，RNIC比较Context[Ch#]::ReqOutNextToCompleteMsgSN和Context[Ch#]::RespOutNextToCompleteMsgSN。较小的值属于拥有具有待重传的段的消息的信道。
图9证明了两个例子。在例A(ReqOut::NCSN＝500，RespOut::NCSN＝600)中，选择的消息属于请求输出信道，即，消息#5。在例B(ReqOut::NCSN＝800，RespOut::NCSN＝600)中，选择的消息属于响应输出信道，即消息#6。
步骤3找出属于从其开始重传的消息的数据缓冲区。
在消息选择之后，该步骤确定指向待重传段的起点的指针描述符的位置。为了找到指针描述符，RNIC需要计算消息的起始序号。注意，消息的起始SN可被用于帮助找出消息内的缓冲区偏移量，该偏移量可被用于找出从其开始重传的缓冲区。消息的最后序号已知，并被保存在连接上下文中(Context[Ch#]::ReqOutNextToCompleteMsgSN或Context[Ch#]::RespOutNextToCompleteMsgSN)。
为了计算消息的起始序号，RNIC比较Context[Ch#]::ReqOutLastCompletedMsgSN与Context[Ch#]::RespOutLastCompletedMsgSN。较大的值指示消息的起始序号，更准确地说，消息的起始序号等于max(Context[Ch#]::ReqOutLastCompletedMsgSN，Context[Ch#]::RespOutLastCompletedMsgSN)+1。
如图9中所示，在例A中，起始序号为401，在例B中，起始序号为501。一旦找到消息的起始序号，RNIC走查指针描述符，并寻找持有待重传段的起点的指针描述符。注意一般来说，LastAckedSN指示待重传段的起点。
这里描述的系统、功能、机构、方法、引擎和模块可用硬件、软件或硬件和软件的组合来实现。它们可由任意类型的计算机系统或者适合于执行这里描述的方法的其它设备来实现。硬件和软件的典型组合可以是具有计算机程序的通用计算机系统，当被加载和执行时，所述计算机程序控制计算机系统执行这里描述的方法。或者，可以利用包含用于执行本发明的一个或多个功能任务的专用硬件的专用计算机。本发明还可被嵌入计算机程序产品中，所述计算机程序产品包含能够实现这里描述的方法和功能的所有特征，并且当被装入计算机系统中时，能够执行这些方法和功能。本文中的计算机程序、软件程序、程序、程序产品或软件意味着一组指令的用任意语言、代码或符号表示的任意表述，所述一组指令意图使具有信息处理能力的系统直接地，或者在下述任一或下述二者之后执行特定的功能a)转换成另一种语言，代码或符号；b)用不同的材料形式再现。
上面出于举例说明的目的，给出了本发明的优选实施例的说明。优选实施例的上述说明不是穷尽的，也不打算把本发明局限于公开的明确形式，显然鉴于上述教导，许多修改和变化是可能的。对本领域的技术人员来说显而易见的这种修改和变化包括在由附加的权利要求限定的本发明的范围内。
权利要求
1.一种处理具有请求输出信道(16)和响应输出信道(18)的远程数据存储器存取(RDMA)环境中的完成过程的系统，包括每个信道的描述符列表(12、14)，其中每个描述符列表(12、14)包括信道中每个消息的消息描述符；每当在请求输出信道(16)和响应输出信道(18)间发生信道交换时，用消息中最后字节的序号更新消息描述符中的消息长度字段的更新机构(25)；检查完成上下文(22)中的值并比较下一要完成的消息的序号与最后确认的序号，以确定该消息是否应被完成的确认(Ack)完成系统；和执行读取请求的完成的读取请求完成系统。
2.按照权利要求1所述的系统，其中确认完成系统包括独立应用于请求输出信道(16)和响应输出信道(18)中每个的一系列重复的逻辑步骤。
3.按照权利要求2所述的系统，其中所述重复的逻辑步骤包括如果下一要完成的消息的序号无效，那么断定完成过程的处理结束；如果下一要完成的消息的序号大于最后确认的序号，那么断定完成过程的处理结束；和如果下一要完成的消息的序号小于或等于最后确认的序号，那么完成该信道中的信息。
4.按照权利要求3所述的系统，其中所述重复的逻辑步骤还包括下述步骤如果请求输出信道(16)正在等待读取请求的完成，那么终止请求输出信道(16)中的完成过程。
5.按照权利要求3所述的系统，其中完成信道中的消息的步骤还包括下述步骤用下一要完成的消息的序号更新最后完成的消息的序号；和用信道中的下一消息的最后序号更新下一要完成的消息的序号。
6.按照权利要求5所述的系统，其中完成信道中的消息的步骤还包括下述步骤如果完成的消息不是读取请求消息，那么执行操作的完成；如果消息是读取请求消息，那么在执行完成之前，等待读取响应的接收和传送以便执行完成，随后设定完成上下文中的未决的读取请求位。
7.按照权利要求2所述的系统，其中读取请求完成系统提供第二系列的逻辑步骤，所述第二系列的逻辑步骤包括完成在读取请求前的任何请求；完成该读取请求；和完成在该读取请求后的任何请求。
8.按照权利要求7所述的系统，其中第二组逻辑步骤中的最后两个步骤被重复N次，其中N是保存在完成上下文中的表示完成的读取请求的数目的值。
9.按照权利要求1所述的系统，还包括处理重传请求的系统，包括定位待重传的段的第三系列的逻辑步骤，其中所述第三系列的逻辑步骤包括执行完成操作，以确保没有未决的完成；识别请求输出信道(16)和响应输出信道(18)的候选消息；从这两个候选消息中选择携带待传送的段的消息；和确定指向待重传的段的起点的指针描述符的位置。
10.按照权利要求9所述的系统，其中如果请求输出信道(16)正在等待未决的读取请求的完成，那么请求输出信道(16)中的候选消息包含请求输出信道(16)中的第一个未完成的消息；其中如果请求输出信道(16)不是正在等待未决的读取请求的完成，那么请求输出信道(16)中的候选消息由下一要完成(N2C)指针给出；和其中响应输出信道(18)中的候选消息由下一要完成(N2C)指针给出。
11.按照权利要求9所述的系统，其中携带待传送的段的消息是驻留于具有下一要完成消息的最低序号的信道中的候选消息。
12.按照权利要求9所述的系统，其中指向待重传的段的起点的指针描述符的位置是下述序号中的最大值加1请求输出信道(16)中的最后完成的消息的序号；和响应输出信道(18)中的最后完成的消息的序号。
13.一种处理具有请求输出信道(16)和响应输出信道(18)的远程数据存储器存取(RDMA)环境中的完成过程的方法，包括利用下述步骤对每个信道执行确认完成如果下一要完成的消息的序号无效，那么断定完成过程的处理结束；如果下一要完成的消息的序号大于最后确认的序号，那么断定完成过程的处理结束；如果下一要完成的消息的序号小于或等于最后确认的序号，那么完成该信道中的信息；和如果请求输出信道(16)正在等待读取请求的完成，那么终止请求输出信道(16)中的完成过程。
14.按照权利要求13所述的方法，其中完成信道中的消息的步骤还包括下述步骤用下一要完成的消息的序号更新最后完成的消息的序号；和用信道中的下一消息的最后序号更新下一要完成的消息的序号。
15.按照权利要求14所述的方法，其中完成信道中的消息的步骤还包括下述步骤如果完成的消息不是读取请求消息，那么执行操作的完成；如果消息是读取请求消息，那么等待读取响应以便执行完成，并设定未决读取请求位。
16.按照权利要求13所述的方法，还包括读取请求完成方法，所述读取请求完成方法包括下述步骤完成在读取请求前的任何请求；完成该读取请求；完成在该读取请求后的任何请求；和重复上两个步骤N次，其中N是表示完成的读取请求的数目的值。
17.一种在具有请求输出信道(16)和响应输出信道(18)的远程数据存储器存取(RDMA)环境中，针对重传请求定位待重传的段的方法，包括执行完成操作；识别请求输出信道(16)和响应输出信道(18)的候选信息；从这两个候选信息中选择携带待传送的段的消息；和确定指向待重传的段的起点的指针描述符的位置。
18.按照权利要求17所述的方法，其中如果请求输出信道(16)正在等待未决的读取请求的完成，那么请求输出信道(16)中的候选消息包含请求输出信道(16)中的第一未完成的消息；其中如果请求输出信道(16)不是正在等待未决的读取请求的完成，那么请求输出信道(16)中的候选消息由下一要完成(N2C)指针给出；和其中响应输出信道(18)中的候选消息由下一要完成(N2C)指针给出。
19.按照权利要求18所述的方法，其中携带待传送的段的消息是驻留于具有下一要完成消息的最低序号的信道中的候选消息。
20.按照权利要求18所述的方法，其中指向待重传的段的起点的指针描述符的位置是下述序号中的最大值加1请求输出信道(16)中的最后完成的消息的序号；和响应输出信道(18)中的最后完成的消息的序号。
21.一种处理具有请求输出信道和响应输出信道的远程数据存储器存取(RDMA)环境中的传送过程的系统，包括每个信道的描述符列表(12、14)，其中每个描述符列表(12、14)包括信道中每个消息的消息描述符；和每当在请求输出信道(16)和响应输出信道(18)间发生信道交换时，用消息中的最后字节的序号更新消息描述符中的消息长度字段的更新机构(25)。
全文摘要
一种保持RDMA环境中的完成和重传操作的排序的系统和方法。提供一种处理具有请求输出信道(16)和响应输出信道(18)的远程数据存储器存取(RDMA)环境中的完成过程的系统，包括每个信道的描述符列表(12、14)，其中每个描述符列表(12、14)包括信道中的每个消息的消息描述符；每当在请求输出信道(16)和响应输出信道(18)间发生信道交换时，用消息中的最后字节的序号更新消息描述符中的消息长度字段的更新机构(25)；检查完成上下文(22)中的值并比较下一要完成的消息的序号与最后确认的序号，以确定该消息是否应被完成的确认(Ack)完成系统；和执行读取请求的完成的读取请求完成系统。
文档编号G06F9/46GK1890657SQ200480035688
公开日2007年1月3日 申请日期2004年12月2日 优先权日2003年12月2日
发明者吉奥拉·比拉恩, 佐里克·马储尔斯基, 瓦迪姆·马克瓦克斯 申请人:国际商业机器公司