专利名称：降低与失序rdma发送消息的传送相关的写操作的数量的制作方法
技术领域：
本发明一般涉及数据传送，尤其涉及一种具有用于对齐DDP分段的直通转发(cut-through)实现的、支持RDMA的网络接口控制器(RNIC)。
背景技术：
1.概述参考图1A，其中示出了常规数据传送环境1的模块图。数据传送环境1包括数据源2(即，对等方)，其通过一个或多个支持远程存储器数据访问(RDMA)的网络接口控制器(RNIC)4将数据传送3A发送到接收数据传送3B的数据宿5(即，对等方)。NIC4包括重新装配缓冲器6等等(下面进一步说明)。近来，联网通信速度已经从10兆位/秒(Mbps)至100Mbps显著提高到1吉位/秒(Gbps)，并且现在正接近10Gbps左右的速度。然而，通信带宽增加现在正开始超过中央处理单元(CPU)高效处理数据所能承受的速率，从而导致例如RNIC4的服务器处理器处的瓶颈。例如，如果得到完全利用，普通的1Gbps网络连接对2GHzCPU将是一个大负担。具体地说，诸如此类的CPU能够将其处理能力的大约一半仅用于进行源于来自网卡的数据的低层传输控制协议(TCP)处理。
解决这个问题的一个方案是在硬件有限状态机(FSM)中实现传送控制和网际协议(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)接入；网际协议(IP)102添加必要的网络路由信息；传送控制协议(TCP)104调度出站TCP分段106，并且满足送达保证；并且标记与协议数据单元(PDU)对齐(MPA)的协议108提供MPA帧109，该帧在跨越DDP分段112(仅仅示出了一个，但是可以是流)的固定间隔(即，每512字节)处包括反向MPA标记110，并且还向每个MPA帧109添加长度字段114和循环冗余校验(CRC)字段116。另外，直接数据放置(DDP)协议120将出站消息分成一个或多个DDP分段112，并且将一个或多个DDP分段重新装配成DDP消息113；并且远程数据存储器访问(RDMA)协议122将RDMA写、读、发送转换成DDP消息或进行相反转换。虽然为了清楚起见仅示出了一个DDP分段112，但是应当认识到，在每个TCP分段106中可以提供许多DDP分段112。
尤其是对于RDMA协议122，这个由RDMA联盟开发的协议通过允许一个计算机以对存储器总线带宽和中央处理单元(CPU)处理开销的最小要求将信息直接放置在另一个计算机的存储器中，同时保持存储器保护语义，使得能够消除数据复制操作和减少等待时间。基于TCP/IP的RDMA通过减轻处理器和存储器的开销负担来保证数据中心内更高效和可伸缩的计算和数据传送，这使得处理器资源可用于其它工作，例如用户应用程序，并且改善基础设施利用率。在这种情形下，与更大、更昂贵的系统中的集中化工作相反，随着网络变得更高效，应用通过跨网络分担任务而更加能够进行伸缩。通过RDMA功能，发送方可以使用成帧处理在以太网字节流上放置报头，使得在接收方处可以更容易地在失序模式中解码和执行这些字节流，这将大大提高性能-尤其是对于因特网小型计算机系统接口(iSCSI)和其它存储业务类型。由RDMA提供的另一个优点是能够通过较少类型的互连将功能聚集到数据中心中。通过在较少互连上聚集功能，所得到的基础设施复杂度更低，更易于管理，并且提供体系结构冗余的机会，这改善系统弹性。
尤其是对于DDP协议，该协议引入了可以用来将数据直接放置到高层协议(ULP)接收缓冲器中而无需中间缓冲器的机制。DDP减少并且在某些情形下消除了在处理入站TCP分段时由支持RDMA的网络接口控制器(RNIC)执行的附加复制(去往和来自重新装配缓冲器)。
3.挑战在硬件设置中对RDMA和DDP高效实现TCP/IP时所面临的一个挑战是标准TCP/IP减负引擎(TOE)实现在接收逻辑中包括重新装配缓冲器，以安排失序接收的TCP流，这增加了复制操作。另外，为了完成对接收方数据缓冲器的直接数据放置，RNIC必须能够为每个到达TCP分段有效负载127找到目的缓冲器。结果，将所有TCP分段保存到重新装配缓冲器中，以确保它们是按顺序的，并且可以找到目的缓冲器。为了解决该问题，iWARP规范强烈建议发送方RNIC以使得所创建的DDP分段与TCP分段“对齐”的方式执行RDMA消息的分段。但是，非对齐DDP分段有时是不可避免的，尤其是在数据传送经过许多交换的情形下。
参考图1B，“对齐”是指DDP分段112紧接在TCP报头126之后(即，MPA报头跟随TCP报头，然后是DDP报头)，并且DDP分段112完全包含在这一个TCP分段106中。更具体地说，每个TCP分段106包括TCP报头126和TCP有效负载/TCP数据127。“TCP洞”130是TCP数据流中丢失的TCP分段。MPA标记110用于在接收失序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处理相关的另一个挑战是由这样的事实产生的，即时常难以确定什么原因正导致非对齐。例如，可以在两个或更多个TCP分段106之间分割单个非对齐DDP分段112NA，并且它们中的一个可能到达，而另一个可能未到达。在另一种情形下，一些DDP分段112NA可能落在MPA标记110之间，报头可能丢失，或者分段尾可能丢失(在后者情形下，可以部分地放置分段，并且需要保存一些信息以了解当其余部分到达时在何处放置)，等等。针对该后一种情形，图1C示出了与一个或多个非对齐DDP分段112NA的MPA标记参考有关的可能情形的模块图。情形A示出了新接收的DDP分段162的DDP分段报头160由先前处理的DDP分段166的MPA长度字段164引用的情形。情形B示出了新接收的DDP分段162报头160由位于新接收的DDP分段162内的标记168引用的情形。也就是，标记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，动词接口7向消费方提供RNIC4，并且包括用于分配和释放RNIC 4资源，以及将工作请求(WR)208投递到RNIC4的方法。动词接口7通常由动词库8实现，动词库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。另外，存在可以构成消费方不直接与其交互、例如读队列214(图1H)和工作队列单元(WQE)216的QP的资源。
可以由WQE216保存的典型信息是消费方工作请求(WR)类型(即，对于发送WR208S，它可以是RDMA发送、RDMA写、RDMA读等，对于接收WR208R，它可以仅仅是RDMA接收)，以及携带要发送的数据或者表示用于所接收数据的位置的消费方缓冲器的描述。WQE216总是描述/对应于单个RDMA消息。例如，当消费方投递RDMA写类型的发送工作请求(WR)208S时，动词库8(图1A)构建WQE216S，其描述需要从中取得数据并且使用RDMA写消息发送到响应方的消费方缓冲器。在另一个例子中，提供接收工作请求(WR)208R(图1F)。在这种情形下，动词库8(图1A)将WQE216R添加到接收队列(RQ)212，其拥有将用于放置所接收的发送消息200的有效负载的消费方缓冲器。
当动词库8(图1A)将新WQE216添加到发送队列(SQ)210或接收队列(RQ)212时，它向RNIC4(图1A)通知(这里被称作“使门铃响铃”)已经将新WQE216分别添加到发送队列(SQ)/接收队列(RQ)。该“门铃响铃”操作通常是由RNIC硬件检测和解码的针对RNIC存储器空间的写入。相应地，门铃响铃向RNIC通知存在需要分别针对指定SQ/RQ完成的新工作。
RNIC4(图1A)拥有具有待处理(已投递)WQE216的发送队列(SQ)210的列表。另外，RNIC在这些发送队列(SQ)210之间进行仲裁，并且轮流服务于它们。当RNIC4提取要服务的发送队列(SQ)210时，它读取要服务的下一个WQE216(按照消费方投递WQE的顺序由RNIC处理WQE)，并且生成属于所请求的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引用的消费方缓冲器(即，响应方接收缓冲器)230中。如果按顺序地接收发送消息200，则RNIC从接收队列(RQ)212提取第一个未用WQE216R。WQE216R按照消费方投递它们的顺序在请求队列(RQ)212中链接起来。就无标签DDP消息而言，发送消息200携带消息序列号(MSN)(图1E)，其被初始化为一，并且由发送方单调增加，其中每个发送的DDP消息220属于相同DDP队列。(下面将针对RDMA写消息202描述带标签消息)。DDP队列由DDP报头中的队列号(QN)(图1E)标识。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中的响应方中钉扎(pinned)存储器的虚拟连续块。存储器区232由其起始虚拟地址(VA)、长度、访问权限以及与该存储器区232相关联的物理页列表来描述。作为存储器区232注册的结果，消费方接收回可以用来访问该注册存储器区232的指引标签(STag)。通过RNIC4执行远程消费方(例如，图1G中的请求方)对存储器区232的访问，而无需任何与本地消费方(例如，图1G中的响应方)的交互。当消费方想要访问远程存储器232时，它分别投递RDMA写或RDMA读类型的发送工作请求(WR)208W或208R(图1H)。动词库8(图1A)分别将对应的WQE216W(图1G)或216R(图1H)添加到发送队列(SQ)210W或210R中，并且向RNIC4通知。当连接赢得仲裁时，RNIC16分别读取WQE216W或216R，并且生成RDMA写消息202或RDMA读消息204。
尤其是对于RDMA写消息202，如图1G所示，当RNIC4接收到RDMA写消息202时，该RNIC使用DDP分段(属于该消息)的报头中的STag和TO(图1D)和长度，来查找注册存储器区232，并且将RDMA写消息202的有效负载放置到存储器232中。数据放置操作不涉及接收方软件或CPU(即，如图所示的响应方)，并且其不知道该操作发生。
尤其是对于RDMA读消息204，如图1H所示，当RNIC4(图1A)接收到该消息时，该RNIC生成RDMA读响应消息206，并且将它发送回到远程主机，即如图所示的请求方。在这种情形下，接收队列被称作读队列214。还执行RDMA读响应206的生成，而不涉及不知道该操作发生的本地消费方(即响应方)。当接收到RDMA读响应206时，RNIC4(图1A)与RDMA写消息204的处理相类似地处理该消息。也就是，它对请求方一侧的存储器区232进行写入。
除了处理消费方工作请求之外，RNIC4(图1A)还向消费方通知这些请求的完成，如图1F-1H所示。通过使用完成队列240，即由消费方分配(通过由动词库8提供的专用函数)的另一个RNIC资源来进行完成通知。完成队列240包括完成队列单元(CQE)242。CQE242被RNIC4在它报告消费方工作请求(WR)208S、208W、208RR的完成时放置到完成队列(CQ)240中。每个工作队列(即，发送队列(SQ)210、接收队列(RQ)212)具有相关联的完成队列(CQ)240。(注意读队列214是通过硬件维护的内部队列，并且对软件不可见。因此，没有CQ240与该队列相关联，并且消费方既不分配该队列也不知道其存在)。然而，应当注意，相同完成队列(CQ)240可以与多于一个的发送队列(SQ)210和接收队列(RQ)212相关联。在队列对(QP)分配时执行关联。在工作时，当消费方将工作请求WR208投递到发送队列(SQ)210时，它可以指定其是否想要在完成该请求时得到通知。如果消费方请求了完成通知，则RNIC4在完成工作请求(WR)时将完成队列单元(CQE)242放置到与发送队列(SQ)210相关联的相关完成队列(CQ)240中。RDMA协议针对被投递到发送队列(SQ)210的工作请求(WR)208定义非常简单的完成定序。具体地说，RDMA发送工作请求(WR)208S和RDMA写工作请求(WR)208W在它们已被可靠发送时完成。RDMA读工作请求(WR)208R在对应的RDMA读响应消息206已被接收并且被放置到存储器区232中时完成。消费方工作请求(WR)按照将它们投递到发送队列(SQ)210的顺序完成。参考图1F，被投递到接收队列(RQ)212的每个工作请求(WR)也需要完成通知。因此，当RNIC4(图1A)完成所接收的发送消息200的放置时，它将完成队列单元(CQE)242放置到与该接收队列(RQ)212相关联的完成队列(CQ)240中。
鉴于以上情况，本技术领域需要一种方法来以不同于处理非对齐DDP分段的放置和送达的方式处理对齐DDP分段的放置和送达。
发明内容
本发明包括RNIC实现，其在特定连接的所有接收DDP分段均对齐的情形下执行向存储器的直接数据放置，或者在特定连接的一些DDP分段是非对齐的情形下移动数据经过重新装配缓冲器。直通转发而不访问重新装配缓冲器的连接的类型被称作“快速”连接，而另一类型被称作“慢速”连接。当消费方建立连接时，它指定连接类型。例如，将经过因特网到另一个洲的连接以对齐分段到达目的地的可能性很低，因此应当由消费方将其指定为“慢速”连接类型。另一方面，连接存储区域网(SAN)中两个服务器的连接使所有DDP分段对齐的可能性很高，因此由消费方将其指定为“快速”连接类型。连接类型可以从快速变到慢速，反之亦然。本发明减少了存储器带宽、等待时间、使用TCP重新发送的差错恢复，并且规定自空接收队列的“适度恢复”，即接收队列不具有针对入站无标签DDP分段的已投递工作队列单元(WQE)的情形。常规的实现将以连接终止结束。相反，根据本发明的快速连接将丢弃这样的分段，并且使用TCP重新发送处理来从该情形中恢复，并且避免连接终止。该实现还可以在发送用于确认分段接收的TCP确认(Ack)之前，对快速连接中的大部分入站DDP分段进行循环冗余校验(CRC)验证。这允许使用TCP可靠服务从通过CRC校验检测出的数据损坏中有效恢复。
本发明的第一方面涉及一种用于减少与失序RDMA发送消息的传送相关的写操作的数量的方法，该方法包括步骤为参考计数器提供完成队列单元(CQE)；将参考计数器设置为针对选定TCP洞完成的RDMA发送消息的数量；针对RDMA动词接口执行的每次完成轮询将参考计数器减一；和在计数器变为零的情况下从相应完成队列(CQ)中清除该CQE。
本发明的第二方面涉及一种用于减少与失序RDMA发送消息的传送相关的写操作的数量的系统，该系统包括用于将完成队列单元(CQE)的参考计数器设置为针对选定TCP洞完成的RDMA发送消息的数量的装置；用于针对RDMA动词接口执行的每次完成轮询将参考计数器减一的装置；和用于在计数器变为零的情况下从相应完成队列(CQ)中清除该CQE的装置。
本发明的第三方面涉及一种包括计算机可使用介质的计算机程序产品，该介质具有在其中体现的用于减少与失序RDMA发送消息的传送相关的写操作的数量的计算机可读程序代码，该程序产品包括用于将与完成队列单元(CQE)相关的参考计数器设置为针对选定TCP洞完成的RDMA发送消息的数量的程序代码；用于针对RDMA动词接口执行的每次完成轮询将参考计数器减一的程序代码；和用于在计数器变为零的情况下从相应完成队列(CQ)中清除该CQE的程序代码。
根据下面对本发明实施例的更具体描述，本发明的前述和其它特征将会变得清楚。
将参考下列附图详细描述本发明的实施例，其中相同的附图标记表示相同的单元，并且其中图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的RNIC的验证单元的模块图；图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，将数据传送14A发送到数据宿18(即，对等方)，其接收数据传送14B。出于说明的目的，这里将发起数据传送的实体称为“请求方”，并且将对数据传送作出响应的实体称为“响应方”。类似地，发送数据的实体这里将被称为“发送方”，并且接收数据传送的实体这里将被称为“接收方”。应当认识到，数据源12和数据宿18中的每个在不同的时候可以是数据的发送方或接收方，或者是请求方或响应方，而且仅仅是为了最初表示拥有要传送的数据的实体的目的而提供标记“源”和“宿”。在更具体的标记没有必要的情形下，下面的描述还可以将上面实体中的一个称为“消费方”(因为其使用RNIC16资源)。“目的缓冲器”应当是指在接收方处最终接收数据的数据存储设备，即数据源12或数据宿18的数据缓冲器50。数据源12和数据宿18均包括用于存储数据的数据缓冲器50。
就硬件而言，RNIC16是任何具有iWARP和动词功能的网络接口控制器，例如网络I/O适配器或者嵌入式控制器。RNIC16还包括动词接口20、访问控制30、RNIC输入逻辑(此后称为“InLogic”)32、重新装配缓冲器34、内部数据缓冲器38、RNIC输出逻辑(此后称为“OutLogic”)40、连接上下文42、验证单元44以及其它部件46。动词接口20是通过RNIC16硬件和RNIC驱动程序(未示出)的组合来实现以执行操作的、对消费方而言的RNIC16的表示。动词接口20包括动词库22，其具有两个部分用户空间库24和内核模块26。访问控制30可以包括任何现在公知的或以后开发的、用于控制对InLogic32的访问的逻辑。重新装配缓冲器34可以包括用于临时存储与数据传送14A、14B相关的数据的任何机构。具体地说，如下面将要更详细描述的那样，重新装配缓冲器34通常用于失序TCP流的临时存储。其它部件46可以包括RNIC16的操作所需的任何其它逻辑、硬件、软件等，但是这里没有另外描述。
参考图2B，连接上下文42包括若干字段，用于存储特定于连接的数据。其它上下文数据60提供这里未作另外说明但是本领域的普通技术人员可认识到的特定于连接的数据。根据本发明，定义了两个连接类型快速(此后称为“快速”)连接和慢速(此后称为“慢速”)连接。术语“快速”和“慢速”是指送达对齐DDP分段的连接可能性。连接类型在被称作连接类型62的连接上下文字段中标识。如下面将要更详细描述的那样，慢速连接可以用于作为慢速连接而被创建、或者在入站数据的处理期间被RNIC16降级的RDMA连接。图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)计算MPACRC，并且将快速连接数据流与慢速连接数据流相分离。对于后者的功能，如下面将要更全面描述的那样，InLogic32将慢速连接上由RNIC16接收的所有数据指引到重新装配缓冲器34，并且以若干不同方式处理快速连接。对于快速连接，如果InLogic32检测到对齐违例(即，紧接在TCP报头之后的不是DDP报头，以及DDP分段没有完全包含在一个TCP分段中)，则将连接降级到慢速连接，并且将数据指引到重新装配缓冲器34。相反，如果不存在对齐违例，则InLogic32将对齐入站DDP流指引到内部数据缓冲器38，然后到OutLogic40，以便直接放置到目的数据缓冲器50中。可选地，可以丢弃TCP分段106，并且不发送确认(Ack)，因此使得必须进行该分段的重新传送。
OutLogic40在快速和慢速连接之间进行仲裁，并且执行两种连接类型流到数据宿18数据缓冲器50的数据放置。快速连接上的对齐DDP分段被指引到内部数据缓冲器38以便直接放置到目的缓冲器中的情形被称作“直通转发模式”，这是因为具有对齐DDP分段的快速连接由OutLogic40直接放置，从而绕过重新装配缓冲器34。然而，对于两种连接类型，只有按顺序接收的数据流才通过OutLogic40送达到数据宿18。
II.InLogic参考图3，将更详细地描述根据本发明的InLogic32(图2A)及其数据传送14A的处理的流程图。如上所述，InLogic32处理入站TCP分段，执行接收分段的TCP验证，计算MPA CRC，并且将快速连接数据流与慢速连接数据流相分离。除非另外指明，否则后面不跟有“S”的附图标记是指图2A-2C所示的结构。
在第一步骤S1，InLogic32过滤属于RNIC16连接的数据传送14A的TCP分段106，并且获得具有针对接收分段计算的CRC验证(通过验证单元44)结果的分组。(注意，CRC验证应当在InLogic32判定处理之前进行。CRC验证也可以在TCP分段106被识别为属于快速连接-步骤S2之前，与TCP校验和计算同时进行。)在步骤S2，InLogic32确定TCP分段106是否属于慢速连接。在这种情形下，InLogic32确定发送方如何标记连接。如果是，则在步骤S3将TCP分段106指引到重新装配缓冲器34，并且TCP逻辑将该分段认为是成功接收的。
如果否，则在步骤S4，InLogic32继续确定TCP分段106长度是否大于所声明的MPA分段长度。也就是，在TCP报头126中声明的TCP分段106长度是否长于在MPA长度字段114中声明的MPA长度。如果是，这表示TCP分段106包括多个DDP分段112，下面将描述其处理。如果否，这表示TCP分段106包括单个DDP分段112或112NA。
在该后者情形下，在步骤S5，InLogic32确定MPA长度是否大于TCP分段106长度。如果是，这表示以下三种情形之一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，因此在步骤S3应当将连接降级到慢速连接。第三种情形(3)不要求连接降级。然而，由于不能识别和确认MPA帧109长度超过TCP分段106长度的原因，因此丢弃(即，取消和不传送)这样的TCP分段106是不可取的，因为它可能引起死锁(上述情形2)。也就是，如果这样的TCP分段实际上携带非对齐DDP分段，则发送方将重新发送相同的非对齐DDP分段，遵循相同的流程，其将被接收方反复地丢弃，从而引起死锁。相应地，在步骤S3，InLogic32将TCP分段106的数据传送指引到重新装配缓冲器34，调度Ack以确认TCP分段106被成功接收，并且将连接降级到慢速连接(即，图2B中的连接类型字段62从快速转变到慢速)。如下所述，如果MPA长度字段114被损坏(上述情形3)，此情形由OutLogic40检测，并且连接由于验证单元44检测到的CRC错误而将被关闭。因此，在步骤S3，连接降级不会导致快速连接由于对齐DDP分段112中的数据损坏而永久性地变成慢速连接。
回到步骤S5，如果MPA长度不大于TCP长度，即否，则表示MPA帧109长度匹配(等于)TCP分段106长度。在步骤S6，InLogic32继续针对该TCP分段106确定CRC验证结果是否有效。也就是，CRC逻辑64是否返回“有效”指示。如果是，这表示单个DDP分段112完全适合TCP分段106边界(即，长度彼此相等)，并且针对该分段，没有检测到数据损坏。结果，在步骤S7，通过将所接收的TCP分段106放置到RNIC16的内部数据缓冲器38中以便由OutLogic40处理，在“快速路径模式”中处理单个DDP分段112，这将所接收的TCP分段106直接放置到例如数据宿18的接收方的目的数据缓冲器50中。另外，调度Ack以确认该TCP分段106的成功接收。
如果CRC逻辑64返回“无效”指示，即在步骤S6为否，这表示存在可以根据本发明确定的五种可能情形之一。图1C示出了这五种可能情形，并且步骤S8-S10说明了InLogic32如何处理每种情形。在任何情形下，处理的目的是1)即使在这些连接由发送方声明为快速连接的情况下，避免非对齐连接的终止；2)降低由于属于快速连接的对齐DDP分段中的数据损坏而导致的连接终止的可能性；以及3)保持InLogic32尽可能地简单，同时把要被单独处理的情形的数目减至最小。
在步骤S8，如图1C中的情形A所示，InLogic32确定新接收的DDP分段162的DDP分段报头160是否被先前处理的DDP分段166的MPA长度字段164引用。在这种情形下，在新接收的DDP分段162的MPA CRC的验证期间检查先前处理的DDP分段166的MPA长度，因此它引用下一分段中的DDP报头160的正确位置。在步骤S6，情形A的CRC无效意味着单个DDP分段162数据或报头160已被损坏。新接收的分段162的TCP重新发送解决这一问题。相应地，在步骤S9，丢弃TCP分段106，并且认为分段接收未被确认。
如果新接收的DDP分段162报头160没有被先前处理的DDP分段166的MPA长度字段164引用(即，在步骤S8为否)，则在步骤S10，如图1C中的情形B所示，InLogic32继续确定新接收的DDP分段162报头160报头160是否被位于新接收的DDP分段162内部的标记168引用。也就是，标记168正指向新接收的DDP分段162的开始处。在这种情形下，在步骤S6，CRC无效以下任一情形1)标记168携带正确值，并且新接收的DDP分段162具有损坏的DDP报头160或数据，或者2)新接收的DDP分段162内部的标记168已被损坏。在这两种情形下，新接收的DDP分段162的重新发送解决这一问题。相应地，在步骤S9，丢弃TCP分段，并且不确认分段接收。
如果新接收的DDP分段162报头160没有被位于新接收的DDP分段162内部的标记168引用，即在步骤S10为否，则存在如下三种情形之一。第一，如图1C中的情形C所示，标记168位于新接收的DDP分段162中，但是指向该分段的外部。第二，如图1C中的情形D所示，标记168位于新接收的DDP分段162中，但是指向该分段的内部。第三，如图1C中的情形E所示，没有标记位于新接收的DDP分段162中。
在情形C、D和E中，CRC逻辑64返回无效指示的原因是不确定的，并且可以是数据损坏和/或非对齐DDP分段112NA(图1B)的接收的结果。在非对齐DDP分段112NA的情形下，这样的分段的无限制重新发送可能引起死锁。为了避免潜在的死锁，InLogic32通过如步骤S3所示将新接收的DDP分段162指引到重新装配缓冲器34，来调度Ack以确认该分段的成功接收，并且将连接降级到慢速连接，从而处理情形C、D和E。如果CRC逻辑64返回无效指示是由于对齐DDP分段112中的数据损坏，则如下所述，该错误将由OutLogic40在处理慢速连接的数据时检测到，并且将终止连接。另外，连接将永远保持慢速连接。然而，如下所述，有限重新发送尝试模式可以避免这一问题。
返回到图3的步骤S4，如果InLogic32确定TCP分段106长度大于MPA帧109长度，这表示TCP分段106包括多个DDP分段112。在这种情形下，在步骤S11，从第一到最后DDP分段112进行CRC逻辑64验证结果的顺序检查。如果所有DDP分段112具有有效CRC，即步骤S11的结果为是，则所有DDP分段112都完全包含在TCP分段106中，并且全部是有效、正确对齐的DDP分段112。在这种情形下，在步骤S7，InLogic32通过将所接收的TCP分段106放置到RNIC16的内部数据缓冲器38中以便由OutLogic40处理，从而在快速路径模式上处理DDP分段112，这将所接收的TCP分段106放置到目的数据缓冲器，例如数据宿18的数据缓冲器50中。另外，调度Ack以确认该TCP分段106的成功接收。InLogic32在检测到第一故障时停止检查CRC验证结果，其管理将结合步骤S12-S13加以说明。
在步骤S12，InLogic32确定第一DDP分段112是否如CRC逻辑64所确定的那样具有无效CRC。如果是，则InLogic32类似于单个DDP分段的无效CRC情形地处理第一DDP分段112(步骤S8)。也就是，InLogic32将具有无效CRC的第一DDP分段112当作单个DDP分段112，并且继续确定是什么导致了CRC无效，即图1C的情形A-E中的哪个适用，并且如何适当地处理该情形。
如果步骤S12的结果为否，即第一DDP分段112具有有效CRC，则InLogic32在步骤S13继续确定在校验中间或最后DDP分段112时是否检测到CRC无效。如果是，则InLogic32(图1)前进到步骤S9，因为该错误表示导致CRC无效的DDP分段112的数据或报头已被损坏(即，先前的具有有效CRC的DDP分段的长度)。也就是，在相同TCP分段106中的中间或最后DDP分段112上检测到CRC错误，这意味着先前DDP分段具有有效CRC，因此先前DDP分段的长度指向具有无效CRC的分段的报头。这与情形A(图1C)的描述相符。因此，如情形A所述，报头的位置是已知的，因此可知，CRC错误是由于数据或报头损坏而导致的。相应地，整个TCP分段的重新发送应当解决这一问题，而没有任何出现死锁情形的风险。在步骤S9，丢弃TCP分段，并且不确认分段接收。
如果步骤S13的结果为否，即中间或最后DDP分段112没有导致CRC无效，则这表示最后DDP分段112的MPA长度字段114超过TCP分段106边界，即最后DDP分段在TCP分段106边界之外或太长。在这种情形下，InLogic32将该情形等同于太长的单个DDP分段112来对待。具体地说，在步骤S3，InLogic32继续将TCP分段106的数据传送14A指引到重新装配缓冲器34，调度Ack以确认TCP分段106被成功接收，并且将连接降级到慢速连接。这样，避免了死锁。如果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的结果为否是可以导致这样的情形的一个说明性确定)的原因的不确定性相关的可选实施例，可以实现“有限重新发送尝试模式”，以限制重新发送尝试的次数，从而避免死锁并且减少不必要地降至慢速连接的快速连接的数目。具体地说，如上所述，情形C、D和E表示若干情形，其中，由于所检测错误的原因的不确定性，连接可能被降级到慢速连接(步骤S3)，其中在错误是由于数据损坏而非失去DDP分段112对齐而导致时，(由OutLogic40)进行潜在的连接终止。
为了限制重新发送尝试次数，本发明对连接上下文42(图2B)提供了附加字段，以允许在降级连接之前特定次数的重新发送。具体地说，如图2B所示，连接上下文42包括一组字段290，其包括恢复尝试次数字段(RecoveryAttemptsNum)292、最后恢复序列号字段(LastRecoverySN)294、以及最大恢复尝试次数字段(MaxRecoveryAttemptsNum)296。RecoveryAttemptsNum字段292维护自从最后更新以来对于连接进行的恢复尝试的次数；LastRecoverySN字段294维护最后发起的恢复操作的序列号(SN)；以及MaxRecoveryAttemptsNum字段296定义在降级连接之前应当由InLogic32执行的恢复尝试的最大次数。
参考图4A，在操作中，当InLogic32检测到新的按顺序接收的数据传送包含错误(被一般性地示出为图4A中的步骤S101)，InLogic32不是将连接立即降级到慢速连接(在图3中的步骤S3)，而是规定对该包含错误的数据传送进行特定次数的重新发送。应当认识到，步骤S101对于由于非对齐DDP分段112NA或数据损坏而导致的若干错误确定是普适的(例如对于图3的步骤S5的是或者图3的步骤S10的否，步骤S101可以适用)。在步骤S102，InLogic继续通过将RecoveryAttemptsNum加一(1)来记录针对该包含错误的数据传送的该传送尝试。另外，InLogic更新LastRecoverySN，以存储先前存储在其中的序列号和新接收(但是被丢弃)的数据传送的序列号当中的最大序列号。也就是，InLogic更新LastRecoverySN以存储指示至少一个先前接收的包含错误的数据传送和新接收的包含错误(但是被丢弃)的数据传送当中的最大序列号。通过将新接收的包含错误的数据传送的序列号与所存储的最大序列号进行比较，确定新接收的包含错误的数据传送具有大于最大序列号的序列号。LastRecoverySN记录的意义在下面将会变得清楚。
接下来，在步骤S103，InLogic32确定RecoveryAttemptsNum(字段292)是否超过MaxRecoveryAttemptsNum(字段296)。如果为否，则在步骤S104，InLogic32丢弃TCP分段106，并且不确认成功接收，这将导致TCP分段的重新发送。然后，处理返回到步骤S1(图3)。如果TCP分段106被损坏，则重新发送应当补救该损坏，使得数据传送14A作为快速连接被直接放置到存储器中(在图3的步骤S7)。可选地，如果处理继续返回其它错误检测(例如，图3的步骤S10)，则RecoveryAttemptsNum(字段292)将最终超过MaxRecoveryAttemptsNum(字段296)，并且导致步骤S106的结果是。在这种情形下，InLogic32执行到步骤S105，其中InLogic32将连接降级到慢速连接，将包含错误的数据传送14A放置到重新装配缓冲器34中，并且调度确认该TCP分段的成功接收的Ack。对于每个包含错误的数据传送，进行上述处理。
图4B表示有限重新发送尝试模式的另一个组成部分，其应对的是这样的事实，即数据损坏通常不在多个连续TCP分段中发生，但是非对齐分段可能影响若干后续TCP分段。例如，快速连接可以维持长时间段，例如五小时，并且不时地，例如一小时一次，可能具有数据损坏，使得CRC验证将失败。当这种情况发生时，每次丢弃包含错误的数据传送(即损坏的分段)时，可以增加RecoveryAttemptsNum(字段292)。该处理应对这样的情形，其中不同分段在不同的时间段由于数据损坏而被丢弃，并且在若干(可能为一)重新发送操作之后，成功地接收这些分段，并且将其放置到存储器中。相应地，成功地完成对这些分段的恢复操作，并且得到恢复的数据损坏情形不被计数，即当由于接收新的错误分段而进入新的恢复模式时。
为了从有限重新发送尝试模式退出，在步骤S105进行关于新接收的按顺序数据传送的TCP分段序列号(SN)(即，InOrderTCPSegmentSN)是否大于LastRecoverySN(SN)(图2B中的字段294)的确定。也就是，将属于快速连接的每个新接收的按顺序TCP分段的序列号与从一个或多个先前接收的包含错误的数据传送中选择的所存储最大序列号进行比较。(注意，具有更大SN的失序分段的接收不意味着错误恢复完成。)然而，有关恢复完成的一个指示是接收到在导致进入恢复模式的分段之后传送的TCP分段。该情形可以通过比较InOrderTCPSegmentSN与LastRecoverySN来确定。该确定可以实际在针对该连接接收的TCP分段的任何处理阶段进行。例如，在图3中的步骤S9之后，或者在图4A中的步骤S102之前。当按顺序分段SN大于LastRecoverySN，即接收到新TCP分段并且步骤S105的确定为是时，在步骤S106，复位RecoveryAttemptsNum(图2B中的字段292)，即将其设为零。关于上述例子，在被丢弃分段由于数据损坏而被丢弃，然后在发送方重新发送该分段之后被成功接收并且作为对齐分段被处理的情形下，步骤S105防止在长时间段例如五小时之后不必要地将快速连接降级为慢速连接(即，由于RecoveryAttemptsNum超过MaxRecoveryAttemptsNum)。如果步骤S105的结果为否或者在步骤S106之后，分段处理照常继续例如图3的步骤S1。
使用上述处理，通过设置MaxRecoveryAttemptsNum字段296，能够由用户定义允许重新发送次数。应当认识到，虽然上面结合图4A-4B以及与图3的步骤S10相关的错误检测描述了有限重新发送尝试模式，但是如下面将要进一步描述的那样，有限重新发送尝试模式不只是适用于步骤S10的错误检测。注意，有限重新发送模式也可有利地用于下述部分D，加速TCP重新发送处理，该处理当分段由于ULP因素而被丢弃时，发送中间重复Ack。
B.连接降级参考图5，现在将描述对这样的独特情形的处理，在该情形中，当在快速路径模式中将一个或多个失序接收的DDP分段112放置到目的数据缓冲器50中之后，连接被降级(图3中的步骤S3)。如图5所示，失序地，即按照顺序3、4、1和2接收被标记为分组(Pkt)的四个TCP分段。当连接被降级到慢速连接时，从降级时刻开始接收的所有数据都被放置到重新装配缓冲器34中，并且被重新装配成按顺序的，即装配为Pkt1、2、3和4。在这种情形下，根据TCP协议，InLogic32维护有关这些分段被接收的记录。
虽然很少见，但可能出现这样的情形，其中(一个或多个)分段例如Pkt#3(加阴影)被直接放置到目的数据缓冲器50中。即使InLogic32假定接收到所有数据，该情形仍然导致用‘垃圾’数据，即间隙或洞来填充正常将保存分组3(Pkt#3)的重新装配缓冲器34中的位置。如果允许不加纠正地继续处理，则当OutLogic40将重新装配缓冲器34传送到目的数据缓冲器50时，将用‘垃圾’数据覆盖在快速路径模式下较早传送的分组3(Pkt#3)，这将损坏数据。
为了解决这一问题而不增加硬件复杂度，在可选实施例中，InLogic32指示TCP逻辑忘记在连接是快速连接时失序接收的分段(即，图5中的Pkt#3)。具体地说，InLogic32被配置成在步骤S3(图3)将连接降级到慢速连接时清除失序放置的数据传送的TCP洞，并且停止对发送方进行的有关已经接收到这些分组的接收报告(SACK选项)。结果，发送方重新发送所有未被确认的数据，包括失序的直接放置到目的数据缓冲器50中的那些分段，即Pkt#3。当接收到重新发送的数据时，将它写入到重新装配缓冲器34中，并且当OutLogic40从重新装配缓冲器34传送数据时，在目的数据缓冲器50处覆盖任何失序的直接放置的分段。该功能实际意味着RNIC16‘丢弃’在该连接中失序的放置到目的数据缓冲器50中的分段。这样的方案消除了重新装配缓冲器34中的‘带间隙’按顺序流的情形，并且由于将引起该行为的条件很少见，不会导致明显的性能恶化。
C.连接升级作为另一个可选实施例，本发明可以包括如图6所示的连接升级过程。上述快速路径模式方案的目的是对于携带对齐DDP分段112的连接，允许绕过重新装配缓冲器34。然而，甚至在快速连接中，数据源12或中间网络设备也可能生成间歇性非对齐DDP分段112NA，根据上述技术，这将导致快速连接被降级到慢速连接。该间歇性行为例如可以由TCP重新发送期间的最大分段大小(MSS)改变或者其它偶发性情形导致。
如图6所示，为了从该情形中恢复，本发明还可以提供在例如步骤S3(图3)的较早降级之后从慢速连接到快速连接的连接升级。为了允许升级，必须提供多种情形。在可选实施例的第一步骤S31中，InLogic32确定重新装配缓冲器34是否为空。如果否，则不进行升级-步骤S32。如果在步骤S31确定为是，则在步骤S33，InLogic32确定是否正在接收对齐DDP分段112。如果否，则不进行升级-步骤S32。如果在步骤S33确定为是，则在步骤S34，InLogic32确定连接是否被例如数据源12的发送方发起为快速连接。如果在步骤S24确定为否，则不进行升级-步骤S32。如果在步骤S34确定为是，则在步骤S35将连接升级到快速连接。
D.加速TCP重新发送处理另一个可选实施例应对这样的情形，其中TCP分段106被接收，但是由于RDMA或ULP的考虑(例如DDP分段的损坏、无效CRC等)而被丢弃。根据上述过程，存在若干这样的情况，其中TCP分段106被接收并且通过TCP校验和检查，但是被InLogic32丢弃而不发送覆盖该分段的TCP Ack(即，图3的步骤S9)。然后，常规的过程将导致这些分组的重新发送尝试。具体地说，在基本方案(所谓的“Reno协议”)中，TCP发送方在它获得三个重复的Ack(即，没有提前按顺序接收数据的序列号的Ack)时，开始‘快速重新发送’模式。例如，假定两个TCP分段A和B，并且分段B按照TCP顺序在分段A之后。如果分段A被丢弃，则接收方只有在它接收到分段B时才会发送重复Ack。该重复Ack将表示“我正在等待分段A，但是接收到另一个分段”，即分段B。在基于Reno协议的‘快速重新发送’模式中，发送方发送一个分段，然后等待另外三个重复Ack以重新发送另一个分组。更高级的方案(如所谓的“新Reno协议”)允许在其‘快速恢复’模式中针对每个接收的重复而重新发送分段。该处理基于的逻辑是如果一个分段离开网络，则发送方可以将另一个分组放置到网络中。
为了利于重新发送，根据本发明的可选实施例，InLogic32生成第一重复TCP确认(Ack)，其覆盖被TCP确定为有效但是基于高层协议(ULP)判定而被TCP丢弃(例如，在图3的步骤S9)的接收TCP分段；并且发送该重复TCP Ack。如上所述，ULP可以包括以下协议中的一个或多个MPA协议、DDP协议、以及RDMA协议。不管TCP分段是按顺序的还是失序的，并且甚至在没有接收到下一个按顺序TCP分段的情形下，均针对TCP分段生成第一重复TCP Ack。InLogic32还可以生成覆盖下一个失序接收TCP分段的第二重复TCP确认(Ack)，并且发送第二重复TCP Ack。
上述处理实际意味着即使可能尚未接收下一个按顺序分段(例如，上面例子中的分段B)，仍然生成重复Ack(例如，针对上面例子中的分段A)，因此在上述重新发送规则下，应当加速使发送方重新进入快速路径模式的处理。更具体地说，即使尚未接收分段B，发送方也将知道分段A，有效的TCP分段被接收并且由于ULP的考虑而被丢弃。结果，附加的重复Ack迫使发送方当在重新发送开始之前必须接收若干重复Ack的情形下更早地开始重新发送过程。该方案不违反TCP原则，因为TCP分段106已经被成功地送达到ULP，但是由于ULP的考虑(无效CRC)而被丢弃。因此，该分组不被IP协议丢弃或重新排序。当RNIC16实现如结合图4A所概述的有限重新发送尝试模式，即在步骤S103发送Ack时，该方案特别有价值。
E.CRC计算和验证传入以太网帧的常规处理从过滤处理开始。过滤的目的是将有效的以太网帧与无效的以太网帧相分离。“无效帧”不是损坏的帧，而是不应当由RNIC16接收的帧，例如，MAC过滤-基于MAC地址的帧选择，虚拟局域网(VLAN)过滤-基于VLAD标签的帧选择，等等。允许进入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的边界之后，与TCP分段有效负载127的该部分的校验和计算同时地计算和验证该DDP分段的CRC，然后继续到包含在相同TCP分段106中的下一个潜在DDP分段112(若有的话)。对于在TCP分段106中发现的每个“潜在”DDP分段，CRC验证结果可以是有效、无效或过长。存储CRC验证结果以便如上面结合图3所述的那样加以使用。
为了如上所述实际计算CRC，当处理TCP分段106的有效负载时，InLogic32需要知道MPA标记110在TCP分段106中的何处。如上面关于图1B所讨论的那样，每隔512字节在TCP分段106中放置MPA标记110，并且第一MPA标记与作为连接上下文42的StartNum字段248(图2B)存储的、TCP报头126(图1B)中的初始序列号相距512字节。遗憾的是，每个MPA标记110的评估未揭示出其相对于StartNum248(图2B)的位置。另外，MPA标记110被CRC数据116覆盖，但是不包括在MPA长度字段114中，其中MPA长度字段114仅包括MPA帧的有效负载。相应地，为了识别MPA标记110，RNIC16需要知道必须从连接上下文42取出的StartNum248(图2B)。遗憾的是，在TCP处理期间，读取连接上下文42是非常不便于进行的，因为此读取在处理中非常早地发生，并且打断或停顿分组处理。
为了减少或消除连接上下文42取出，本发明提供了四种可选方案，其允许正确计算DDP分段112长度，该DDP分段112长度是计算和验证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可以通过获得特定分段的序列号和StartNum238之差来确定在何处找到标记，然后从该位置开始，每512字节地定位标记。MPA规范定义上述标记检测方法。这样，可以在执行TCP校验和验证之前执行散列查找(基于TCP三元组)和连接上下文42预取。这是正常连接上下文42取出流程。如果RNIC16想要取得连接上下文42，它首先需要了解该上下文位于何处，或者取得连接ID。TCP分段106报头携带TCP三元组(IP地址(源和目的地)和TCP端口(源和目的地))。三元组是散列函数的输入。散列函数的输出是连接ID。当然，可能产生不同三元组的相同连接ID，这被称作“冲突”。为了处理冲突，RNIC16读取连接上下文42，采用分组中的三元组检查连接上下文42中的三元组，并且如果它不匹配，则RNIC16取得指向下一个连接上下文42的指针。RNIC16一直检查三元组，直至它发现匹配或者将分段识别为不属于任何已知连接的分段。该处理允许定位TCP流中的MPA标记110。结果，可以与TCP校验和验证同时地执行CRC计算和验证。
2.初始序列号协商方法在第二可选实施例中，通过对MPA规范进行若干改变，可在不进行连接上下文取出的情形下，正确地计算DDP分段长度。首先，改变MPA规范中的MPA标记110放置的定义。上述连接上下文预取方法的一个缺点是需要执行散列查找和连接上下文42预取以识别TCP分段106中的MPA帧109的边界。为了防止这一点，本发明以每512字节的方式，而不是以从初始序列号(SN)(被保存为StartNum248)开始每512字节的方式(这需要上述SN-StartNum模除512处理)放置MPA标记110。以这种方式，MPA标记110位置可以通过序列号模除512的处理来确定，以便定位MPA标记110，并且无需连接上下文42取出。
根据该实施例对MPA规范的第二个改变用于避免在两个DDP分段112之间分割一个标记的情形，即初始序列号没有字对齐的情形。结果，序列号模除512处理可能不在所有环境中工作，因为标准TCP实现允许初始SN具有随机生成的字节对齐值。也就是，初始序列号是否字对齐不能由RNIC16控制。结果，给定连接的TCP流可能不一定以MPA标记110开始。相应地，如果CRC逻辑64仅仅通过使用序列号模除512处理来提取标记110的位置，则它可能使标记被放置到不可接受的字节对齐位置。为了避免这一情形，本发明向在MPA协商阶段交换的MPA帧，即所谓的“MPA请求/应答帧”添加填充字节，以使RDMA连接的初始SN字在它变为RDMA模式时字对齐。也就是，如图7所示，将校正因子150插入到TCP分段106的MPA请求/应答帧152中，其包括使初始SN字对齐所需的一定数目的字节。应当认识到，校正因子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的2个最低有效位(LSB)、以及填充字节121中的有效位。
该修改的定义允许使用MPA长度字段114检测MPA帧109边界，而无需定位嵌入在该MPA帧中的所有MPA标记110。MPA层协议负责剥离标记110、CRC数据116以及填充字节121，并且向ULP(DDP层)提供ULP有效负载长度。
参考图8，使用MPA长度的这一定义，CRC逻辑64通过下面处理来定位MPA帧109的边界在步骤S100，CRC逻辑64确定MPA帧109的第一字是否等于零。如果是，则InLogic32(图2A)在步骤S102从下一个字中读取MPA长度字段114。这是MPA标记110落在两个MPA帧109之间的情形。在这种情形下，MPA长度字段114如步骤S104所示位于下一个字中。如果在步骤S100确定为否，则该字保存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逻辑，以允许与TCP校验和计算同时地进行运行时刻CRC计算，并且无需预取连接上下文42。
完全如针对具有标记的情形描述的那样进行CRC计算。也就是，本发明假定TCP分段以对齐DDP分段开始，并且使用MPA长度字段来查找CRC的位置，然后计算和验证CRC。然而，与该实施例的区别是在给定MPA报头的MPA长度字段的情况下，在计算DDP分段长度时无需考虑标记。
参考图9，其中示出了说明与该实施例的第一可选方案相关的InLogic32功能的流程图。应当认识到，InLogic32功能的大部分基本上类似于上面关于图3描述的功能。为清楚起见，在InLogic32功能基本上类似于上面关于图3所述的情形下，重复并且用虚线框标出这些步骤。
在更新的MPA规范下，接收方在连接初始化时协商特定连接的‘无标记’选项。如图9所示，在该实施例中，在步骤S201，InLogic32确定入站TCP分段106是否包括标记110。如果是，则InLogic32如在图3中那样继续处理，并且如上所述将使用一些其它的CRC计算和验证方法。如果为否，则在步骤S202，使用与TCP校验和逻辑66相同的存储转发缓冲器68在运行时刻计算和验证入站MPA帧109的CRC，但是无需取出连接上下文42。还可以完成有关连接是否是慢速连接的确定，如图3中的步骤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中)。这留下两个需要解决的情形情形A当MPA帧109被先前接收的分段(并且经过验证的)MPA帧109的长度引用(如在图3的步骤S8所确定的那样)时；以及情形B所有其它情形。在情形A中，MPA帧109被损坏，并且在情形B中，MPA帧109可能被损坏或者未对齐。在两种情形下，都丢弃接收TCP分段106(图3的步骤S9)，并且不确认接收。在这种情形下，结合图4描述的有限重新发送尝试模式可以被实现成从该TCP分段106的丢弃中恢复，这允许发送方重新发送被丢弃的TCP分段106，并且解决任何潜在的数据破坏。如果MPA帧109与TCP分段106未对齐，则有限重新发送尝试模式将如上所述通过将连接降级到慢速连接来结束。
在情形3)中，在MPA帧109的长度超过TCP分段106的长度(图3的步骤S5)的情形下，MPA帧109与TCP分段106未对齐，或者长度被损坏。在这种情形下，丢弃接收的TCP分段106(图3的步骤S9)，并且TCP不确认接收。在这种情形下，结合图4描述的有限重新发送尝试模式同样可以被实现成从该TCP分段106的丢弃中恢复，这允许发送方重新发送被丢弃的TCP分段并且解决任何潜在的数据损坏。同样，如果MPA帧109与TCP分段106未对齐，则有限重新发送尝试模式将如上所述通过将连接降级到慢速连接来结束。
在情形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未对齐，则有限重新发送尝试模式将如上所述通过将连接降级到慢速连接来结束。
转到图10，其中示出的另一个可选流程图说明了与该实施例相关的InLogic32功能，并且包括有限重新发送尝试模式和TCP重新发送加速的方面。与图9相反，相比于图3，大大简化了InLogic32功能。为了清楚起见，在InLogic32功能基本上类似于上面结合图3描述的步骤的情形下，重复并用虚线框标出这些步骤。
在图10中，步骤S151-S153基本上相同于图3的步骤S1-S3。在步骤S154，InLogic32确定是否通过CRC验证。该评估与图3中步骤S4的不同之处在于代替每个DDP分段地提供指示的方式，CRC逻辑54提供CRCValidationPassed(CRC验证通过)位，其表示接收TCP分段中的所有DDP分段的CRC验证的成功或失败。如果包含在接收TCP分段中的所有DDP分段都通过CRC验证，则设置该位，并且如果这些分段之一的CRC验证失败，或者(仅仅)最后分段过长，则清除该位。如果为否，则InLogic32继续到步骤S155，其中确定RecoveryAttemptsNum(图2B的字段292)是否大于MaxRecoveryAttemptsNum(图2B的字段296)。如果是，则InLogic继续到步骤S153，其中将DDP分段放置到重新装配缓冲器34中，发送Ack，并且将连接降级到慢速连接(如果它是快速连接)。如果在步骤S155为否，则在步骤S156，丢弃TCP分段106，并且不调度确认。另外，将RecoveryAttemptsNum(图2B的字段292)加一，并且更新LastRecoverySN(图2B的字段294)。
回到步骤S154，如果该确定的结果为是，则在步骤S157，InLogic32继续确定新接收的按顺序数据传送的序列号(按顺序的SN)是否大于LastRecoverySN(图1B的字段294)。如果是，则在步骤S158，InLogic32清除RecoveryAttemptsNum(图1B中的字段292)，即将它设为零。如果在步骤S157为否或者在步骤S158之后，则在步骤S159，通过将分段放置到目的数据缓冲器50中，在“快速路径模式”下处理分段。如上面针对TCP重新发送加速选项所讨论的那样，步骤S159还可以包括重复Ack的实现。
上述图10实施例实现本发明的直通转发模式，加上有限重新发送尝试模式和TCP重新发送加速选项，而不使用MPA标记。
III.OutLogicOutLogic40(图2A)执行RDMA消息的按顺序送达而无需每个RDMA消息地保存信息。存在要解决的两种情形1)对于除了发送消息之外的所有RDMA消息，以及2)RDMA发送消息。
回到图1F-1H，现在将描述OutLogic40(图2A)的操作。OutLogic处理来自内部数据缓冲器38的对齐DDP分段220，其中该分段如上所述在快速路径模式下被放置在内部数据缓冲器38中，并且向接收方的数据缓冲器进行对齐DDP分段的数据放置和送达。如这里所使用的那样，“放置”是指将数据实际放置在缓冲器中的处理，并且“递送”是指确认数据传送完成的处理。“放置”可以适用于分段和消息，而“送达”仅仅适用于消息。在RDMA协议下，可以以失序方式放置对齐DDP分段，但是不进行送达，直至失序放置所有对齐DDP分段。例如，对于三个对齐DDP分段1、2和3，在没有分段1而首先放置分段2和3的情形下，不发生送达，直至放置了分段1。
A.放置对于放置，如下所述，除了与RDMA读消息相关的之外，OutLogic40提供常规的RDMA消息放置。
对于带标签DDP分段，例如，回到图1D，根据RDMA协议，带标签DDP分段的报头124携带接收方的先前注册存储器区(例如，图1G中的存储器区232)的地址。如上所示，该地址包括表示位于存储器区/窗口(例如，对于RDMA写消息，图1G中的存储器区232)中的目的缓冲器的起始标签(STag)、该区/窗口中的目标偏移量(TO)、以及事务长度(分段有效负载)。在这种情形下，数据放置由OutLogic40以常规的方式进行，而不从连接上下文42(图2A)检索任何附加信息。将STag和TO翻译成描述目的数据缓冲器的存储器区的物理缓冲器列表的常规地址翻译和保护(ATP)处理在OutLogic40的数据放置之前进行。
关于诸如RDMA读消息的无标签DDP分段，参考图1H，RDMA协议定义在协商时交换的待处理入站读请求222的最大数目。每个RDMA读消息204使用单个DDP分段222。当RNIC16接收RDMA读消息204时，它将RDMA读响应WQE216RR投递到读队列214。在另一个例子中，参考图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消息将被放置到目的缓冲器中，并且未被完成，直至丢失的分段将被重新发送并且成功地放置到存储器中。在常规的环境下，有限的资源可用于存储失序流，使得在接收到失序流之后只能存储特定数目的后续消息。
然而，根据本发明，不是为每个未被送达的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洞130A-130C的数目限制为例如一个、两个或三个洞。典型地，有限数目的TCP洞130A-130C的支持实际意味着当失序TCP分段到达从而打开新的TCP洞时，该分段被TCP逻辑丢弃。图12示出了三TCP洞实现。在这种情形下，如果新分段在底部TCP报头130C之后，即在两个底部丢失分段400之后到达，则该分段将“打开”不被支持的第四个洞。结果，该分段将被丢弃。
为了解决这一情形，本发明实现经由连接上下文42(图2A和2B)的TCP洞130(图12)的跟踪，而不是失序消息/分段的跟踪。具体地说，如图2B所示，本发明存储用来对已完成的RDMA读请求进行计数的PendingReadResponseNum字段300、用来对已完成的发送消息进行计数的CompletedSendsNum字段302、以及用来对已完成的RDMA读响应进行计数的CompletedReadResponseNum字段306。本领域的技术人员应当认识到，对于每个洞，可能需要其它字段，为了简洁起见将不对其进行描述。该方案允许无限数目的等待完成和按顺序送达的失序接收的RDMA消息。该方案不限制由没有任何限制的接收212和发送210队列共享完成队列240(图1F-1H)的能力。现在将描述特定类型的消息的处理的详细信息。
第一，应当认识到，RDMA写消息202(图1G)的送达由于该操作的性质而不导致向响应方的任何报告、或者向其它硬件逻辑的任何通知。相应地，不存在与这种RDMA消息相关的送达问题。
第二，回到图11，对于RDMA读响应消息206，该操作表示待处理RDMA读消息204的完成。在这种情形下，针对每个TCP洞130在连接上下文42中存储包含已完成的RDMA读响应消息206的数目的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针对每个TCP洞130在连接上下文42(PendingReadResponseNum字段300(图2B))中存储等待门铃响铃(通知)的已投递RDMA读响应WQE216RR的数目。当关闭TCP洞130时，RNIC16使门铃响铃(进行通知)以确认PendingReadResponseNum个WQE216RR向读队列214的投递。这表示所有先前读消息204已经完成，并且RNIC16可以开始已投递的读响应WQE216RR的处理。
参考图13，RDMA发送消息500表示一独特情形。具体地说，已完成的发送消息的送达包括将CQE452放置到CQ540中。CQE542携带描述已完成消息的信息(例如，长度、无效STag等)。该信息是特写于消息的信息，因此应当针对每个待处理发送消息500而保存。RNIC16不能在发送消息500完成之前放置CQE542(类似于所接收的读工作请求508R中的RDMA读响应WQE508RR的放置)，因为如上所述，CQ540可以由若干发送510和接收512队列共享。
为了解决这一问题但不使用附加RNIC资源，并且提供可伸缩实现，根据本发明的OutLogic40将需要包括在CQE542中的所有信息放置到由该发送消息500使用的WQE516R中。然后，在完成轮询请求时由动词接口20(图2A)从WQE516R检索该信息。RNIC16需要针对每个TCP洞130在连接上下文42中保存已完成的发送消息500的数目(CompletedSendsNum字段302中)，其被用来在对应TCP洞关闭时将CQE542投递到CQ540。当TCP洞130关闭时，RNIC16将CQE542放置到CQ540中。要放置的CQE542的数目等于针对该洞计数的已完成的发送消息500的数目。当N是已完成的发送消息500的数目时，该方案涉及2N个写操作。
上面对于RDMA发送消息500的送达而表现出的方案的一个缺点是它使由RNIC16执行的写操作的数目加倍。也就是，对于每个已完成的发送消息500，存在一个向WQE516的写入和一个CQE542的写入。为了解决这一问题，如图14所示，根据本发明的可选实施例，将CQE542的内容改变成携带特定CQE542完成的WQE516R的参考计数器544。参考计数器544由RNIC16初始化为针对给定TCP洞130完成的发送消息500的数目。对于每个完成轮询操作，动词接口20减小参考计数器544，并且只有当该计数器变成零时才从CQ540清除CQE542。另外，只有当其拥有的等待完成的未完成发送消息500多于阈值(M)时，RNIC16才更新WQE516S。M是可配置参数，表示为保存待处理入站发送消息500的信息而分配的内部资源的量。如果M等于零，则任何失序接收的发送消息500均涉及WQE516R的更新(对于按顺序接收的发送消息500，无需更新)。
该实施例还包括定义两种CQE542，并且向CQE542提供指示符546，以表示该CQE是在CQE主体内携带所有完成数据的CQE，还是携带部分完成数据的CQE，其中完成信息的其余部分存储在与一个或多个RDMA发送消息相关联的WQE516R中。该可选实施例将写操作数目减至N+1，其中N是在关闭TCP洞130之前待处理的已完成发送消息500的数目。
IV.结论在前面讨论中，应当理解，方法步骤优选地由包含用于实现本发明的一个或多个功能性任务的专用硬件的专用计算机，即有限状态机来执行。然而，这些方法步骤也可以由执行存储在存储器中的程序产品的指令的处理器，例如CPU来执行。应当理解，这里描述的各种设备、模块、机构和系统可以采用硬件、软件或者硬件和软件的组合来实现，并且其划分可以不同于所示的方式。它们可以由适于执行这里描述的方法的任何类型的计算机系统或其它设备实现。硬件和软件的典型组合可以是具有计算机程序的通用计算机系统，在被加载和执行时，该程序控制计算机系统，使得它实现这里描述的方法。本发明也可以体现在计算机程序产品中，其中该计算机程序产品包括允许实现这里描述的方法和功能的所有特征，并且当被加载到计算机系统中时，能够执行这些方法和功能。在本文中，计算机程序、软件程序、程序、程序产品或者软件是指一组指令的采用任何语言、代码或表示法的任何表示，其旨在使具有信息处理能力的系统直接地或者在下列操作之后执行特定功能(a)转换到另一个语言、代码或表示法；以及/或者(b)以不同材料形式再现。
虽然结合上面概述的特定实施例描述了本发明，但是显然本领域技术技术人员能够想到很多可选方案、修改和变化。相应地，如上所述的本发明的实施例只是说明性而非限制性的。在不背离如在所附权利要求中所限定的本发明的实质和范围的前提下，可以进行各种修改。具体地说，在特定情况下可以改变所述步骤顺序，或者由不同步骤集提供的功能，而不背离本发明的范围。
工业实用性本发明可用于计算机编程和信息技术领域。
权利要求
1.一种减少与失序RDMA发送消息(500)的送达有关的写操作的数量的方法，该方法包括步骤为参考计数器提供完成队列单元(542)(CQE)；将参考计数器设置为针对所选择的TCP洞(130)完成的RDMA发送消息(500)的数量；针对RDMA动词接口(20)执行的每次完成轮询，将参考计数器减一；和在计数器变成零的情况下从相应完成队列(540)(CQ)中清除该CQE(542)。
2.如权利要求1所述的方法，还包括仅在发送队列具有大于阈值数量的待处理RDMA发送消息(500)的情况下，更新发送队列的工作队列单元(516)(WQE)的步骤。
3.如权利要求2所述的方法，其中该阈值与为存储待处理RDMA发送消息(500)的信息而分配的资源相称。
4.如权利要求1所述的方法，还包括使CQE(542)至少包含部分完成数据的步骤。
5.如权利要求4所述的方法，其中其余完成数据被包含在与一或多个RDMA发送消息(500)相关的工作队列单元(516)(WQE)中。
6.如权利要求4所述的方法，还包括指示以下情况之一的步骤1)CQE(542)包含所有完成数据，和2)CQE完成数据被至少部分地包含在与一或多个RDMA发送消息(500)相关的工作队列单元(516)(WQE)中。
7.如权利要求1所述的方法，其中写操作的数量等于N+1，N是在选择的TCP洞(130)关闭之前待处理的完成RDMA发送消息(500)的数量。
8.一种减少与失序RDMA发送消息(500)的送达有关的写操作的数量的系统，该系统包括用于将完成队列单元(540)(CQ)的参考计数器设置为针对所选择的TCP洞(130)完成的RDMA发送消息(500)的数量的装置；用于针对RDMA动词接口(20)执行的每次完成轮询将参考计数器减一的装置；和用于在计数器变成零的情况下从相应完成队列(540)(CQ)中清除该CQE(542)的装置。
9.如权利要求8所述的系统，还包括用于仅在发送队列具有大于阈值数量的待处理RDMA发送消息(500)的情况下，更新发送队列的工作队列单元(516)(WQE)的装置。
10.如权利要求9所述的系统，其中该阈值与为存储待处理RDMA发送消息(500)的信息而分配的资源相称。
11.如权利要求8所述的系统，还包括用于将至少部分完成数据存储在CQE(542)中，并且将其余完成数据存储在与一或多个RDMA发送消息(500)相关的工作队列单元(516)(WQE)中的装置。
12.如权利要求11所述的系统，还包括用于指示以下情况之一的装置1)CQE(542)包含所有完成数据，和2)CQE完成数据被至少部分地包含在与一或多个RDMA发送消息(500)相关的工作队列单元(516)(WQE)中。
13.如权利要求8所述的系统，其中写操作的数量等于N+1，N是在选择的TCP洞(130)关闭之前待处理的完成RDMA发送消息(500)的数量。
14.一种包括计算机可用介质的计算机程序产品，该计算机可用介质具有在其中体现的计算机可读程序代码，该计算机可读程序代码用于减少与失序RDMA发送消息(500)的送达有关的写操作的数量，该程序产品包括用于将与完成队列单元(542)(CQE)相关的参考计数器设置为针对所选择的TCP洞(130)完成的RDMA发送消息(500)的数量的程序代码；用于针对RDMA动词接口(20)执行的每次完成轮询将参考计数器减一的程序代码；和用于在计数器变成零的情况下从相应完成队列(540)(CQ)中清除该CQE(542)的程序代码。
15.如权利要求14所述的程序产品，还包括用于仅在发送队列具有大于阈值数量的待处理RDMA发送消息(500)的情况下，更新发送队列的工作队列单元(516)(WQE)的程序代码。
16.如权利要求14所述的程序产品，其中该阈值与为存储待处理RDMA发送消息(500)的信息而分配的资源相称。
17.如权利要求14所述的程序产品，还包括用于在CQE(542)中存储至少部分完成数据的程序代码。
18.如权利要求17所述的程序产品，其中存储程序代码在与一或多个RDMA发送消息(500)相关的工作队列单元(516)(WQE)中存储其余完成数据。
19.如权利要求17所述的程序产品，还包括关于以下情况之一的指示符1)CQE(542)包含所有完成数据，和2)CQE完成数据被至少部分地包含在与一或多个RDMA发送消息(500)相关的工作队列单元(516)(WQE)中。
20.如权利要求17所述的程序产品，其中写操作的数量等于N+1，N是在选择的TCP洞(130)关闭之前待处理的完成RDMA发送消息(500)的数量。
全文摘要
一种RNIC(16)实现，其在特定连接的所有分段均对齐的情形下执行向存储器的直接数据放置，或者在特定连接的所有分段是非对齐的情形下移动数据经过重新装配缓冲器(34)。直通转发而不访问重新装配缓冲器(34)的连接的类型被称作“快速”连接，因为它非常可能是对齐的，而另一类型被称作“慢速”连接。当消费方建立连接时，它指定连接类型。连接类型可以从快速变到慢速。本发明减少了存储器带宽、等待时间、使用TCP重新发送的差错恢复，并且规定自空接收队列的“适度恢复”。该实现还可以在发送用于确认分段接收的TCP确认(Ack)之前，对快速连接中的大部分入站DDP分段进行循环冗余校验(CRC)验证。
文档编号G06F15/167GK1997977SQ200480036633
公开日2007年7月11日 申请日期2004年12月7日 优先权日2003年12月11日
发明者吉奥拉·比拉恩, 佐里克·玛储尔斯基, 瓦迪姆·玛赫瓦克斯 申请人:国际商业机器公司