CN100520758C - 提高tcp重发处理速度 - Google Patents

Abstract

一种RNIC实施，其执行向存储器的直接数据放置，其中具体连接的所有报文段都是对齐的，或是经重组缓冲器来转移数据，其中具体连接的所有报文都是非对齐的。没有接入重组缓冲器的切入直通的连接类型被称作为“快”连接，因为它最有可能是被对齐的，而另一种类型就被称作为“慢”连接。当消耗装置建立起连接时，它指定连接类型(S2)。这连接类型可从快变成为慢和在变回来。本发明减小了存储器带宽、延迟、利用TCP重发的错误恢复以及提供来自空接收队列的“降级恢复”。本实施还可在发送确认报文段接收的TCP确认(Ack)前以快连接来执行大部分进站DDP报文段的CRC验证(S11，S6)。

Description

提高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向用户提供RNIC 4，包括分配和解除分配RNIC 4资源的方法以及向RNIC 4发送工作请求(WR)208。动词接口7通常由动词库8来实施，该动词库具有两个部分：用于服务用户空间消耗装置的用户空间库9A以及服务内核空间消耗装置的内核模块9B。动词接口7是与RNIC 4硬件和固件一起工作的RNIC专用软件。对在动词接口7(动词库8)、硬件和固件中应该实施什么是没有严格定义的。动词接口7可以看作是向消耗装置提供RNIC4业务的一个独立数据包，因此消耗装置可执行主要两种类型的操作：对RNIC 4资源的管理(分配和解除分配)以及向RNIC 4发送工作请求(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)类型(即，对于发送WR 208S，它可以是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时，它会向RNIC 4通知(这里称作为“响门铃”)新的WQE216已经被分别添加到发送队列(SQ)/接收队列(RQ)。该“门铃响”操作通常是向RNIC存储空间执行写的操作，并由RNIC硬件来检测和解码。因此，门铃响通知RNIC对于指定的SQ/RQ，分别有新的工作要去做。

RNIC 4(图1A)保留具有未决的(被发送的)WQE 216的发送队列(SQ)210的列表。此外，RNIC在这些发送队列(SQ)210之间进行仲裁并且对它们进行相继地服务。当RNIC4选择发送队列(SQ)210来服务时，它读取下一个WQE 216来服务(WQE按照消耗装置发过来的顺序由RNIC进行处理)，并产生一个或是多个属于被请求的RDMA消息的DDP报文段220。

现在参考图1F-1H对处理具体类型的RDMA消息进行描述。如图1F所示，RNIC(请求方)选择要服务的具体发送队列(SQ)210S。它从发送队列(SQ)210S读取WQE 216S。如果该WQE216S对应于RDMA发送请求，则RNIC生成发送消息并将该消息发送到对等节点RNIC(响应方)。生成的消息可包括，例如，三个DDP报文段220。当RNIC(响应方)接收到发送消息，它从接收队列(RQ)212读取WQE216R，并将接收到的DDP报文段220的净荷放置到由WQE 216R表示的消耗装置的缓冲器(即，响应方Rx缓冲器)230。如果发送消息200是有序接收到的，那么RNIC从接收队列(RQ)212选取第一个未使用的WQE 216R。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是失序到达时，RNIC4可利用该消息的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添加相应的WQE 216W(图1G)或216R(图1H)，并通知RNIC4。当连接赢得仲裁时，RNIC16分别读取WQE 216W或216R，并生成RDMA写消息202或是RDMA读消息204。

如图1G所示，具体地针对RDMA写消息202而言，当RDMA写消息202被RNIC 4接收时，RNIC利用STag和TO(图1D)和DDP报文段报头(属于该消息)内的长度来寻找登记了的存储区232，并将RDMA写消息202的净荷放置到存储器232。接收方软件或CPU(即所示的响应方)不涉及该数据放置操作，并且不会意识到发生了该操作。

如图1H所示，具体地针对RDMA读消息204而言，当消息被RNIC4(图1A)接收时，RNIC生成RDMA读响应消息206，并将其发送回远端主机，即所示的请求方。在这种情况中，接收队列被称作为读队列214。生成RDMA读响应206的操作被执行而不涉及本地消耗装置(即响应方)，其也不会意识到发生了该操作。当RDMA读响应206被接收到时，RNIC4(图1A)对该消息的处理类似于处理RDMA写消息204。即，它在请求方侧写入到存储区232。

除了处理消耗装置的工作请求以外，RNIC 4(图1A)还通知消耗装置关于这些请求的完成，如图1F-1H所示。完成的通知是通过利用完成队列240来实现的，该完成队列是另一个RNIC资源并且是由消耗装置来分配的(经由动词库8提供的专用功能)。完成队列240包括完成队列元素(CQE)242。当CQE242在报告消耗装置工作请求(WR)208S、208W和208RR完成时，它就被RNIC 4(图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)，该接收到的TCP报文段由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过滤属于RNIC 16连接的数据传输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并被按顺序重组，即，Pkt1、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报文段由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.OutLogic

OutLogic40(图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包括WQE 216R。每个WQE216R保留描述由消耗装置发送的接收WR 208R的控制信息。每个WQE 216R也指向被发送到WR 208R内的消耗装置缓冲器。这些缓冲器是用来放置净荷的。因此，每个消息200消耗WQE 216R。

参照图11，示出表示类似图1H的RDMA读消息204和RDMA读响应206。然而根据本发明，读队列414作为特殊工作队列(WQ)提供，该特殊工作队列作为循环缓冲器实施，该循环缓冲器的每个输入是描述需要由发送逻辑产生的RDMA读响应的WQE 216RR。这就可以容易和有效的对失序的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读请求，WQE 216RR发送的操作包括两个步骤：将WQE 216RR放置到读队列414，和通告，即，门铃响，来通告RNIC16该WQE能被处理。对WQE 216RR的放置可以是失序的执行。然而，如上所指出的，WQE处理的起始(并且因此门铃响)必须要适应RDMA的排序规则。即，RDMA协议需要对进站的RDMA读消息204的处理进行延迟，直到所有先前发送的任意类型的RDMA消息都完成。因此，门铃响，即通告，应该被延迟到所有有序的先前的RDMA读消息204被完成。单独的门铃响，即通告，可表示几个WQE216RR的发送。

为了解决上述问题，根据本发明的RNIC16在连接上下文42(PendingReadResponseNum域300(图2B))中存储等待每个TCP洞130(图1B)的门铃响(通告)的发送的RDMA读响应WQE 216RR的数目。当TCP洞130被关闭时，RNIC16响门铃(通告)来确认PendingReadResponseNum WQE 216RR被发送到读队列214。这表示所有先前的读消息204都被完成，并且RNIC16可以开始处理发送的读响应WQE 216RR。

参照图13，RDMA发送消息500表现出一种独特的情况。具体地，发送完成的发送消息包括将CQE542放置到CQ540。CQE542携带描述完成的消息的信息(例如，长度、无效的STag等等)。该信息是消息指定信息，并且因此应该为每个未决的发送消息500保留。RNIC16不能在发送消息500完成前放置CQE542(类似于在接收到的读工作请求508R中放置RDMA读响应WQE 508RR)，因为如上所示CQ540可被几个发送510和接收512队列来共享。

为了解决该问题同时不消耗额外的RNIC资源，并且可提供可升级的实施，根据本发明的OutLogic40向由发送消息500所消耗的WQE516R放置需要被包含在CQE542中的所有信息。当接收到Poll-For-Completion请求时，该信息就重新由动词接口20从WQE516R中提取出。RNIC16需要保留在连接上下文42中每个洞130的完成发送信息500的数目(在CompletedSendsNum域302中)，其在当相应的TCP洞关闭时被用于向CQ540发送CQE 542。当TCP洞130关闭时，RNIC16将CQE 542放置到CQ540。要放置的CQE 542的数目等于为该洞所计数的完成的发送消息500的数目。当N是完成发送消息500的数目时，该方法涉及2N次的写操作。

上述提到的关于RDMA发送信息500的传送的方法的一个缺点是它将由RNIC16执行的写操作扩大了一倍。即，对于每个完成的发送消息500，都有一次写入到WQE 516R和一次CQE 542的写。为了解决该问题，如图14所示，根据本发明的一个可选实施方式，CQE542的内容变成携带由具体CQE542完成的WQE 516R的引用计数器544。引用计数器544被RNIC16初始化成为给定TCP洞130完成的发送消息500的数目。对于每一个Poll-For-Completion操作，动词接口20减小引用计数器544并且仅在该计数器变为零时从CQ540移去CQE542。此外，RNIC16仅在WQE 516S保留了大于门限(M)的等待完成的发送消息500时才对WQE 516S更新。M为可配置的参数，表示分配用于保存未决的进站发送消息500的信息的内部资源量。如果M等于零，则任意失序的接收到的发送消息500涉及WQE 516R的更新(对于有序的接收到的发送消息500是无需更新的)。

该实施方式还包括定义两类CQE 542，以及提供具有CQE542的指示器546，用来表示CQE是否在该CQE的主体中携带有所有完成数据，或是携带有部分完成的数据，该部分完成数据具有存储在与一个或是多个RDMA发送消息相关的WQE 516R中的剩余完成信息。该可选实施方式将写操作的数目减小至N+1，其中N是所完成的发送消息500的数目，它们在TCP洞130被关闭前是未决的。

IV.总结

在先前的讨论中，可以理解本方法步骤可通过专用计算机来优选实施，该专用计算机即有限状态机，包含用于执行一个或是多个本发明的功能任务的专用硬件。然而，本方法步骤也可由处理器来执行，例如CPU，执行存储于存储器中的程序产品的指令。可以理解此处描述的各种设备、模块、机制和系统可在硬件、软件、或是硬件和软件的结合中来实现，也可被不同于所示的那样进行划分。它们可以被任何类型的计算机系统或是其它适于执行这里所述方法的设备来执行。典型结合硬件和软件的是具有计算机程序的通用计算机系统，当被加载和运行时，计算机程序控制计算机使其执行这里所述的方法。本发明还可嵌入到计算机程序产品中，其包括所有能够实施这里所述方法和功能的特征，并且其在加载在计算机系统内时，能够执行这些方法和功能。在本上下文中的计算机程序、软件程序、程序、程序产品或是软件意味着任意的一组指令以不同的语言、代码或是符号的表达，该组指令旨在使得具有信息处理能力的系统来直接或是在下面步骤后执行具体地功能：(a)转换为另一种语言、代码或是符号；和/或(b)以不同的物质形式复制。

尽管本发明结合概括的具体实施方式进行了描述，但对于本领域技术人员来说许多的可选方式、改进方式和变形都是显而易见的。因此，本发明上述提出的实施方式旨在起示例性而不是限制性的作用。可以进行各种改变而不脱离本发明在后面权利要求中所定义的精神和范围。具体地，所述的步骤的顺序可在由不同组的步骤提供的某些环境或是功能中改变并且没有脱离本发明的范围。

工业实用性

本发明具有在数据传输领域内的工业实用性。

Claims (10)

1.一种提高传输控制协议重发处理速度的方法，该方法包括步骤：

生成涵盖接收到的传输控制协议报文段的第一重复传输控制协议确认，所述接收到的传输控制协议报文段由传输控制协议确定为有效并被传输控制协议基于上层协议判决来丢弃(S9)；以及

发送所述第一重复传输控制协议确认。

2.权利要求1所述的方法，其中所述上层协议包括至少一个以下标志：具有数据单元对齐协议的标志、具有直接数据放置协议的标志和具有远端直接存储器存取协议的标志。

3.权利要求1所述的方法，其中为传输控制协议报文段生成所述第一重复传输控制协议确认，而无论所述传输控制协议报文段是否失序或有序。

4.权利要求1所述的方法，其中所述第一重复传输控制协议确认甚至在下一个有序传输控制协议报文段还没有被接收到时也被生成。

5.权利要求1所述的方法，进一步包括生成涵盖下一个失序接收到的传输控制协议报文段的第二重复传输控制协议确认并且发送所述第二重复传输控制协议确认。

6.一种用于提高传输控制协议重发处理速度的系统，该系统包括：

传输控制协议确认发生器，其生成涵盖接收到的传输控制协议报文段的第一重复传输控制协议确认，所述接收到的传输控制协议报文段由传输控制协议确认为有效并且被传输控制协议基于上层协议判决而丢弃；以及

用于发送所述第一重复传输控制协议确认的装置。

7.权利要求6所述的系统，其中所述上层协议包括至少一个以下标志：具有数据单元对齐协议的标志、具有直接数据放置协议的标志和具有远端直接存储器存取协议的标志。

8.权利要求6所述的系统，其中所述发生器为传输控制协议报文段生成所述第一重复传输控制协议确认，而无论所述传输控制协议报文段是否失序或有序。

9.权利要求6所述的系统，其中所述发生器甚至在下一个有序传输控制协议报文段没有被接收到时也生成所述第一重复传输控制协议确认。

10.权利要求6所述的系统，进一步包括生成涵盖下一个失序接收到的传输控制协议报文段的第二重复传输控制协议确认的传输控制协议确认发生器和用于发送所述第二重复传输控制协议确认的装置。

Images