CN101194250A - 用于关闭rdma连接的方法和系统 - Google Patents

用于关闭rdma连接的方法和系统 Download PDF

Info

Publication number
CN101194250A
CN101194250A CN200680016265.4A CN200680016265A CN101194250A CN 101194250 A CN101194250 A CN 101194250A CN 200680016265 A CN200680016265 A CN 200680016265A CN 101194250 A CN101194250 A CN 101194250A
Authority
CN
China
Prior art keywords
rdma
stream
packets
calm
request
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN200680016265.4A
Other languages
English (en)
Inventor
S·冯
J·T·平克顿
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Corp
Original Assignee
Microsoft Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Microsoft Corp filed Critical Microsoft Corp
Publication of CN101194250A publication Critical patent/CN101194250A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/10—Streamlined, light-weight or high-speed protocols, e.g. express transfer protocol [XTP] or byte stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/12—Protocol engines

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer And Data Communications (AREA)
  • Multi Processors (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

公开的是用于处理分组流连接上携带的RDMA连接的方法。一方面，I/O完成事件在一多处理器计算设备中的多个处理器间被分布，从而消除了处理的瓶颈。对于每个将接受I/O完成事件的处理器，至少一个完成队列被创建。当一I/O完成事件在这些完成队列中的一个上被接收到时，与该队列关联的处理器处理该事件。第二方面，定义了分组流处理程序、RDMA层、和RNIC间进行交互的语意来控制RDMA关闭从而避免实现错误。第三方面，定义了在避免可能的竞态情况的同时将现有分组流连接转移到RDMA模式的语义。结果所得的RNIC体系结构比传统的要简单，因为RNIC从不需要同时处理流消息和RDMA模式话务两者。

Description

用于关闭RDMA连接的方法和系统
技术领域
本发明一般涉及远程直接存储器存取，尤其涉及对分组流上携带的RDMA连接的本地处理。
发明背景
DMA(直接存储器存取)是一种传统的技术，其在仅使用少量或不使用计算设备的中央处理单元的资源的同时将项目从计算设备的动态存储器中的一个地方移动或复制到另一个地方。RDMA拓展了这个概念并将存储器项目从一个计算设备移动或复制到另一个计算设备。在高速连网环境以及在高性能计算环境中，预计RDMA的价值将变得越来越难以估量。例如，数据中心和服务器站将依赖于RDMA来协调由运行诸如TCP等分组协议的网络连接的计算设备。
由于RDMA的巨大商业价值，例如RDMA联盟等正在将其各个方面标准化。但这些努力尚不足以覆盖RDMA处理中对于产生RDMA所允诺的效率而言有意义的所有领域。例如，RDMA连接通常历时很长，并常常需要密集地使用本地输入/输出(I/O)资源。当单个的计算设备被调用来支持多个同时的RDMA连接时，所涉及的本地处理可能会湮没计算设备的资源，从而导致瓶颈并导致RDMA传递效率低下。
在另一所涉领域，支持RDMA连接协议的网络接口控制器(NIC)可能因其也支持下层网络分组协议而混淆或被湮没。用它们各自不同的命令协调这两种协议、以及用计算设备的操作系统来协调两者导致了复杂的问题以及易于出错的实现。更关键的是，当在现有的分组流之上关闭现有RDMA连接或当发起RDMA连接时会产生问题。
以上仅仅是在RDMA能实现其全部潜能之前尚未解决的关注领域的几个例子。
发明概要
鉴于以上，本发明定义用于在分组流处理程序、RDMA层、和RNIC(RDMA网络接口控制器)间进行交互的语义，以控制RDMA的关闭来力图管理实现复杂性。分组流处理程序包括断开请求处理程序，其向RNIC发出断开请求(可以是针对从容或异常断开)。当RNIC接收到针对携带RDMA连接的分组流的断开请求时，RNIC关闭该RDMA连接和该分组流两者。
在一些实施例中，除非被显式地请求执行在分组流上执行从容断开，否则RNIC决不会发送出分组流FIN消息。如果RNIC发送或接收分组流RST消息，则它向主计算设备的操作系统指示异常断开事件。
在一些实施例中，只有在分组流已经在两个方向上皆关闭或异常中断之后，终止卸载(Terminate Offload)请求才被发送给RNIC。这样做将确保仅当相关队列对的状态为空闲、错误或关闭时才作出终止卸载请求。
附图简要说明
虽然所附的权利要求具体地阐述了本发明的特征，但本发明及其目的和优势可以结合附图从以下具体说明更好地理解，附图中：
图1是其中各计算设备经由RDMA共享数据的示例性连网环境的框图；
图2是一般地例示支持本发明的示例性计算设备的示意图；
图3是支持RDMA连接的示例性体系结构的示意图；
图4是用来保留RDMA资源的方法的工作流程图；
图5是用来改变RDMA读资源的方法的工作流程图；
图6是用来将分组流转移到RDMA模式的方法的工作流程图；
图7是用来在多处理器计算设备上初始化每接口的完成处理程序的方法的工作流程图；
图8是多处理器计算设备上的完成队列和队列对的示意图；
图9是在多处理器计算设备上的各处理器间分布完成事件的方法的流程图；
图10是用来关闭RDMA连接的方法的流程图；
图11是用来本地发起RDMA连接的从容关闭的方法的工作流程图；
图12是用来在发送队列非空时本地发起RDMA连接的从容关闭的方法的工作流程图；
图13是用来本地发起有错的RDMA连接的从容关闭的方法的工作流程图；
图14是用来远程地发起RDMA连接的从容关闭的方法的工作流程图；
图15是用来在本地发送队列非空时远程地发起RDMA连接的从容关闭的方法的工作流程图；
图16是用来远程地发起有错的RDMA连接的从容关闭的方法的工作流程图；
图17是用来在检测到错误时异常关闭RDMA连接的方法的工作流程图；
图18是用来通过终止状态本地发起RDMA连接的异常关闭的方法的工作流程图；
图19是用来不通过终止状态本地发起RDMA连接的异常关闭的方法的工作流程图；
图20是用来远程地发起RDMA连接的异常关闭的方法的工作流程图。
发明具体说明
转到附图，其中相同的附图标记标示相似的要素，本发明被图示为在适当的计算环境中实现。以下的说明是基于本发明的实施例，但考虑到在此未明确描述的替换性实施例，以下说明不应被示为限定本发明。
在以下的说明中，围绕本发明的环境是参考由一个或多个计算设备执行的动作以及操作的注记表示来进行描述，除非另有说明。由此，应当理解，有时称为计算机执行的这样的动作和操作包括由计算设备对以结构化形式表示数据的电信号进行的操纵。此操纵对数据进行变换或在计算设备的存储器系统的各个位置处维护这些数据，从而以本领域的技术人员公知的方式对设备的操作进行重新配置或者变更。维护数据的数据结构是存储器中具有由数据的格式定义的特定属性的物理位置。但是，尽管本发明在前述的上下文中进行描述的，但并不意味着限定，本领域的技术人员将可以理解，以下所描述的各种动作及操作也可以在硬件中实现。
序言
RDMA是近来开发的技术，其能使一台计算机用少量或不使用处理器额外开销而直接存取远程对等设备的存储器。RDMA实现了常规分组网络——例如TCP(传输控制协议)流——上的零复制发送和接收。
图1示出了RDMA连网环境100，其中网络102连接了四个计算设备104。计算设备104使用它们的网络102连接来执行相互的RDMA传递。网络102可以是例如本地管理的公司LAN(局域网)或因特网。
图1仅旨在为以下讨论目的而引入RDMA动作者以及它们的相互关系。因此，所描绘的RDMA环境100被大大地简化。由于RDMA的一些方面在本领域中是公知的，因此这些方面——诸如认证方案和安全等都不再这里讨论了。在设置和运行成功的RDMA环境100中所涉及的复杂性对于在本领域中工作的人来说都是公知的。
图1的计算设备104可以是任意体系结构的。图2是一般化地示出支持本发明的示例性计算机系统的框图。图2的计算机系统仅是合适的环境的一个例子，并且并不试图对本发明的使用范围或功能提出任何限定。也不应当将计算设备104解释为具有与图2中所示的组件中的任何一个或其组合有关的任何依赖性或要求。本发明可与许多其他的通用或专用计算环境或配置一起工作。适于与本发明一起使用的公知计算系统、环境和配置的示例包括但不限于，个人计算机、服务器、手持式或膝上型设备、多处理器系统、基于微处理器的系统、机顶盒、可编程消费电器、网络PC、微型计算机、大型计算机、以及包括任意以上系统或设备的分布式计算环境。在其最基本的配置中，计算设备104通常包括至少一个处理器200和存储器202。存储器202可以是易失性的(诸如RAM)、非易失性的(诸如ROM或闪存)、或这两者的某种组合。这个最基本的配置在图2中由虚线204例示。计算设备104可以具有外加的特征和功能。例如，它可以包括外加的存储(可移动的和不可移动的)，其包括但不限于，磁盘和磁带以及光盘和光带。这样的外加存储在图2中由可移动存储206和不可移动存储208例示。计算机存储介质包括易失性和非易失性的，可移动的和不可移动的，在任何方法或技术中实现的用来存储诸如计算机可读指令、数据结构、程序模块或其它数据等信息的介质。存储器202，可移动存储206和不可移动存储208都是计算机存储介质的示例。计算机存储介质包括，但不限于，RAM、ROM、EEPROM、闪存、其他的存储器技术，CD-ROM、数字通用盘、其他的光存储，磁卡带、磁带、磁盘存储、其他的磁存储设备，以及任何其他可以用来存储所需信息并可由计算设备104访问的介质。任何这样的计算机存储介质都可以是计算设备104的一部分。计算设备104还可以包含允许其与其他设备——包括在网络102上的设备——通信的通信信道210。通信信道210是通信介质的示例。通信介质通常在诸如载波等的已调制数据型号或其它传输机制中包含计算机可读指令、数据结构、程序模块、或其他数据，并包括任何信息传递介质。术语“已调制数据信号”意味着其特征中的一个或多个被以在信号中编码信息的方式设置或改变的信号。作为示例而非限定，通信介质包括光介质、诸如有线网络和直线连接等的有线介质、诸如声音、RF、红外线和其他无线介质等的无线介质。在此使用的术语“计算机可读介质”包括存储介质和通信介质两者。计算设备104还可以具有诸如触敏式显示屏、硬件键盘、鼠标、语音输入设备等的输入设备212。输出设备214包括设备本身，诸如触敏式显式屏、扬声器、打印机和用来驱动这些设备的呈现模块(常称之为“适配器”)。所有这些设备都是本领域公知的，因此在此无需详细讨论。计算设备104具有电源216。
以下的定义将有助于讨论RDMA。
消费者：Winsock内核(WSK)或RAL代理的内核模式用户
数据阱：接收数据有效载荷的对等计算设备。要注意的是，发送和接收RDMA/DDP(直接数据定位)消息两者可能都需要数据阱来传送数据的有效载荷。
数据源：发送数据有效载荷的对等计算设备。要注意的是，发送和接收RDMA/DDP(直接数据定位)消息两者可能都需要数据源来传送数据有效载荷。
无效STag：用来防止远程对等设备重复使用先前显式地告示的STag直到本地对等设备通过后续的显式告示使其重新可用的机制。
iWARP：一组有线协议，包括RDMAP(RDMA协议)、DDP和MPA(标记PDU对齐组帧)。iWARP协议组可以层叠于TCP、SCTP(流控制传输协议)或其他传输协议之上。
本地对等设备：在连接的本地端上的RDMA/DDP协议实现。它用来在描述在两个计算设备之间的协议交换或其他交互时引用本地实体。
消息：应用记录被从数据源传输到数据阱，保留记录边界并使用还没有被从数据阱向数据源告示的缓冲。这是用来传输数据的三种传统的RDMA模式中的一个(还有RDMA读和RDMA写)。
RDMA读：由数据阱使用的将源RDMA缓冲的内容从远程对等设备传送到本地对等设备的RDMA操作。RDMA读操作包含单个RDMA读请求消息和单个RDMA读响应消息。这是用来传送数据的三种传统的RDMA模式中的一个。
RDMA写：使用RDMA将源RDMA缓冲的内容从本地对等设备传送到在远程对等设备处的目标RDMA缓冲的RDMA操作。RDMA写消息仅描述数据阱RDMA缓冲。这是用来传送数据的三种传统的RDMA模式中的一个。
RDMA：一种存取远程系统上的存储器的方法，其中本地系统指定要被传送的数据的远程位置。在远程系统中采用RNIC在不中断系统上CPU的处理的情况下允许存取的发生。
远程对等设备：在连接的相对端上的RDMA/DDP协议实现。它被用来在描述两个输出设备之间的协议交换或其他交互时引用远程实体。
RNIC：RDMA网络接口控制器是具有iWARP和动词功能的网络I/O适配器或嵌入式控制器。
RNIC接口(RI)：通过RNIC和RNIC驱动器的组合实现的RNIC向动词消费者的呈示。
发送：RDMA操作，其将ULP(上层协议)缓冲的内容从本地对等设备传送到在远程对等设备处的未标记的缓冲。
转向标签(STag)：节点上被标记的缓冲的标识符，依协议规范内定义为有效。
被标记的缓冲：通过STag、被标记的偏移量、和长度来显式地向远程对等设备告示的缓冲。
未标记的缓冲：没有显式地向远程对等设备告示的缓冲。
动词：RNIC接口功能的抽象描述。OS(操作系统)可以通过一个或多个API(应用程序编程接口)来向应用程序曝露这些功能中的一些或全部。OS还使用这些功能中的一些来管理RNIC接口。
示例性RDMA体系结构的综览
图3给出作为支持RDMA的体系结构的一个示例的“烟囱(chimney)体系结构”的综览。RDMA模块300具有两个消费者：WSK和RAL代理(在图3中未示出但在RDMA模块300“之上”)。图3的示例性体系结构利用现有的TCP烟囱机制来执行RDMA卸载和上载请求。在RDMA烟囱中，状态如它们在TCP烟囱中那样被更新，其中任何高速缓存的状态可以在连接被卸载的同时被更新，但委托的状态不能被修改，除非RDMA连接已被上载。RDMA烟囱是通过NDIS(网络驱动器接口规范)来与烟囱驱动器312协商的。
虽然类似，但RDMA烟囱与传统的TCP烟囱卸载体系结构在数个重要方面相异。
·对于TCP，在卸载被发起之前连接通常已被建立并且发生了一些数据传送。这样软件堆栈就具有应当传送给NIC 308的TCP状态。对于RDMA，相反，一旦应用程序决定开始使用RDMA(在已经建立的TCP连接上)，则连接被立即卸载。由此，在堆栈中仅有少量的RDMA状态。
·TCP/IP(网际协议)卸载状态分为三类：恒定的、高速缓存的和委托的。相反，大多数RDMA状态是委托的。
·如果TCP连接已经被卸载并转换到RDMA模式，则它在连接的生命期中都将停留在RDMA模式中。
·目前，唯一支持的上载状态是用于关闭的连接：QP(队列对)状态为空闲。
RDMA模块300包括RDMA卸载管理器(ROLM)(在图3中未示出)。ROLM执行以下功能(参见稍后关于示例性实现细节的章节)：
·它用NDIS并用RNIC迷你端口来初始化设备和软件。ROLM机制的细节和在初始化期间所使用的数据结构将在以下描述。
·ROLM管理资源：(1)它管理STag；(2)它在卸载开始之前保留资源，包括创建和配置PD(保护域)、CQ(完成队列)和QP；以及(3)它在卸载完成时清除资源。
·ROLM通过SNMP MIB(简单网络管理协议管理信息基础)提供RDMA统计。某些RDMA统计通过SNMP MIB被收集并报告给用户。
·RDMA向系统管理员曝露多个配置选项以便他们可以在RNIC 308上指定以下选项：允许/不允许在某些TCP端口上进行RDMA操作，允许/不允许从某些IP地址传入的RDMA请求，以及在RNIC 308上禁用/启用RDMA。
以下是WSK API RDMA编程模型的语意的简要综览。存在着确保用户RDMA操作的正当排序的保证和约束。用户还可以在某些RDMA操作上请求围栅指示器。所有的调用都是异步的。
WskRdmaMapAnd Send：实现RDMA发送和无效发送。这个功能允许本地缓冲被指定为WSK_BUF(MDL)或STag/偏移量/长度的分散/集中列表(SGL)。这允许用户给出无效的STag，并且这个功能将通过“PostSQ”动词映射该STag并接着进行RDMA发送。
WskRdmaRecv：接收RDMA发送类型消息。缓冲被张贴到QP的RQ(接收队列)。
该缓冲可被指定为的WSK_BUF或STag/偏移量/长度的SGL。
WskRdmaGet：实现RDMA读操作。这个API被用来向远程对等设备发出RDMA读请求。此API信号的完成通知读操作已经完成并且有数据可用。
WskRdmaGet支持WSK_BUF或STag/偏移量/长度的SGL，并且如果多个分散/集中的条目被张贴，则生成多个RDMA读。
WskRdmaPut：实现RDMA写操作。这个调用被用来向远程对等设备发出RDMA写请求。由于WskRdmaPut在远程对等设备上没有完成语意，因此在该调用本地完成之后，应用程序通常将使用WskRdmaSend()发送指定ULP专用消息来通知远程对等设备数据是通过WskRdmaPut操作来传送的。
WskRdmaMapBuffer：实现RDMA存储器寄存操作并向用户返回STag。该STag通常为存储器域STag。此API的用户能够通过设置合适的标志来指定要生成什么类型的STag。返回的STag是有效状态，并即可被用于将来的RDMA数据传输操作。
WskRdmaInvalidateMap：实现RDMA存储器无效操作。它取STag，并使用PostSQ无效操作来无效该STag(设置其状态为无效)。
WskRdmaAllocateSTag：实现RDMA“分配STag”动词。它取STag，并解除对其的分配(无论该STag是用WskRdmaMapBuffer还是用WskRdmaAllocate创建的)。
Ioctls：由WSK RDMA接口提供给应用程序以便它能操作RDMA状态的几个Ioctls：
(1)SIO_RDMA_RESERV_RESOURCE被调用以在RDMA连接建立(RD，CQ和QP)之前保留RDMA资源和(2)SIO_RDMA_SWITCH_TO_RDMA_MODEB被调用以将现有的已连接套接字
(在流模式中)切换到RDMA模式。
RAL代理接口与SDP(套接字直接协议)交互以启用内核旁路RDMA。至RAL代理的接口是控制接口，这样它就能显著地比WSK API更精细。RAL代理控制接口允许RAL代理为本地存取的缓冲直接操纵PD、CQ、存储器窗口和STag。但是，WSK API的诸如序列约束等的所有其他约束均适用。要注意的是，数据传输并不是通过该控制接口进行的：建立起一QP用于直接用户模式存取，从而所有发送和接收数据由用户模式应用程序直接从和向RNIC 308发送和接收的。
RDMA模块300使用传输层接口302与TCP烟囱模块310对话以开始和终止(或上载)TCP连接。一旦连接被卸载到RNIC 308，则RDMA模块300就直接与NDIS迷你端口驱动器306交互来访问RNIC迷你端口。为了支持RAL代理，RDMA模块300可以通过传输层接口302添加和移除TCP监听请求。
示例性RDMA体系结构的说明
初始化
用NDIS进行RNIC初始化有三个部分：(1)告示RNIC卸载能力，(2)告示卸载处理程序，和(3)提供调用处理程序。
(1)NDIS通过调用MINIPORT_REQUEST_HANDLER以在初始化时查询RNIC迷你端口的能力来从迷你端口获得卸载能力。NDIS发出NdisRequest来查询具有OID_TCP_OFFLOAD_TASK的信息。RNIC迷你端口通过完成例程返回返回由RNIC所支持的卸载任务的列表。在卸载任务列表的末端，存在任务结构，它的任务类型等于RdmaChimneyOffloadNdisTask。该任务结构的TaskBuffer字段包含NDIS_TASK_RDMA_OFFLOAD结构。该结构包含RNIC根据动词规范告示的变量的列表。
(2)迷你端口向NDIS告示其分派例程。存在两种类型的烟囱卸载处理程序：通用卸载处理程序和烟囱专用卸载处理程序。通用烟囱卸载处理程序(和它们的完成处理程序)在所有类型的烟囱上被共享。它们包括InitiateOffload(发起卸载)，TerminateOffload(终止卸载)，UpdateOffload(更新卸载)，和QueryOffload(查询卸载)。由于RDMA烟囱是建立在TCP烟囱之上的，因此RDMA卸载与TCP烟囱使用相同的一组通用卸载处理程序。当迷你端口初始化其TCP烟囱时，通用卸载处理程序被告示给NDIS。烟囱专用卸载处理程序专用于一种类型的烟囱并由不同的烟囱单独地向NDIS告示。RDMA烟囱为使用最为频繁的动词，例如“张贴SQ”和“张贴RQ”等中的一些定义RDMA专用卸载处理程序。对于RDMA，动词的更新和查询类型被“嵌入”到这两种RDMA专用卸载处理程序RdmaOffloadOffloadUpdateHandler和RdmaOffloadOffloadQueryHandler中。例如，查询QP被实现为RdmaOffloadOffloadQueryHandler的操作码。
为了设置RDMA专用卸载处理程序，迷你端口调用NdisSetOptionHandler。
NDIS_STATUS
NdisSetOptionalHandlers
(
        NDIS_HANDLE                                  NdisHandle，
        PNDIS_DRIVER_OPTIONAL_HANDLERS    OptionalHandlers
)
NdisHandle是当迷你端口向NDIS注册时给予该迷你端口的句柄。
OptionalHandler是迷你端口想要给予NDIS的RDMA专用卸载处理程序。
为迷你端口定义了以下的结构用于存储RDMA专用卸载处理程序。迷你端口在将该结构传递到上述函数中之前设置以下字段：NDIS_OBJECT_HANDER的类型字段被设为NDIS_OBJECT_TYPE_PROVIDER_CHIMNEY_OFFLOAD_CHARACTERISTICS；字段OffloadType被设为：NdisRdmaChimneyOffload；而RDMA专用卸载处理程序被设为相应的迷你端口分派例程。
typedef struct_NDIS_PROVIDER_CHIMNEY_OFFLOAD_RDMA_CHARACTERISTICS
{
        NDIS_OBJECT_HEADER Header；
        //Header.Type＝NDIS_OBJECT_TYPE_PROVIDER_CHIMNEY_OFFLOAD_CHARACTERISTICS
        ULONG Flags；
        //目前尚未被NDIS使用。
        NDIS_CHIMNEY_OFFLOAD_TYPE OffloadType；
        //将此字段设为NdisRdmaChimneyOffload。
        //RDMA专用卸载处理程序转至此处：
        MINIPORT-RDMA_OFFLOAD_POST_SQ_HANDLER RdmaOffloadPostSQHandler；
        MINIPORT_RDMA_OFFLOAD_POST_RQ_HANDLER RdmaOffloadPostRQHandler；
        MINIPORT_RDMA_OFFLOAD_POLL_CQ_HANDLER RdmaOffloadPollCQHandler；
        MINIPORT_RDMA_OFFLOAD_UPDATE_HANDLER RdmaOffloadUpdateHandler；
        MINIPORT_RDMA_OFFLOAD_QUERY_HANDLER RdmaOffloadQueryHandler；
        MINIPORT_RDMA_OFFLOAD_REQUEST_COMPLETION_NOTIFICATION_HANDLER
             RdmaOffloadRequestCompletionNotificationHandler；
        MINIPORT_RDMA_OFFLOAD_SET_COMPLETION_EVENT_HANDLER_HANDLER
             RdmaOffloadSetCompletionEventHandlerHandler；
 }NDIS_PROVIDER_CHIMNEY_OFFLOAD_RDMA_CHARACTERISTICS，
 *PNDIS_PROVIDER_CHIMNEY_OFFLOAD_RDMA_CHARACTERISTICS；
(3)迷你端口通过调用NdisMGetOffloadHandler API从NDIS获得RDMA烟囱专用的完成处理程序和事件处理程序。
VOID
NdisMGetOffloadHandlers
(
      IN NDIS_HANDLE                      NdisMiniportHandle，
      IN NDIS_CHIMNEY_OFFLOAD_TYPE        ChimneyType，
      OUT PNDIS OFFLOAD EVENT HANDLERS    *OffloadHandlers
)；
对于RDMA烟囱，迷你端口应当设置烟囱类型等于NdisRdmaOffload。NDIS接着返回以下的包含RDMA专用的完成处理程序和事件处理程序的结构。
typedef struct_NDIS_RDMA_OFFLOAD_EVENT_HANDLERS
{
         NDIS_OBJECT_HEADER Header；
         //Header.Type＝＝NdisRdmaChimneyOffload.
         NDIS_RDMA_OFFLOAD_ASYNCHRONOUS_EVENT_INDICATE_HANDLER
               NdisRDMAAsynchronousEventlndicate；
         NDIS_RDMA_OFFLOAD_UPDATE_COMPLETE_HANDLER
               NdisRdmaOffloadUpdateCompleteHandler；
         NDIS_RDMA_OFFLOAD_QUERY_COMPLETE_HANDLER
               NdisRdmaOffloadQueryCompleteHandler；
   }NDIS_RDMA_OFFLOAD_EVENT_HANDLERS，
    *PNDIS_RDMA_OFFLOAD_EVENT HANDLERS；
每当有接口被上提或下放，RDMA模块300都需要由TCP卸载模块通知。RDMA模块300还需要由TCP卸载模块通知在其初始化时所有现有的接口。在被通知了接口事件之后，RDMA模块300具有对该接口的NDIS句柄，并接着能用NDIS为该接口注册向上调用。在这之后，RDMA模块300可以开始为RDMA卸载目的使用此接口。
发起时，RDMA卸载模块使用以下的分派表来注册对TCP卸载模块的向上调用。
typedef struct_TL_OFFLOAD_CLIENT_DISPATCH
{
        USHORT                                    Version；
        USHORT                                    Length；
        USHORT                                    UpperLayerProtocolld；
        //这是使用TCP卸载模块的协议ID。
        PTL_OFFLOAD_CLIENT_ADD JNTERF ACE          Addlnterfacelndicate；
        PTL_OFFLOAD_CLIENT_DELETE_INTERFACE  Deletelnterfacelndicate；
        ....
        <卸载所使用的其它客户机分配例程，例如发起卸载完成。>
        ....
}TL_OFFLOAD_CLIENT_DISPATCH，*PTL_OFFLOAD_CLIENT_DISPATCH；
向上调用TL_OFFLOAD_CLIENT_ADD_INTERFACE定义如下：
typedef
VOID
(NTAPI*PTL_OFFLOAD_CLIENT_ADD_INTERFACE)
(
      IN PTL_OFFLOAD_INDICATE_INTERFACE           Args，
      IN CONST TL_OFFLOAD_INTERFACE_CHARACTERISHCS    *TLCharacteristics
)；TL_OFFLOAD_CLIENT_DELETE_INTERFACE除了名字外，其函数特征与添加接口调用完全一样。
当在系统中上提新的接口或当RDMA模块300向TCP卸载模块注册时，TCP卸载模块调用上述对RDMA模块300的“添加接口通知”向上调用。对于后一种情形，接口可以是已在系统中被上提的，并且TCP卸载模块需要为每个现有的接口调用向上调用。
为了发起RDMA卸载处理，RDMA模块300调用TCP卸载模块的发起卸载函数，因为RDMA是TCP的附属协议。由此，RDMA模块300需要从TCP模块获得发起卸载处理程序，并向TCP模块设置相应的完成处理程序。这两组处理程序是通过传输层接口302来交换的。
以下是由TCP模块提供给RDMA模块300的发起卸载处理程序及其完成处理程序的定义：
typedef
NTSTATUS
(*PTL_PROVIDER_OFFLOAD_INITIATE_OFFLOAD)
(
       HANDLE                          TCPConnectionHandle，
       PNDIS_PROTOCOL_OFFLOAD_BLOCK    OffloadBlock
)
typedef
VOID
(*PTL_CLIENT_OFFLOAD_INITIATE_OFFLOAD_COMPLETE)
(
      PNDIS_PROTOCOL_OFFLOAD_BLOCK     OffloadBlock
)
第一个是发起卸载处理程序。它在已经建立的TCP连接上发起RDMA卸载。第二个是完成处理程序。除了上述发起卸载处理程序之外，还有终止卸载、更新卸载、和查询卸载处理程序、以及它们各自的完成处理程序。
卸载处理程序在TL客户端和提供者之间按以下方式交换。当一TL客户端被绑定到一TL提供者时，它被提供以下的结构：
typedef struct_TL_PROVIDER_DISPATCH
{
         PTL_PROVIDER_IO_CONTROL    IoControl；
         PTL_PROVIDER_QUER
Figure S2006800162654D00121
_DISPATCH              QueryDispatch；
         PTL_PROVIDERJENDPOINT      Endpoint；
         PTL_PROVIDER_MESSAGE       Message；
         PTL_PROVIDER_LISTEN        Listen；
         PTL_PROVIDER_CONNECT       Connect；
         PTL_PROVIDER_RELEASE_INDICATION_LIST  ReleaseIndicationList；
         PTL_PROVIDER_CANCEL        Cancel；
}TL_PROVIDER_DISPATCH，*PTL_PROVIDER_DISPATCH；
在该结构中，具有QueryDispatch函数。该QueryDispatch函数用来在TL客户端与TL提供者之间交换扩展的分派例程。卸载分派例程在语义上被认为是“扩展”的TLNPI接口的一部分。由此，调用该QueryDispatch函数来交换卸载处理程序。该QueryDispatch函数定义如下：
typedef
NTSTATUS
(NTAPI*PTLPROVIDER_QUERY_DISPATCH)
(
      IN HANDLE                          ClientHandle，
      IN PTL_REQUEST_QUERY JDISP ATCH    QueryDispatchRequest_.
)；
使用以下数据结构来交换调用处理程序：
typedef struct_TL_REQUEST_QUERY_DISPATCH
{
         IN PTL_CLIENT_CREATE_REQUEST_COMPLETE    RequestComplete；
         IN PVOID                                 RequestContext；
         IN PNPIID                                NpiId；
         IN CONST VOID                            *ClientDispatch；
         OUT CONST VOID                           *ProviderDispatch；
}TL_REQUEST_QUERY_DISPATCH，*PTL_REQUEST_QUERY_DISPATCH；
以上结构中的ClientDispatch包含卸载向上调用处理程序。它包含至少以下处理程序：
{
        TLOffloadAddlntertacelndicate，
        TLOffloadDeletelnterfacelndicate，
        TLOffloadlnterfaceWillGoDownlndicate，
        TLOffloadlnitiateOffloadComplete，
        TLOffloadTerminateOffloadComplete，
        TLOffloadUpdateOffloadComplete，
        TLOffloadQueryOffloadComplete
}
以上结构中的ProviderDispatch包含卸载向下调用处理程序。它包含至少以下处理程序：
{
        TLOffloadlnitiateOffload，
        TLOffloadTerminateOffload，
        TLOffloadUpdateOffload，
        TLOffloadQueryOffload
}
为了避免RDMA连接卸载发起期间可能发生的竞态情况，RDMA模块300请求TCP层刷新所有预张贴的接收缓冲。而且，在状态转移中的某个点，RDMA模块300忽略从TCP层接收的所有指示。这里有一由TLNPI层提供并由RDMA模块300调用的用于刷新一连接上所有的预张贴的接收缓冲。
NTSTATUS
TLFlushReceiveBuffer
(
       HANDLE        EndPointHandle
)
如果没有预张贴的缓冲，则TCP模块什么也不做，仅返回STAUS_SUCCESS。如果存在任何预张贴的缓冲(预张贴的接收请求)，则无论迄今接收到多少比特均将它们完成。(最为可能的是它们将以零比特完成)。如果TCP连接已经被卸载到RNIC，并且如果在硬件上存在任何预张贴的缓冲，则因为硬件中没有刷新预张贴的接收缓冲的机制，所以TCP层将首先把该连接上载至软件堆栈，然后刷新接收缓冲。
示例性RDMA体系结构的说明
卸载
本节将参考表示卸载过程的一系列工作流程图进行例示。在这些图中的调用中，“W”是指“WSK”，而“R”是指RDMA模块300，而“M”是指RNIC迷你端口。因此，例如“WR”表示在WSK模块与RDMA模块300之间的调用。
对于由不同模块提供的API，命名惯例为：
·WskRdmaXXX：由WSK提供给用户的WSK RDMA扩展API。
·TL_XXX(或TLXXX)：由TCP层提供并由RDMA模块300调用的API。
·MINIPORT_RDMA_OFFLOAD_XXXX：RNIC迷你端口分派例程。它们由迷你端口提供并由NDIS调用。
在本文档中的API函数特征仅为示例性目的给出，并且在实现中可能会改变。
对于WSK层，套接字可以具有以下的状态：StreamingMode、RdmaTranstionInProgress或RDMAMode。对于RDMA模式300层，连接可以具有以下状态：NotReadyToOffload、ResourceReservationInProgress、ReadyToOffload、WaitForFirstRecvBuffer、OffloadInProgress或Offloaded。
图4描绘了用来保留RDMA烟囱资源的调用序列。它由WSK异步Ioctl调用SIO_RDMA_RESERVE_RESOURCE在400处发起。WSK模块或RAL代理模块可以作出此调用。这是由RDMA模块300的消费者作出的第一次调用。如果没有传入可任选参数，则传递到RNIC 308的默认值为：这个RDMA QP的IRD和ORD(传入的RDMA读请求和传出的RDMA读请求)由RDMA模块300在运行时确定以适应当前的系统负荷；EnableRDMARead和EnableRDMARWrite默认为TRUE；而LengthOfSQ和LengthOfRQ由RDMA模块300在运行时间确定以适应当前的系统负荷。该API在用户可以调用RDMA模块300的任何其他API之前在402处被调用并以STATUS_SUCCESS完成。它返回所分配的实际资源，其可以与所请求的资源不同。所有的交互都在内核模式中发生。
402是调用400的完成例程。如果它返回STATUS_SUCCESS，则意味着RDMA层已经成功地为QP分配了所需的资源，并且这个RDMA烟囱已准备好被卸载。它还返回为该连接分配的实际属性。如果它返回任何出错代码，则意味着分配失败。
WR1向前调用从WSK向RDMA模块300的SIO_RDMA_RESERVE_RESOURCE Ioctl请求。这个调用本质上启动RDMA模块300中的状态机。RDMA模块300为每个连接维护一单独的状态机。这个调用的成功完成将连接置于ReadToOffload状态。虽然这个调用是未决的，但是该连接的状态为ResourceReservationInProgress。该API由RDMA模块300为WSK模块提供：
RDMAOffloadAllocateOffloadResource
(
    IN HANDLE             TCPConnectionHandle，
    IN ULONG              IRD                  可任选，
    IN ULONG              ORD                  可任选，
    IN BOOL               EnableRDMARead       可任选，
    IN BOOL               EnableRDMAWrite      可任选，
    IN ULONG              LengthOfSQ           可任选，
    IN ULONG              LengthOfRQ           可任选，
    IN HANDLE             RelatedConnection    可任选，
    IN HANDLE             CompletionRoutine，
     IN HANDLE     RequestContext
)
WR1-C是WR1的完成例程，并且它指示该调用的结果。如果返回的结果为STATUS_SUCCESS，则QP属性的实际值也被返回。
typedef
VOID
(*RDMA_OFFLOAD_ALLOCATE_OFFLOAD_RESOURCE_COMPLETE)
(
      IN HANDLE      RequestContext，
      IN ULONG       ActualIRD，
      IN ULONG       ActualORD，
      IN ULONG       ActualLengthOfSQ，
      IN ULONG       ActualLengthOfRQ，
      IN NTSTATUS    CompletionStatus，
      IN ULONG       CompletionReasonCode
)
RM1潜在地为由RDMA模块300向RNIC迷你端口作出的创建QP的一系列调用。为了创建QP，迷你端口需要被提供保护域ID和完成队列句柄。多个QP可以共享一个PD和一个CQ。RDMA模块300基于PD/CQ共享策略来决定要被创建的QP是否将与其他QP共享PD或CQ。对于WSK接口，默认PD在每连接的基础上唯一性的，但消费者具有将不同的连接放入一个PD中的选择。CQ在有限数目的QP间被共享。对于RAL代理接口，没有默认值：RDMA模块300本质上向RAL代理直接曝露出能为创建PD、CQ和QP设置的所有参数。如果RDMA模块300决定应为此QP创建新的PD/CQ，则调用以下分派例程。
RM1-PD是一用于创建PD的异步调用。一旦成功完成，保护域ID(PDID)就被创建。根据NDIS API，该调用被以“创建PD”作为其操作码嵌入到“更新卸载”调用中。
RM1-AllocateSTag为Fast-Register分配一组STag。
RM1-CQ创建CQ或修改先前创建的CQ。创建CQ的调用是异步的，并指定该CQ的长度。该长度是共享该CQ的各RQ和各SQ(发送队列)的长度的之和。当有更多的SQ和RQ与该CQ相关联时，CQ的长度可以改变。根据NDIS API，创建CQ调用被以“创建CQ”作为其操作码嵌入到“更新卸载”调用中。在CQ已经被成功地创建后，对新的CQ请求完成通知。RDMA动词规范要求如果在有CQE(完成队列事件)被排队时请求了通知，则QP的消费者请求CQ的完成通知。否则，如果任何事物被排队到该CQ中，则不再调用完成事件处理程序。
当RM1-CQ被调用来修改现有CQ时以下适用。(1)如果RDMA模块300决定该QP能与其他QP共享CQ，则它从其内部表检索要被共享的现有CQ的句柄。但是，现有CQ的大小可能不足以适应新的QP，因此它可能需要由“修改CQ”动词来实现。(2)“修改GQ”在RM1-QP(创建QP)调用之后被调用。RDMA模块300首先试图创建所需大小的QP，并且如果QP的创建成功了，则它试图修改将由新创建的QP共享的的现有CQ。(3)如果CQ不能被增大来适应外加的QP，则创建新的CQ。(4)根据NDIS API，这个调用被以“修改CQ”作为操作码嵌入到“更新卸载”调用中。(5)对CQ的调整大小操作是昂贵的，并可能影响与被调整大小的CQ相关联的QP的操作。RDMA模块300试图以尽可能少的次数来调整CQ的大小，并仅将合理数目的QP与一CQ相关联。
RM1-QP创建QP。在创建了PD ID和CQ句柄之后，RDMA模块300层调用“创建QP”动词来为该连接创建QP。如果RM1-CQ调用是要修改现有CQ，则这个调用在RM1-CQ调用之前作出。换句话说，首先创建一QP，接着修改该CQ来适应该新QP。根据NDIS API，该调用被以“创建QP”作为操作码嵌入到“更新卸载”调用中。
RM1-C-QP、RM1-C-PD、和RM1-C-CQ是对应于上述原始调用的完成处理程序。
当“创建QP”的完成处理程序被调用时，用于该连接的RNIC状态已经被分配。PD、CQ和QP被初始化。(QP处于空闲状态)。RDMA模块300以相应的状态和原因码调用WR1-C。完成链最终弹出到WSK或RAL代理消费者面前，并且这完成了保留RDMA卸载资源的Ioctl调用。在这个过程成功完成时，RDMA模块300将连接状态设为ReadyToOffload。
在RDMA资源已经被成功地分配之后，消费者可能希望在转移到RDMA模式之前交换外加的配置信息。可通过WSK接口改变的唯一参数是RDMA读资源(IRD和ORD)的量。此调用可在连接处于流模式或RDMA模式中时作出。如果存在对WskRdmaGet()的未解决的调用，则RDMA模块300以出错来完成此调用。如果没有未解决的WskRdmaGet()调用，则ORD值可被改变。IRD值应当仅于在链路上没有RDMA读请求到达时才被改变。如果有，则改变IRD将会导致连接被拆卸。对于一些应用程序，需要先改变该值才能生成任何RDMA读。对于其他的应用程序，在作出改变之前进行应用程序专用的协商来刷新RDMA。要注意的是，IRD和ORD两者皆被指定。如果不需要改变，则应当使用来自最新调用的设置RID或ORD资源的值。
在图5中，作出改变RDMA读资源的请求。RR1-WR仅仅是将该请求结构传递给RDMA模块300。如果没有未解决的RDMA读请求，则RDMA模块300接着发出“修改QP”(RR1-RM)来改变RDMA读资源。要注意的是，预期在QP仍然处在IDLE状态中时改变IRD将总是成功的。
图6示出了向RDMA模式的转移。在步骤600之前，消费者知道在当前连接上的RDMA烟囱资源已经被分配但尚未被启用。对消费者有以下要求。
·消费者确保向RDMA模式转移的请求仅在来自远程对等设备的最新流模式消息被接收到之后作出。这清楚地定义了在传入的一半TCP流上在TCP模式与RDMA模式之间的转移。消费者以他之际与远程对等设备的协议来确保此实现。在最新的流模式消息之后的所有传入话务都被预期为iWARP模式。
·消费者在该调用之后不能再张贴任何传统套接字WskRecv调用。对于这样的试图将返回内联出错。所有未解决的在该调用602之前已经张贴但还没有完成的WskRecv调用都以零子节完成。
·在该调用602之后并在第一个WskRdmaRecv调用606之前，消费者可以张贴一个或多个WskSend调用。在此期间由消费者张贴的最新WskSend调用为最新传出的流模式消息。
·消费者需要张贴第一个WskSend调用606，否则，RDMA卸载处理就不会开始。
WSK设置这个连接的状态为“RdmaTransitionInProgress”并将此连接一直保持在这个状态直到它接收到卸载的成功完成(608)。当608被调用时，连接已被切换到RDMA模式。WSK将此连接的状态移到“RDMAMode”
就在WSK移到“RDMATransitionInProgress”状态之后，它刷新接收缓冲并开始忽略来自TCP层的任何接收指示。它为来自TCP层的所有接收指示向上调用返回STATUS_DATA_NOT_ACCEPTED。通过如此，它实际上请求TCP层处理所有的传入数据然后缓冲它们。稍后，缓冲的数据被转发到RNIC 308。这是避免在RDMA卸载发起时可能发生的竞态情况所需要的。而且，就在WSK移到“RDMATransitionInProgress”状态之后，它所有的对TCP层的预张贴的接收请求(如果有任何的话)都以特定数目的子节(最可能是零子节)完成。
在2，由WSK适用以下的API来通知向RDMA模式的转移。该API请求TCP堆栈刷新所有预张贴的接收缓冲。(TLNPI应当为此目的而曝露一API)。而且，此API在RDMA模块300中将此连接的状态设为“WaitForFirstRecvBuffer”状态，其为在卸载实际开始之前的最新状态。要注意的是，TCP状态可在主机堆栈中，或者它也可以已经被卸载了。
NTSTATUS
RDMAOffloadStartOffload
(
    IN HANDLE             TCPConnectionHandle，
    IN HANDLE             CompletionRoutine，
    IN HANDLE             RequestContext
)
以下的调用由RDMA模块300层对TCP层作出。它请求TCP层刷新所有预张贴的接收缓冲。该调用由TLNPI接口指定。
NTSTATUS
TLFlushReceiveBuffer
(
       IN HANDLE        EndPointHandle
)
在604，消费者可以在TCP流的传出的一半上执行一个或多个正常的TCP发送。这个特征可以被一些ULP用来建立RDMA连接。如果ULP请求最新的流模式消息被发送给远程对等设备以触发远程对等设备切换到RDMA模式，则该最新的流模式消息在此步骤中被发送，也就是说，在调用2后并在步骤606之前。在消费者已经发送了他的最新的流模式消息给远程对等设备之后，消费者张贴第一RDMA接收请求606来触发实际转移处理并通知RDMA模块300已经发送了最新的流模式消息。在步骤606之后，消费者不能再发送任何流模式消息。
不要求消费者在作出调用4(WskRdmaRecv)之前等待调用3(WskSend)完成。由此，在TCP层完成发送最新流消息之前消费者就作出调用4来触发卸载处理是可能的。换句话说，在针对最新的流消息的TCP ACK被接收到之前，或甚至在TCP层发送出最新的流消息之前，可以由消费者作出调用4。如果这发生了，则RDMA模块300在它为消费者实际开始执行调用4之前等待调用3完成。这有助于解决很多在未完成的传出流模式消息已经被下放到RNIC 308作为RDMA卸载模式的一部分的情况下可能会发生的竞态状况。这意味着，RNIC 308不需要同时具有双模式来支持流模式和RDMA模式话务两者。当硬件处于RDMA模式时，这使RNIC 308被从重新传送最新的流模式消息的复杂情况中被释放。从RNIC 308的观点来看，没有最新的流模式消息要发送：该消息应当已经由软件堆栈在卸载发起之前就发送了(并且接收到了TCP ACK)。这还意味着，在RDMA卸载发起之际或之后，没有传出的流模式消息被向下转发到RNIC 308。
在步骤606，消费者作出WskRdmaRecv调用，并且实际的RDMA卸载处理开始。消费者应当能够基于他的应用程序和协议需求来估算首先传入的RDMA消息的大小。此调用被设计成在进入RDMA模式时避免潜在的竞态状况。如果消费者没有被要求在进入RDMA模式之前就预张贴缓冲，则远程对等设备就可能在消息者有时间张贴接收缓冲(在向RDMA模式的转移完成之后)之前就发送DMAPSend类型的消息。如果这发生了，则连接应当被拆卸。由此API需要消费者预张贴至少一个缓冲。在WSK得到4处的调用之后，它通过调用WR4(在图6中未示出)将请求转发给RDMA模块300。
WR4是由RDMA模块300提供来让用户在请求向RDMA模式转移之后传入接收缓冲的API。WR4向RDMA模块300层张贴RDMA接收缓冲，并通过调用TCP卸载函数来启动卸载处理。WR4 API指定如下：
RDMAOffloadPostFirstReceiveBuffer
(
    IN HANDLE                  TCPConnectionHandle，
    IN PWSK_BUFLIST            LocalReceiveBufferList，
    IN PWSK_RDMA_LOCAL_BUFSGL  LocalBufferSGL，
    IN HANDLE                  CompletionRoutine，
    IN HANDLE                  RequestContext
)
此API的用户必须仅传入LocalReceiveBufferList和LocalBufferSGL.中的一个。
WR4调用是在RDMA模块300中如下实现的：
·RDMA模块300首先为该连接查看其内部状态机以检查它是否处于“WaitForFirstRecvBuffer”状态。如果不是，则它立即返回出错码。而且，如果流模式发送未决，则RDMA模块300等待它完成再继续以下步骤。
·RDMA模块300为该连接将其状态机设为“OffloadInProgress”。它还准备RDMA_OFFLOAD_STATE数据结构。在该数据结构中存在QP句柄。该QP由消费者在该连接的资源保留阶段期间创建。
·如果PWSK_BUFLIST不是NULL，则RDMA模块300将PWSK_BUFLIST转换成分散/集中元列表：(1)RDMA模块300向RNIC 308注册在此缓冲列表中的缓冲以得回本地Stag列表。(2)RDMA模块300使用通过上述步骤获得的STag作出SGL。(3)由RDMA模块300为用户注册的本地STag由RDMA模块300在接收请求完成时无效。(4)参数PWSK_RDMA_LOCAL_BUFSGL必须为NULL。如果不是，则RDMA模块300直接使用此SGL。也就是说，如果该参数不为NULL，则当接收请求完成时RDMA模块300不使SGL中所包含的STag无效。
·RDMA模块300调用PostRQ来将缓冲张贴到RQ。
·RDMA模块300准备NDIS_PROTOCOL_OFFLOAD_BLOCK并将RDMA_OFFLOAD_STATE挂钩入该数据结构。
·RDMA模块300进行发起TCP卸载的调用RT4c(参见以下)。这里存在两种情形：(1)如果TCP连接之前没有被卸载，则TCP层没有卸载句柄。它启动新的卸载处理并构建NDIS_PROTOCOL_OFFLOAD_BLOCKTCP卸载数据结构，其中RDMA卸载块作为从属块被指向。(2)如果TCP连接已经被卸载了，则TCP层具有卸载句柄，并且它仅仅是将RDMA块链到该列表的末端并将其传递到RNIC 308。
RT4c是由TCP层提供的发起卸载调用。RDMA模块300传入具有RDMA_OFFLOAD_STATE的NDIS_PROTOCOL_OFFLOAD_BLOCK。
typedef
NTSTATUS
(*PTL_PROVIDER_EXTENSION_INITIATE_OFFLOAD)
(
      HANDLE                                TCPConnectionHandle，
      PNDIS_PROTOCOL_OFFLOAD_BLOCK          OffloadBlock
)
RDMA_OFFLOAD_STATE块定义如下：
typedef struct_RDMA_OFFLOAD_STATE
{
        IN ULONG                OpCode；
        OUT ULONG               RDMAReasonCode；
        union
        {
             struct
             {
                     HANDLE    QPHandle；
              }StatesTolnitiateOffload
              struct
              {
                      PVOID            InputBuffer；
                      ULONG            InputBufferLength；
                      PVOID            OutputBuffer；
                      ULONG            OutputBufferLength；
              }StatesToBeUpdatedOrQueried；
     }StateCategory；
}RDMA_OFFLOAD_STATE，*PRDMA_OFFLOAD_STATE；
涉及本讨论的字段为QPHandle，其为此链接将使用的QP。以上的结构被挂钩入NDIS)_MINIPORT_OFFLOAD_BLOCK中。
由TCP烟囱作出一组调用来启动其卸载处理。这设法用卸载状态块的链接列表向下去到RNIC 308。在该链接列表中，RDMA协议卸载块为TCP协议卸载块的从属块。由此，迷你端口知道此TCP连接也将作为RDMA连接被卸载。QP句柄被包含在RDMA OFFLOAD STATE块中，并且它将是为这个连接使用的QP。完成例程由RNIC迷你端口向TCP烟囱调用来指示卸载已经被完成。它指示TCP和RDMA卸载两者都已经被完成了。
TCP层向RDMA模块300通知完成。这个是对应于调用RT4c的完成例程。此时，RDMA模块300被通知RDMA卸载已经完成了，并且它立即采取两个行动；
(1)它通知调用2的完成，调用2是由用户作出以发起RDMA卸载处理的第一个调用。这个完成不是针对WR4作出通知的，因为那是张贴接收缓冲的接收调用，并不应当在接收接收缓冲填满之前被完成。WR4调用将在稍后由WR4-C来完成。
(2)RDMA模块300将其对应于此连接的内部状态机设为卸载状态。该完成调用的原型为：
typedef
VOID
(*PTL_CLIENT_EXTENSION_INITIATE_OFFLOAD_COMPLETE)
(
      PNDIS_PROTOCOL_OFFLOAD_BLOCK         OffloadBlock
)
一旦接收对应于启动卸载调用的完成指示，WSK层将该连接的状态设定为RDMA模式。此完成例程由RDMA模块300层调用并被定义如下：
typedef
VOID
(*RDMA_OFFLOAD_START_OFFLOAD_COMPLETE)
(
     IN HANDLE          RequestContext，
     IN NTSTATUS        CompletionStatus，
     IN ULONG           CompletionReasonCode
)
对应于调用2的完成例程——将套接字设置成RDMA模式的WSK Ioctl调用\由WSK层向WSK的用户调用。一旦此时接收到成功的完成，则WSK的用户就可以确信RDMA连接已经被卸载并且新的RDMA请求可以在这个连接上被张贴。WSK设置该套接字的状态为“RDMA模式”。
WR4-C是用于WR4调用的完成例程。它由RDMA模块300在从RNIC 308接收到CQ完成指示后由RDMA模块300调用。从CQ检索到的CQE指示在卸载开始时由WR4张贴的接收缓冲已被填满。接收完成例程定义如下：
typedef
VOID
(*RDMA_OFFLOAD_RECEIVE_COMPLETE)
(
     IN HANDLE          RequestContext，
     IN ULONG           BytesReceived，
     IN NTSTATUS        CompletionStatus，
     IN ULONG           CompletionReasonCode
)
调用4的完成例程指示所张贴的接收缓冲已经被以RDMA数据填满。
为了总结WSK状态，WSK在消费者作出调用2之前处于StreamingMode，就在调用2之后并在调用2完成之前处于RdmaTransitionInProgress，而就在调用2之后处于RDMAMode，虽然WSK处于StreamingMode，但消费者可以调用：
所有WSK正常API(WskSend，WskRecv等)，
SIO_RDMA_RESERVE RESOURCE，SIO_RDMA READ_RESOURCES，
SIO_RDMA_SWFTCH_TO_RDMA_MODE，WskRdmaAllocateSTag，
WskRdmaDeallocateSTag，以及WskRdmaMapBuffer但不能调用：
WskRdmaMapAndSend，WskRdmaRecv，WskRdmaPut，或WskRdmaGet，而当WSK处于RdmaTransitionlnProgress时，消费者可调用
WskSend(在WskRdmaRecv被调用之前是允许的)，WskRdmaRecv，
WskRdmaAllocateSTag，WskRdmaDeallocateSTag，WskRdmaMapBuffer，以及
SIO RDMA READ RESOURCES
但不能调用：
所有其它WSK API，SIO_RDMA_RESERVEJRESOURCE，
SIO_RDMA_SWITCH_TO_RDMA_MODE，WskRdmaPut，WskRdmaGet，
WskRdmaMapAndSend，或
WskSend(在WskRdmaRecv被调用之后是不允许的)。
当WSK处于RDMAMode时，消费者可调用：
SIO_RDMA_READ_RESOURCES，WskRdmaMapAndSend，WskRdmaRecv，
WskRdmaPut，WskRdmaGet，WskRdmaAllocateSTag，
WskRdmaDeallocateSTag，
WskRdmaMapBuffer，以及WskDisconn
但不能调用：
WSK正常API，除了WskDisconn，
SIO_RDMA_RESERVE_RESOURCE，或
SIO_RDMA_SWITCH_TO_RDMA_MODE.
在RNIC 308已经将TCP流转移到RDMA模式之后，传入的数据可能已由TCP层缓冲。如以上所讨论的，在RDMA烟囱卸载期间，没有传出的流模式数据被转发到RNIC 308。RNIC 308并不需要发送最新的流模式消息：该消息应当在卸载发起之前已经被由软件堆栈发送(并且接收到了TCP ACK)。但是，RNIC 308不需要处理在RDMA卸载处理之前以及期间接收到的传入的RDMA模式数据。那些数据要么被向下传递到RNIC作为TCP卸载委托状态的一部分，要么通过TCP转发接口转发给RNIC。
存在其中远程对等设备甚至在本地对等设备发起卸载之前就可能开始发送RDMA模式数据的潜在的竞态条件。在这种情形中，TCP软件堆栈接受所有的传入数据，对这些数据进行正常的TCP协议处理，并在其缓冲中缓冲TCP有效载荷。“TCP有效载荷”实际上是包括MPA标记、DDP报头、RDMA报头等的RDMA协议数据。在此阶段接收到的数据被以发起卸载调用向下传递到RNIC作为TCP委托状态。RNIC 308将这些数据作为纯RDMA数据来处理。它们已经由软件堆栈进行“TCP处理”(TCP CRC已检验、TCP ACK已发送，等等)。
RDMA数据还可以在卸载处理期间传入，即，RDMA模式数据可以在RDMA模块300对RNIC 308请求发起卸载之后并在RNIC 308完成此卸载请求之前传入。在这种情形中，TCP软件堆栈接受所有传入的数据并缓冲它们作为原始数据。不对这些数据执行任何TCP协议处理。只要卸RNIC 308一通知卸载完成，TCP层就通过TCP转发接口向RNIC 308转发在此阶段期间缓冲的所有传入的原始数据。RNIC 308首先对这些转发的原始数据进行“TCP处理”，接着处理TCP有效载荷作为RDMA数据。
为进行资源分配，有两种类型的出错：可恢复的出错和不可恢复的出错。可恢复的出错是在用户的资源需求超出RNIC 308的容量时引发的，例如“创建QP”因为所请求的IRD/ORD太大而失败，或者“修改CQ”因为新的CQ大小不能被支持而失败。RDMA模块300返回原因码来向用户指示是什么出了错。接着，用户可以决定重新请求资源保留或仅仅是异常中断。不可恢复的出错包括由RNIC308故障或连接丢失所导致的那些出错。这些出错返回它们自己的出错代码，并且用户可以异常中断卸载企图并在可能的情况下返回出错消息给远程对等设备。不可恢复的出错包括：NIC不是RNIC，未能创建新的PD，以及即便用最小输入值也未能创建QP。在卸载处理期间，如果RDMA卸载失败，则连接被采写而不是切换回TCP流模式。
对于RDMA烟囱卸载，“联动卸载”使用与TCP烟囱相同的算法和设计，但仍然要留意一些外加的步骤：
·在发起联动卸载之前，对每个单独的连接作出并完成保留RNIC资源的请求。
·只有那些已经成功地保留了RNIC资源的连接才应当被包括在联动卸载块列表中。
·从流模式到RDMA模式的转移对每个连接单个并独立地发生。
·RDMA模块300释放为未能卸载的连接保留的任何资源。
示例性RDMA体系结构的说明
状态变量
在资源保留阶段的最后，以下RDMA状态在RNIC 308上被建立：
·QP：与TCP连接句柄相关联的队列对。
·CQ、PD：如果QP没有与其他QP共享CQ/PD，或如果这是新创建的QP，则RNIC 308也为这个QP创建CQ和PD。
·IRD、ORD：这些指定QP的RDMA读能力。
·启用RDMA读/写：这些指定QP是否允许RDMA读/写。
·LengthOfSQ、LengthOfRQ：这些是QP的长度属性。
在卸载开始时，以下状态作为RDMA OFFLOAD STATE块被传入到烟囱驱动器。
QP句柄：RDMA连接将使用的队列对。
在RDMA模块300成功地卸载连接之后，QP具有以下的状态：Idle、RTS、Closing、Terminate和Error。这些状态由RDMA模块300处理，并且它们对用户是不可见的。RDMA模块300通过事件处理程序来通知用户终止，出错，和关闭事件。
STag是RDMA数据传递操作所需的。STag在其被创建后可以具有无效和有效状态。消费者需要跟踪已被告示的本地STag的状态以便于进行远程存取，并在需要时使它们无效。消费者还需要跟踪从远程对等设备接收到的任何远程STag，并且如果需要使它们无效。对于仅为本地存取所使用的本地STag，如果用户想重复使用缓冲，那他可以选择跟踪它们。否则，RDMA模块300透明地地处理这种类型的STag。
示例性RDMA体系结构的说明
完成和异步事件处理
RDMA模块300通过“设置完成事件处理程序”动词来对迷你端口设置完成事件处理程序。RNIC 308可以支持一个以上的完成事件处理程序。每次有一个新的完成事件处理程序被设置，RNIC迷你端口就向消费者返回一个标识符。此标识符是在消费者创建新的CQ时使用的，并将该CQ与完成事件处理程序相关联。这是完成事件处理程序的定义：
typedef
VOID
(*RDMA_OFFLOAD_COMPLETION_EVENT_HANDLER)
(
      IN NDIS_HANDLE    NdisMiniportHandle，
      IN PVOID          CQHandle
)；.
当有CQE排队入CQ并且为该CQ请求了完成通知时，迷你端口调用上述处理程序。完成事件处理程序被给予CQ句柄作为输入。RDMA模块300执行完成事件处理程序如下：
·从CQ一个接一个地轮询CQ并使CQE出列，直到没有CQE剩下。
·对于从CQ收获的每个CQE，对其进行处理：
(1)在CQE中存在工作请求(WR)。这个ID是指向WR上下文的64位指针。
(2)WR的上下文是RDMA模块300的内部数据结构。当RDMA模块300创建WR时它被填充以该WR的相关信息。
(3)在WR的上下文中，具有指向该WR的原始请求方(通常为WSK调用)的指针。
(4)如果由该原始请求方发出的所有WR已经完成了，则原始请求方的完成例程可以被调用。否则，RDMA模块300的一些内部状态被设置以便于积累完成。
·就在该完成事件处理程序返回之前，它再次请求该CQ上的完成通知。
当RDMA模块300创建要张贴到SQ的WR时，它设置大多数WR的完成通知类型为“被通知的完成”。但是，为了避免完成处理的额外开销，RDMA模块300将其中一些WR设为“不被通知的完成”。那些被设置为不被通知的完成的WR的完成状态由就在它们之后的WR间接通知。此后的WR如果立即跟随有企图WR就被设置为不被通知的完成：PostSQ快速注册和PostSQ无效本地STag。
类似于对“工作请求完成”的处理，对RNIC 308只有一个异步事件处理程序。该异步事件处理程序在存在附属的异步事件时由RNIC 308调用。在NDIS与迷你端口交换调用处理程序时，RDMA模块300将异步事件处理程序注册到迷你端口。这是异步事件处理程序的定义：
typedef
VOID
(*NDIS_RDMA_OFFLOAD_ASYNCHRONOUS_EVENT_HANDLER)
(
       IN NDISJHANDLE       NdisMiniportHandle，
       IN UCHAR             EventSource，
       IN PVOID             EventSourceHandle，
       IN ULONG             Eventldentifier
)；
当RNIC 308遇到远程或本地出错时，大多数异步事件被通知，并且RDMA连接将被关闭。RDMA模块300处理该事件、将此出错记入日志，并用该RNIC 308发起连接拆卸和资源清除处理。RDMA模块300最终使连接终止向上调用回它的用户来表示连接已被拆卸。
示例性RDMA体系结构的说明
在多个处理器上并行化CQ完成事件处理
当从RNIC 308向主机堆栈指示RDMA CQE时，主机堆栈通常轮询CQ，从CQ中取出所有CQE，并一个接一个地对它们进行处理。传统上，即便在多处理器的计算设备上，也只有一个处理器在执行这个工作，而其他的处理器都是空闲的。图7至9和以下的文本描述了如何并行地使用多个处理器来加速CQE处理。这个方法可以应用到支持多个CQE处理程序的任何RNIC 308。
在图9的步骤900中，当对RDMA模块300指示RNIC 308起动时，RDMA模块300设置每接口的数据结构来跟踪该接口。该每接口的数据结构包含描述符的阵列。每个描述符对应于一个处理器，并存储用于该处理器的完成时间处理程序ID(步骤904)。稍后，如果要在该处理器上创建CQ，则它们使用该完成时间处理程序ID。
该阵列在接口起动时间被初始化。RDMA模块300使用SET_COMPLETION_EVENT_HANDLER动词向RNIC 308设置完成事件处理程序。RDMA模块300调用该动词N次，其中N等于在系统中的处理器个数(或处理器的总数当中涉及CQE处理的子集)。如在图7中所示，对于每次调用，RDMA模块300都为RNIC 308提供包含处理器号和完成回调函数的数据结构。这将每个完成事件处理程序与一个处理器相关联。对于SET_COMPLETION_EVENT_HANDLER动词的每次调取，RNIC 308返回唯一性的完成事件处理程序ID。这样，就在完成事件处理程序ID与处理器之间建立起了一对一的映射。图7示出了使用增强的SET_COMPLETION_EVENT_HANDLER调用来初始化每接口的完成事件处理程序ID的处理。
当要建立新的RDMA连接时，RDMA模块300决定是否应当为该RDMA连接创建新的CQ。如果新的CQ被创建，则RDMA模块300运行负载平衡算法和其他试探来确定在哪个处理器上创建该CQ(图9的步骤902)。一旦作出了在一处理器上——例如在处理器K上——创建新CQ的决定，RDMA模块300就使用K作为进入其完成事件处理程序ID的每接口队列的索引，并检索处理器K的完成事件处理程序ID。那个ID被用作创建这个新的CQ的输入。如此高效率地告诉RNIC308这个新的CQ被绑定于处理器K。这个步骤的结果是，对于每个处理器，从处理器生长出CQ和QP的两层树。对于多处理器的计算设备，这变如在图8中所示的树的森林。
当CQE排队到CQ中，并且作出向主机OS指示该CQE的决定(图9的步骤906)时，RNIC迷你端口驱动器排定DPC在与该CQ相关联的处理器上运行。RDMA模块300轮询CQ并处理在DPC例程的上下文中轮询的每个CQE(步骤908)。由于多个DPC例程可以同时在多个处理器上运行，因此这实现了并行CQE处理的目的。
示例性RDMA体系结构的说明
关闭连接和出错处理
如果没有仔细处理，关闭RDMA连接可能会是非常复杂并且易于出错的处理。复杂性主要来自于两个方面：(1)在主机OS与RNIC 308硬件之间的交互和(2)在RDMA模块300与主机OS的TCP层之间的交互。
以下的规则和处理定义了在RNIC 308(和它的迷你端口驱动器)与主机OS之间为成功处理RDMA连接关闭而进行的交互。这些一般化的规则在特定的关闭情景的上下文中例示。
·RNIC迷你端口从不用“修改QP(RTS→关闭)”或“修改QP(RTS→出错)”来直接调用。相反，通过TCP卸载断开处理程序发出TCP断开请求。一旦接收到了TCP断开请求，如果连接为RDMA连接，则迷你端口应当执行RDMA关闭和TCP关闭两者。
·RNIC迷你端口从不在没有被发出从容断开请求的情况下自己自动发出TCPFIN。
·RNIC迷你端口如果需要就发出TCP RST。一旦TCP RST被发送或接收，RNIC迷你端口就通过TCP卸载事件处理程序向主机堆栈指示异常中断的断开事件。
·如果RNIC需要发出RDMA终止消息，则它不应当发出该消息的FIN位，也不应当在终止消息之后自动发出TCP FIN。
·对于RDMA烟囱体系结构，“终止卸载”仅在与RDMA连接相关联的TCP连接已经在两个方向上都被完全关闭或异常中断之后被调用。这意味着，“终止卸载”仅在QP处于空闲(Idle)状态，处于出错(Error)状态，或处于关闭(Closing)状态的一部分时才被调用。
TCP断开请求处理程序由TCP软件堆栈用来向RNIC 308的迷你端口驱动器发布从容的或异常中断的断开请求。TCP断开事件处理程序由迷你端口驱动器用来向TCP软件堆栈指示从容的或异常中断的断开事件。在RDMA卸载的上下文中，软件堆栈通过此事件处理程序被通知连接状态，接着它相应地执行RDMA状态转移。
作为这些概念的第一个例示，图10给出处理从容的断开请求的处理的过程的概览。在RDMA连接被建立(步骤1000)之后，RNIC迷你端口被调用以执行TCP从容的断开(步骤1002)。
·如果当前的QP状况允许迷你端口执行从容的LLP(下层协议)断开连接(在步骤1004中的测试)，则RNIC遵从TCP从容断开的语义(步骤1012)。简言之，这将涉及发出TCP FIN并且如果接收到针对该FIN的ACK，则以STATUS_SUCCESS来完成从容断开请求，否则则用IO_TIMEOUT完成它。
·如果当前的QP状况不允许迷你端口执行从容的LLP断开，则迷你端口通过执行TCP复位(步骤1008)并将QP移动到出错状态(步骤1010)来发起异常中断的断开(步骤1006)。而且，迷你端口向软件堆栈指示TCP异常中断的断开事件，并以STATUS_ABORTED来完成原始的从容断开请求。
·如果在执行从容LLP断开的处理期间，发生了一些要求迷你端口立即异常中断LLP连接的RDMA状况，则迷你端口将此连接复位，向软件堆栈通知异常中断的断开事件，并以STATUS_ABORTED来完成原始的从容断开请求。
·迷你端口可以使用RDMAC动词规范来确定当前RDMA QP状况是否允许从容的LLP断开。迷你端口也可以使用RDMAC动词规范来为所有的情形确定RDMA状态转移。
当调用RNIC迷你端口来执行TCP异常中断的断开时，这被视为“修改QP(RTS→出错)”的等效。
·迷你端口立即发出TCP RST并遵从执行异常中断的断开的TCP语义。
·迷你端口将QP从RTS移动到出错(Error)并遵从RDMA处理的RDMA动词规范。
当迷你端口驱动器通过TCP断开事件处理程序向主机OS通知从容的断开事件时：
·对于RDMA烟囱，一旦迷你端口从远程对等设备接收到TCP FIN，它就应当遵循以下TCP语义：向软件堆栈指示从容断开事件并立即发出针对该TCP FIN的ACK。
·对于RDMA烟囱，迷你端口在其从远程对等设备接收到TCP FIN之后，根据RDMAC动词规范执行RDMA处理。
一旦主机OS从RNIC迷你驱动器接收到从容断开事件的指示，它就在RDMA层和TCP层两者中执行处理。
当迷你端口通过TCP断开事件处理程序向主机OS通知了异常中断的断开事件，RNIC迷你端口驱动器就应用正常的TCP语义。简言之：如果从远程对等设备接收到TCP RST，则指示该事件；如果连接被丢失(超时)，则指示该事件。如果RNIC 308无论什么原因想发出RST，则指示该事件。对于RDMA烟囱，如果迷你端口由于RDMA状况需要执行异常中断的LLP关闭，则迷你端口将会如此做。允许迷你端口自己发出TCP RST。一旦LLP连接被异常中断地关闭，迷你端口就将该异常中断的断开事件返回指示给主机。
以下为RDMA烟囱卸载体系结构的TerminiateOffload调用的语义的定义。
·TerminiateOffload仅在与RDMA连接相关联的TCP连接完全关闭或复位之后才被调用。
·以上这点意味着，TerminateOffload仅在QP处在出错(Error)状态、空闲(Idle)状态、或是关闭(Closing)状态的一部分时才被调用。“关闭状态的一部分”意味着LLP已经完全关闭，该QP仍在刷新RQ，并且它仍然处在关闭状态。
·RDMA卸载状态块被链作为对RDMA烟囱作出的TerminiateOffload请求的TCP卸载状态的附属块。
·一旦完成了TerminiateOffload调用，TCP委托状态就通过TCP卸载状态块被上载回主机堆栈。但是，对于RDMA状态，不要求迷你端口将任何状态上载回主机堆栈。。
·可构想地，RNIC 308使用一些内部数据结构(例如，MiniportOffloadContext)来跟踪卸载的RDMA连接。TerminiateOffload调用允许迷你端口清除这些数据结构。在向迷你端口发出TerminiateOffload请求之后，不再参考由主机堆栈作出的MiniportOffloadContext。通常，该上下文在TerminiateOffload调用完成后消失。
·这个TerminiateOffload调用是通用的烟囱卸载API。它不应当被设计成清除RDMA规范资源，诸如QP、CQ、Stag等。为该目的可调用“摧毁QP”和“摧毁CQ”。“摧毁QP”和“摧毁CQ”以及其他的调用都在TerminiateOffload调用作出之后进行。
为了更全面地解释上述概念，图11到20显示了以下可能的RDMA关闭和出错情景：
·本地消费者在关闭处理期间以及之前在无错的情况下发起从容关闭(图11)。
·本地消费者发起从容的关闭，但在SQ上存在未决的工作请求，或是存在未决的传入RDMA读请求(图12)。
·本地消费者发起从容的关闭，并且在该请求作出时无错。但是，在LLP关闭处理期间发生出错(图13)。
·远程对等设备在关闭处理之前和期间在无错的情况下发起从容关闭(图14)。
·远程对等设备在接收到该请求时在有本地出错的情况下发起从容关闭。终止消息被发送(如果可能)，并且试图从容关闭LLP(图15)。
·远程对等设备在接收到该请求时在无本地出错的情况下发起从容关闭，但在关闭处理期间发生出错(图16)。
·本地RNIC 308由于RDMA出错而发起异常关闭。终止消息被发送(如果可能)，并试图从容关闭LLP(图17)。
·本地消费者通过调用“修改QP(RTS→终止)”发起异常关闭。终止消息被发送(如果可能)，并试图从容终止LLP(图18)。
·本地RNIC 308或消费者在不试图发送终止消息的情况下发起异常关闭。LLP被异常中断地关闭(经由TCP RST)。可能LLP已经被丢失(图19)。
·远程对等设备用终止消息发起异常关闭。试图从容关闭LLP(图20)。
·远程对等设备通过发送TCP RST来发起异常关闭。本地对等设备没有发送或接收终止消息。LLP连接被异常中断地关闭(无图)。
在图11到20中以及在随附的文本中使用以下简称：
Disconn(g)：从容断开请求。
·Disconn(a)：异常中断断开请求。
·DisconnEvent(g)：从容断开事件。
·DisconnEvent(a)：异常中断断开事件。
·TermOffload：终止卸载调用。
·RCVD：接收的。
·MQP(A→B)：从状态A到状态B的“修改QP”调用。
·TermMsg：终止消息。
·TERM：终止状态。
·Compl：完成的、完成、完成例程等。
在图11到20中：
·从RDMA模块300向TCP模块的调用是通过TLNPI接口作出的。
·从TCP模块向RNIC迷你端口的调用是通过TCP卸载处理程序作出的(即，RNIC迷你端口TCP卸载分派例程)。
·从RDMA模块300向RNIC迷你端口的调用是通过RDMA卸载处理程序作出的(即，RNIC迷你端口卸载分派例程)。
·从RNIC迷你端口到TCP模块的向上调用是通过TCP卸载事件处理程序作出的(即，RNIC端口TCP卸载向上调用例程)。
·从TCP模块向RDMA模块300的向上调是通过TLNPI接口作出的。
·从RNIC迷你端口到RDMA模块300的向上调用是通过RDMA卸载异步事件处理程序作出的。
·在迷你端口内执行的行为中的一些可以并发而不是如图中所示顺序地执行的。
·对于图11到20，“终止卸载”调用被示为在连接完全关闭或复位之后作出。虽然这是最常见的情形，但由于很多原因，“终止卸载”调用可以在连接已经被完全关闭或复位之前发生。迷你端口遵循以上定义的语意来处理这种情形。这种情形与LLP异常中断断开没有什么不同。
图11：本地消费者在关闭处理之前和期间在无错的情况下发起从容关闭。为了对RDMA连接发起关闭请求，用户应当等待在本地SQ上的所有未解决的工作请求完成并且为所有的远程读工作请求完成。这使RNIC 308能执行从容关闭。WSK的用户与远程对等设备交换ULP专用消息来确认来自远程方的工作请求已经被完成。
详细的处理是：
(1)RDMA模块300向TCP层作出从容断开请求，TCP层向下调用RNIC迷你端口来请求从容断开。由于RNIC迷你端口知道这是RDMA连接，因此它发送TCP FIN，并将QP状态从RTS改为关闭(Closing)，并等待针对该TCP FIN的ACK。在迷你端口接收到针对该FIN的ACK之后，并且当QP处在关闭状态时，RNIC迷你端口完成此从容断开请求调用。
(2)RNIC 308在关闭状态中开始刷新RQ并等待远程对等设备发送FIN。
(3)远程对等设备发送FIN。RNIC迷你端口立即向TCP堆栈指示从容断开事件，TCP堆栈接着向RDMA模块300指示从容断开事件
(4)在图11的点A处，RDMA模块300知道LLP已经被成功且完全地关闭。RDMA模块300接着向下调用TCP层以请求“终止卸载”。
(5)响应于“终止卸载”，RNIC迷你端口首先通过应用TCP烟囱语意(更新TCP委托状态等)来终止TCP卸载，并通过应用以上定义的语意来对RDMA烟囱执行“终止卸载”。
(6)当“终止卸载”完成时，QP应当为两种可能的无错状态中的一个：关闭状态或空闲状态。QP仍然可以处在关闭状态，因为它刷新了RQ。如果RDMA模块300没有因为该无措情形被通知“LLP已关闭”，则计时器被启动，并且RDMA模块300等待RDMA事件“LLP已关闭”。
(7)一旦RNIC 308结束刷新RQ并完全关闭LLP连接，QP就被移到空闲状态。根据动词规范，必须由RNIC 308生成一RDMA事件“LLP已关闭”。这在图11中示为点B。要注意的是，点B可能在TermOffload调用之前或之后发生。
(8)在点B，RDMA模块300知道该QP处于空闲状态。如果在此连接上已经调用了TermOffload并且完成了，则RDMA模块300开始“RDMA资源清除序列”。
(9)在该最后的步骤中，涉及这个连接的RDMA资源被清除。该序列根据动词规范的依存关系图执行。
注意：如果RNIC 308发生了一些问题而阻碍其成功地刷新RQ，则RDMA模块300不会被通知RDMA事件“LLP已关闭”，并且QP关闭状态下被挂起。RDMA模块300并不一直等待这个事件：它在计时器计超时之时启动RDMA资源摧毁序列。
图12：本地消费者发起从容关闭，但在SQ上具有未决的工作请求，或存在未决的传入RDMA读请求。根据RDMAC动词规范，“RNIC可能导致转移到关闭状态，然后立即转移到出错状态(由于SQ非空)”。基于这个文本以及整个烟囱卸载体系结构，RNIC迷你端口执行如下：
(1)将QP移到关闭状态。
(2)复位TCP连接(通过发出TCP RST)
(3)以STATUS_ABORTED完成原始的从容断开请求。
(4)将QP移到出错状态并开始刷新SQ和RQ。
(5)向TCP堆栈指示异常中断断开事件。
在图12的点A，RDMA模块300知道连接已经被复位(异常中断)，并向下调用“终止卸载”。它还知道QP处在出错状态。
在图12的点B，RDMA模块300调用“修改QP(出错→空闲)”。如果QP仍然在刷新，则迷你端口驱动器应“修改QP(出错→空闲)”请求将STATUS_PENDING返回给RDMA模块300。一旦QP完成刷新，迷你端口驱动器就用STATUS_SUCCESS完成原始的“修改QP(出错→空闲)”请求。否则，如果迷你驱动器仍未RNIC 308硬件花费太长时间来刷新(或处于无响应状态)，则迷你端口驱动器可以用特殊出错状态(STATUS_ABORTED)来完成原始的“修改QP(出错→空闲)”请求。无论这个请求的完成状态如何，主机堆栈都开始进行包括了“摧毁QP”调用的RDMA资源摧毁序列。
图13：本地消费者发起从容关闭，并在作出此请求时无错。但是，在LLP关闭处理期间发生出错。在LLP关闭处理期间可能发生的出错应当是LLP出错或RDMA出错。它们是：
(1)本地对等设备从远程对等设备接收到TCP RST。
(2)LLP关闭超时。这可以是以下之一：
(2.a)在发出TCP FIN后，针对该FIN的ACK从未返回。
(2.b)在发出TCP FIN并接收到针对该FIN的ACK之后，RNIC 308和RDMA模块300预期远程对等设备将很快发回TCP FIN。RNIC 308等待这个传入的TCP FIN来完成LLP关闭并将QP移动到空闲状态。一旦接收到TCPFIN，RNIC 308就将从容断开事件返回指示给主机堆栈并将QP移到空闲状态。但是，远程对等设备可能从未发回FIN(或任何事物)回来。为了应对此情况，RDMA模块300触发计时器来等待从容断开事件，并且如果该计时器超时，则RDMA模块300调用异常中断断开请求来复位该连接。
(3)在发出TCP FIN后，任何数据传入。这由动词规范归类为出错情形。
(4)由于某种原因，工作请求在QP处于关闭状态时被张贴到SQ/RQ。该出错状况由RDMA动词规范概述。
(5)由于多种原因，主机堆栈在LLP连接被完全关闭之前调用“终止卸载”。
无论何时发生了上述出错中的任何一个，RNIC 308都将LLP连接复位，向TCP主机堆栈指示异常中断断开事件，并将QP移到出错状态。
图14：远程对等设备在关闭处理之前和期间在无错情况下发起从容关闭。远程对等设备通过发送TCP FIN来发起从容关闭请求。如果本地对等设备的SQ为空并且没有未决的传入RDMA读操作，则RNIC 308接受该从容断开请求并作如下：
(1)发送ACK给远程对等设备来确认该TCP FIN。
(2)修改QP(RTS→关闭)并开始刷新RQ。
(3)向TCP主机堆栈指示从容断开事件。
(4)就在此指示之后不久，TCP堆栈向下对RNIC调用从容断开请求。
(5)一旦迷你端口被以从容断开请求调用，它就发出FIN给远程对等设备，并在它接收到针对该FIN的ACK之后完成该从容断开请求。
(6)一旦RQ刷新完成并且LLP已经被完全关闭，它就将QP移到空闲状态。
根据RDMAC动词规范，迷你端口必须向消费者指示RDMA事件“LLP已关闭”。RDMA模块300等待该事件来知道QP处在空闲状态。
在图14中的点A，RDMA模块300知道LLP已经完全关闭，从而它能向下调用“终止卸载”。一旦“终止卸载”完成了，RDMA模块300就调用“查询QP”(如果需要)来得到QP的当前状态。如果结果显示QP处在关闭状态，则RDMA模块300启动计数器以等待“LLP已关闭”事件。在点B，向RDMA模块300通知RDMA事件“LLP已关闭”以便RDMA模块300能知道QP处在空闲状态，并且RDMA模块300启动RDMA资源清除序列。点B可在点A之后的任何时间发生。
注意：如果RNIC 308发生了一些严重问题阻碍其成功地刷新RQ，则RDMA模块300将不被通知RDMA事件“LLP已关闭”，并且QP在关闭状态中挂起。RDMA模块300并不一直等待该事件：它在计时器超时之时启动RDMA资源摧毁序列。
图15：远程对等设备在该请求被接收到时在有本地出错的情况下发起从容关闭。终止消息被发送(如果可能)，并且试图从容关闭LLP。这里，接收到FIN(意味着远程对等设备正在请求从容关闭)，但本地SQ非空，因为工作请求未决。这被动词规范定义为出错情形。QP首先被移动到终止状态，并且如果可能则由RNIC308生成并发出终止消息。试图从容关闭LLP。
要注意的是，RDMA模块300在此情形中可调用“查询QP”，因为它需要将这种情形与图14和16的情形区分开来。对于那两种情形，QP应当处于关闭状态，并且需要一计时器来等待RNIC 308通知“坏的关闭”或“LLP已关闭”RDMA事件。在当前的情形中，队列QP返回出错状态，并执行在图15的点B的处理。
图16：远程对等设备在接收到该请求(SQ为空，并且没有RDMA读请求未决)时在无本地出错的情况下发起从容关闭(接收到TCP FIN)，但在关闭处理期间发生出错。在LLP关闭处理期间可能发生的出错可能是LLP出错或RDMA出错。它们是：
(1)本地对等设备接收到来自远程对等设备的TCP RST。
(2)LLP关闭超时。
(3)因为某种原因，工作请求在QP处在关闭状态时被张贴到SQ/RQ上。该出错状况由RDMA动词规范概述。
无论何时发生上述的任何出错，RNIC 308都将LLP连接复位，向TCP主机堆栈指示异常中断断开事件，并将QP移到出错状态。
这里对在此情形中的出错处理作进一步说明：
(1)如果错误发送在主机向下调用从容断开请求之前，则RNIC迷你端口应当将异常中断断开返回通知主机并将LLP连接复位。当它被调要以执行从容断开请求时，它以STATUS ABORTED来完成该请求。
(2)如果出错发生在从容断开请求的执行期间，则RNIC迷你端口用STATUS_ABORTED完成此请求并将异常中断断开事件返回指示给主机。
(3)在从容断开请求成功地完成(这意味着LLP已经被完全关闭)之后，QP可能仍在刷新RQ(这意味着它仍然处于关闭状态)，并且可能会发生出错。根据该动词规范，RNIC必须将QP移到出错状态并通知事件“坏的关闭”。RDMA模块300由此事件被通知该QP处在出错状态并对此进行相应的响应。
要注意的是，在无错误情形中(参见图14以及随附的文本)，RNIC 308在它将QP状态从关闭移到空闲之后通知RDMA事件“LLP已关闭”。因此，“坏的关闭”事件将当前情形与该情形区分开来。
同时，要注意的是，在LLP失败的情形中，RDMA动词规范要求RNIC 308通知“LLP丢失”或“LLP复位”。但是，这两个RDMA事件与异常中断断开事件构成冗余。在RDMA烟囱中，RDMA模块300总是等待异常中断断开事件并忽略RDMA事件“LLP丢失”和“LLP复位”。
其余的情形全都涉及异常关闭。RDMA异常关闭因RDMA出错或LLP出错而由RNIC 308本身或由消费者发起。在RDMA异常关闭的情形中，LLP连接可以被异常中断地关闭，或如果可能，则被从容关闭。通常，如果条件允许，则由RNIC 308发送或接收终止消息。
图17和18针对本地对等设备发起RDMA异常中断关闭的情形。这里存在两种子情形：
(1)在图17所示的情形中，本地对等设备的RNIC 308在该连接上检测到RDMA操作出错并发起异常关闭。如果LLP仍然在工作，则RNIC 308试图发送终止消息并将QP移到终止状态。(但是，如果LLP没有在工作，则RNIC 308直接将QP移到出错状态而不发送终止消息，如图19所示的情形)。
(2)在图18所示的情形中，本地对等设备的消费者确定RDMA连接应被异常关闭并且终止消息应当被发送到远程对等设备。消费者调用“修改QP(RTS→终止)”。
图17：本地RNIC 308因RDMA出错而发起异常关闭。终止消息被发送(如果可能)，并且试图从容关闭LLP。如果RNIC 308检测到本地出错并且决定通过终止状态来发起RDMA异常关闭，则它执行以下行为：
(1)通过以下两种方式中的任何一种通知主机堆栈有关出错：
通知异步事件或以出错状态完成工作请求。
(2)停止所有的QP处理以及准备并发送终止消息。
(3)等待主机堆栈向下调用从容断开请求，并发出FIN。一旦主机堆栈(a)接收到RDMA异步出错事件，(b)轮询到具有出错完成状态的CQE，或
(c)接收到从容断开事件的指示，它就向下调用从容断开请求。
(4)如果远程对等设备发送了FIN，则RNIC 308就发回ACK，接着通过从容断开事件通知主机堆栈。
(5)出错可能在处理中的任何时间发生。如果发生了任何出错，则TCP连接就被复位(如果它仍在)，并且将异常中断断开事件返回指示给主机堆栈。QP被移到出错状态。这个处理的可能出错包括：
(5.a)接收到来自远程对等设备的TCP RST。
(5.b)由于(i)未能接收到针对该FIN的ACK或(ii)未能发送终止消息，因此LLP关闭超时。
(5.c)未能从远程对等设备接收到FIN。远程对等设备可能根本没有发回任何事物。参见附图13的出错(2.b)的讨论。
要注意的是，从容断开事件或异常中断断开事件可能在RNIC 308指示异步出错并发送终止消息之后的任何时间发生。
在图17中要注意的是，点E指示从容断开事件或异常中断断开事件也可以由RNIC迷你端口在此点通知。一旦迷你端口从远程对等设备接收到TCP FIN，它就通知从容断开事件，而一旦LLP被复位或丢失，它就通知异常中断断开事件。这就是点E的含义。
在“终止卸载”调用完成之后，如果需要，RDMA模块300可以调用“查询QP”来查询QP的当前状态。“查询QP”被调用以将这种情形与无错关闭情形区分开来。
图18：本地消费者通过调用“修改QP(RTS→终止)”来发起异常关闭。终止消息被发送(如果需要)，并且试图从容终止LLP。本地消费者可以在任何时候发起异常RDMA关闭。存在两种方式来这样做：(1)调用“修改QP(RTS→终止)”和(2)调用异常中断断开请求。第一种情形请求RNIC 308在可能的情况下发出RDMA终止消息，并试图从容关闭LLP连接。第二种情形不发送终止消息，但立即异常中断地拆卸LLP连接。图18显示了第一种情形。
图19：本地RNIC 308或消费者在不试图发送终止消息的情况下发起异常关闭。LLP被异常中断地关闭(通过TCP RST)。可能LLP已经被丢失。这种情形通过异常中断地拆卸LLP连接而直接转到出错状态。对此，具有三种可能的情形：
(1)本地消费者发出异常中断断开请求。这在图19中被标为点B。
(2)LLP被丢失或复位，并且本地RNIC 308将QP状态从RTS移到出错。
(3)由于各种RDMA出错和状况，RNIC 308决定立即将LLP复位。
情形(2)和(3)都以异常中断断开事件向主机堆栈指示(在图19中的点A)。
图20：远程对等设备用终止消息发起异常关闭。试图从容关闭LLP。一旦接收了终止消息，RNIC迷你端口就将QP移到终止状态并向主机堆栈指示RDMA事件“已经接收到终止消息”。由这个事件通知，RDMA模块300立即向下调用从容断开请求。RNIC迷你端口接着发出TCP FIN并试图完成从容LLP断开。如果远程对等设备发回FIN，则LLP就被从容关闭，并且QP被移到出错状态。但是，在这个处理期间的任何时间都可能发生以下的出错：
(1)LLP等待TCP FIN导致超时或本地RNIC 308从未接收到针对所发送的FIN的ACK。
(2)本地RNIC 308从远程对等设备接收到TCP RST。
(3)在发出TCP FIN之后，本地RNIC 308预期远程对等设备立即发回TCP FIN。但是，这个FIN可能从未传入。这与以上关于图13讨论的错误2.b相同。
在整个处理期间，如果RNIC迷你端口从远程对等设备接收到TCP FIN，则它向主机堆栈指示从容断开事件，而如果它接收到TCP RST或如果它发送了TCPRST，则它向主机堆栈指示异常中断断开事件。
在图20中要注意的是，从容断开事件或异常中断断开事件也可以由RNIC迷你端口在点E通知。
无图：远程对等设备通过发送TCP RST发起异常关闭。本地对等设备没有发送或接收终止消息。LLP连接被异常中断地关闭。
鉴于可应用本发明原理的许多可能的实施例，应当明白，在此参考附图所描述的这些实施例仅是示例性的并不应被视为限定本发明的范围。本领域的技术人员将可以意识到，诸如RDMA烟囱体系结构的详细语意和过程等的一些实施细节是由具体的情况所决定的。虽然在此以软件模块或组件的形式描述了本发明的环境，但是一些处理也可以等效地由硬件组件执行。因此，在此所描述的本发明构想了落在所附权利要求及其等效技术方案的范围内的所有这样的实施例。

Claims (31)

1.在联网环境中的一种用来终止远程直接存储器存取(RDMA)连接的系统，所述RDMA连接被携带于分组流上，所述系统包括：
用于分组流的断开请求处理器，所述断开请求处理器被配置成用于发出从容断开请求；以及
用于支持所述分组流的网络输入/输出(I/O)适配器的驱动器，所述网络I/O驱动器配置成用于：
接收所述从容断开请求；
确定队列对(QP)的状况是否允许从容分组流断开；以及
如果所述QP的状况允许从容断开，则从容断开所述分组流，否则执行异常中断分组流断开，将所述分组流复位，并将所述QP的状态设为出错状态。
2.根据权利要求1的系统，其特征在于，所述分组流为TCP流。
3.根据权利要求1的系统，其特征在于，由一主机操作系统包括所述断开请求处理器，其中所述网络I/O驱动器与网络接口卡相关联。
4.根据权利要求1的系统，其特征在于，所述确定QP的状况是否允许从容分组流断开包括应用RDMAC动词规范。
5.根据权利要求1的系统，其特征在于，所述网络I/O驱动器还配置成用于：
如果在从容断开所述分组流的同时，所述分组流必须被异常中断，则发起异常中断分组流断开并通知主机操作系统所述异常中断的断开。
6.根据权利要求1的系统，其特征在于，所述断开请求处理器还被配置成用于发出异常中断断开请求；并且
其中所述网络I/O驱动器还被配置成用于：
接收所述异常中断断开请求；
执行异常中断分组流断开；以及
将所述QP的状态设为出错状态。
7.根据权利要求1的系统，其特征在于，还包括：
用于所述分组流的断开事件处理器；
其中所述网络I/O驱动器还配置成用于发出从容断开事件以及用于从容断开所述分组流；并且
其中所述断开事件处理器被配置成用于接收所述从容断开事件。
8.根据权利要求7的系统，其特征在于，所述网络I/O驱动器还被配置成用于通过所述断开事件处理器发出异常中断断开事件并用于发起异常中断分组流断开并将所述分组流复位；并且
其中所述断开事件处理器还被配置成用于接收所述异常中断断开事件。
9.在联网环境中的一种用来终止RDMA连接的方法，所述RDMA连接被携带于分组流上，所述方法包括：
接收从容断开请求；
确定QP的状况是否允许从容分组流断开；以及
如果所述QP的状况允许从容断开，则从容断开所述分组流，否则执行异常中断分组流断开，将所述QP的状态设为出错状态，并通知主机操作系统所述异常中断断开。
10.根据权利要求9的方法，其特征在于，所述分组流是TCP流。
11.根据权利要求9的方法，其特征在于，所述方法运行用于支持所述分组流的网络I/O适配器的驱动器，并且所述网络I/O驱动器与网络接口卡相关联。
12.根据权利要求9的方法，其特征在于，所述确定QP的状况是否允许从容分组流断开包括应用RDMAC动词规范。
13.根据权利要求9的方法，其特征在于，还包括：
如果在从容断开所述分组流的同时，所述分组流必须被异常中断，则发起异常中断分组流断开并通知主机操作系统所述异常中断断开。
14.根据权利要求9的方法，其特征在于，所述方法在用于支持分组流的网络I/O适配器的驱动器上运行，并且所述方法还包括：
接收异常中断断开请求；
执行异常中断分组流断开；以及
将所述QP的状态设置为出错状态。
15.根据权利要求9的方法，其特征在于，所述方法在用于支持所述分组流的网络I/O适配器的驱动器上运行，并且所述方法还包括：
发出从容断开事件；以及
从容断开所述分组流。
16.根据权利要求9的方法，其特征在于，所述方法在用于支持所述分组流的网络I/O适配器的驱动器上运行，并且所述方法还包括：
发出异常中断断开事件；以及
发起异常中断分组流断开并将所述分组流复位。
17.一种计算机可读介质，其具有用来执行用于终止RDMA连接的方法的计算机可执行指令，所述RDMA连接被携带于分组流上，所述方法包括：
接收从容断开请求；
确定QP的状况是否允许从容分组流断开；
如果所述QP的状况允许从容断开，则从容断开所述分组流，否则执行异常中断分组流断开，将所述QP的状态设置为出错状态，并通知主机操作系统所述异常中断断开。
18.根据权利要求17的计算机可读介质，其特征在于，所述方法还包括：
接收异常中断断开请求；
执行异常中断分组流断开；以及
将所述QP的状态设置为出错状态。
19.在联网环境中的一种用来终止RDMA连接的系统，所述RDMA连接被携带于分组流上，所述系统包括：
用于所述分组流的断开请求处理器，所述断开请求处理器被配置成用于对所述分组流和所述分组流上所携带的所述RDMA连接两者发出断开请求；以及
用于支持所述分组流的RDMA网络接口控制器(RNIC)的驱动器，所述RNIC驱动器被配置成用于：
接收所述断开请求；
响应于所述断开请求执行RDMA关闭；以及
响应于所述断开请求执行分组流关闭。
20.根据权利要求19的系统，其特征在于，所述RNIC驱动器还被配置成用于：
在没有被请求执行从容断开的情况下决不会自己发出分组流FIN消息。
21.根据权利要求19的系统，其特征在于，所述RNIC驱动器还被配置成：
发出分组流RST消息；
接收分组流RST消息；以及
如果有分组流RST消息被发送或接收，则向主机操作系统指示异常中断断开事件。
22.根据权利要求19的系统，其特征在于，所述RNIC驱动器还被配置成用于：
发出FIN位没有被设置的RDMA终止消息；
在发出所述RDMA终止消息之后避免发出分组流FIN消息；以及
仅在通过所述断开请求处理器接收的主机操作系统的请求处发出分组流FIN消息。
23.根据权利要求19的系统，其特征在于，还包括：
主机操作系统，其被配置成用于仅在所述分组流已在两个方向上都被关闭或被异常终止之后才发出终止卸载请求，并用于在队列对处于从包含空闲、出错和关闭的组中选出的状态时发出终止卸载请求。
24.在联网环境中的一种用来终止RDMA连接的方法，所述RDMA连接被携带于分组流上，所述方法包括：
从断开请求处理器接收针对所述分组流的断开请求，所述断开请求是从包括从容断开请求和异常中断断开请求的组中选出的；
响应于所述断开请求执行RDMA关闭；以及
响应于所述断开请求执行分组流关闭。
25.根据权利要求24的方法，其特征在于，还包括：
如果没有被请求执行从容断开，则决不会自己发出分组流FIN消息。
26.根据权利要求24的方法，其特征在于，还包括：
发出分组流RST消息；
接收分组流RST消息；以及
如果有分组流RST消息被发送或接收，则向主机操作系统指示异常中断断开事件。
27.根据权利要求24的方法，其特征在于，还包括：
发出FIN位没有被设置的RDMA终止消息；
在发出所述RDMA终止消息之后避免发出分组流FIN消息；以及
仅在通过所述断开请求处理器接收的主机操作系统的请求处发出分组流FIN消息。
28.一种计算机可读介质，其具有用来执行用于终止RDMA连接的方法的计算机可执行指令，所述RDMA连接被携带于分组流上，所述方法包括：
从所述断开请求处理器接收针对所述分组流的断开请求，所述断开请求是从包括从容断开请求和异常中断断开请求的组中选出的；
响应于所述断开请求执行RDMA关闭；以及
响应于所述断开请求执行分组流关闭。
29.根据权利要求28的计算机可读介质，其特征在于，所述方法还包括：
如果没有被请求执行从容断开，则决不会自己发出分组流FIN消息。
30.根据权利要求28的计算机可读介质，其特征在于，所述方法还包括：
发出分组流RST消息；
接收分组流RST消息；以及
如果有分组流RST消息被发送或接收，则向主机操作系统指示异常中断断开事件。
31.根据权利要求28的计算机可读介质，其特征在于，所述方法还包括：
发出FIN位没有被设置的RDMA终止消息；
在发出所述RDMA终止消息之后避免发出分组流FIN消息；以及
仅在通过所述断开请求处理器接收的主机操作系统的请求处才发送分组流FIN消息。
CN200680016265.4A 2005-05-13 2006-05-15 用于关闭rdma连接的方法和系统 Pending CN101194250A (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US11/128,875 US20060259570A1 (en) 2005-05-13 2005-05-13 Method and system for closing an RDMA connection
US11/128,875 2005-05-13

Publications (1)

Publication Number Publication Date
CN101194250A true CN101194250A (zh) 2008-06-04

Family

ID=37420449

Family Applications (1)

Application Number Title Priority Date Filing Date
CN200680016265.4A Pending CN101194250A (zh) 2005-05-13 2006-05-15 用于关闭rdma连接的方法和系统

Country Status (4)

Country Link
US (1) US20060259570A1 (zh)
EP (1) EP1880308A4 (zh)
CN (1) CN101194250A (zh)
WO (1) WO2006124718A2 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102404212A (zh) * 2011-11-17 2012-04-04 曙光信息产业(北京)有限公司 一种基于InfiniBand网络的跨平台RDMA通信方法

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004192179A (ja) * 2002-12-10 2004-07-08 Fujitsu Ltd Ｒｄｍａ機能を持ったｎｉｃをハードウェアメモリ保護を行わないで、専用のモニタプロセスなしにシステムに組み込むための装置
US7539780B2 (en) * 2003-12-01 2009-05-26 International Business Machines Corporation Asynchronous completion notification for an RDMA system
US9229901B1 (en) 2012-06-08 2016-01-05 Google Inc. Single-sided distributed storage system
US9058122B1 (en) 2012-08-30 2015-06-16 Google Inc. Controlling access in a single-sided distributed storage system
US8862561B1 (en) 2012-08-30 2014-10-14 Google Inc. Detecting read/write conflicts
US8676851B1 (en) 2012-08-30 2014-03-18 Google Inc. Executing transactions in distributed storage systems
US9164702B1 (en) 2012-09-07 2015-10-20 Google Inc. Single-sided distributed cache system
US20140337456A1 (en) * 2013-05-07 2014-11-13 Dell Products L.P. Systems and methods for enabling rdma between diverse endpoints
CN103257865A (zh) * 2013-05-15 2013-08-21 山东超越数控电子有限公司 基于Wince7下实现应用程序控制底层硬件的方法
US9313274B2 (en) 2013-09-05 2016-04-12 Google Inc. Isolating clients of distributed storage systems
US8996741B1 (en) 2013-09-25 2015-03-31 International Business Machiness Corporation Event driven remote direct memory access snapshots
US9954979B2 (en) * 2015-09-21 2018-04-24 International Business Machines Corporation Protocol selection for transmission control protocol/internet protocol (TCP/IP)
US10652320B2 (en) 2017-02-21 2020-05-12 Microsoft Technology Licensing, Llc Load balancing in distributed computing systems
US10956245B1 (en) * 2017-07-28 2021-03-23 EMC IP Holding Company LLC Storage system with host-directed error scanning of solid-state storage devices
US20210117246A1 (en) 2020-09-25 2021-04-22 Intel Corporation Disaggregated computing for distributed confidential computing environment
CN113873008B (zh) * 2021-08-30 2024-03-19 浪潮电子信息产业股份有限公司 一种rdma网络节点的连接重配方法、装置、系统及介质

Family Cites Families (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5872941A (en) * 1996-06-05 1999-02-16 Compaq Computer Corp. Providing data from a bridge to a requesting device while the bridge is receiving the data
US6041060A (en) * 1997-04-30 2000-03-21 International Business Machines Corporation Communications cell scheduler and scheduling method for providing periodic activities
US6697868B2 (en) * 2000-02-28 2004-02-24 Alacritech, Inc. Protocol processing stack for use with intelligent network interface device
US7136645B2 (en) * 1998-10-09 2006-11-14 Netmotion Wireless, Inc. Method and apparatus for providing mobile and other intermittent connectivity in a computing environment
US6658469B1 (en) * 1998-12-18 2003-12-02 Microsoft Corporation Method and system for switching between network transport providers
US7113291B1 (en) * 1999-01-29 2006-09-26 Minolta Co., Ltd. Image formation apparatus limiting print operation according to additional information embedded in input image data
US7010607B1 (en) * 1999-09-15 2006-03-07 Hewlett-Packard Development Company, L.P. Method for training a communication link between ports to correct for errors
US6594712B1 (en) * 2000-10-20 2003-07-15 Banderacom, Inc. Inifiniband channel adapter for performing direct DMA between PCI bus and inifiniband link
US7149817B2 (en) * 2001-02-15 2006-12-12 Neteffect, Inc. Infiniband TM work queue to TCP/IP translation
US6816455B2 (en) * 2001-05-09 2004-11-09 Telecom Italia S.P.A. Dynamic packet filter utilizing session tracking
US7165110B2 (en) * 2001-07-12 2007-01-16 International Business Machines Corporation System and method for simultaneously establishing multiple connections
US7095750B2 (en) * 2001-08-16 2006-08-22 International Business Machines Corporation Apparatus and method for virtualizing a queue pair space to minimize time-wait impacts
US20030065856A1 (en) * 2001-10-03 2003-04-03 Mellanox Technologies Ltd. Network adapter with multiple event queues
US7006436B1 (en) * 2001-11-13 2006-02-28 At&T Corp. Method for providing voice-over-IP service
US7245627B2 (en) * 2002-04-23 2007-07-17 Mellanox Technologies Ltd. Sharing a network interface card among multiple hosts
US7149220B2 (en) * 2002-04-25 2006-12-12 International Business Machines Corporation System, method, and product for managing data transfers in a network
US7487264B2 (en) * 2002-06-11 2009-02-03 Pandya Ashish A High performance IP processor
US7631107B2 (en) * 2002-06-11 2009-12-08 Pandya Ashish A Runtime adaptable protocol processor
WO2004017220A1 (en) * 2002-08-19 2004-02-26 Broadcom Corporation One-shot rdma
US8631162B2 (en) * 2002-08-30 2014-01-14 Broadcom Corporation System and method for network interfacing in a multiple network environment
US7299266B2 (en) * 2002-09-05 2007-11-20 International Business Machines Corporation Memory management offload for RDMA enabled network adapters
WO2004036381A2 (en) * 2002-10-18 2004-04-29 Broadcom Corporation System and method for receive queue provisioning
US6874054B2 (en) * 2002-12-19 2005-03-29 Emulex Design & Manufacturing Corporation Direct memory access controller system with message-based programming
US7114096B2 (en) * 2003-04-02 2006-09-26 International Business Machines Corporation State recovery and failover of intelligent network adapters
US7685254B2 (en) * 2003-06-10 2010-03-23 Pandya Ashish A Runtime adaptable search processor
US7757232B2 (en) * 2003-08-14 2010-07-13 Hewlett-Packard Development Company, L.P. Method and apparatus for implementing work request lists
US7526577B2 (en) * 2003-09-19 2009-04-28 Microsoft Corporation Multiple offload of network state objects with support for failover events
US7404190B2 (en) * 2003-09-18 2008-07-22 Hewlett-Packard Development Company, L.P. Method and apparatus for providing notification via multiple completion queue handlers
US7177941B2 (en) * 2003-12-11 2007-02-13 International Business Machines Corporation Increasing TCP re-transmission process speed
US7441006B2 (en) * 2003-12-11 2008-10-21 International Business Machines Corporation Reducing number of write operations relative to delivery of out-of-order RDMA send messages by managing reference counter
US8161126B2 (en) * 2003-12-19 2012-04-17 Broadcom Corporation System and method for RDMA QP state split between RNIC and host software
US7779081B2 (en) * 2004-07-16 2010-08-17 International Business Machines Corporation Method, system, and program for forwarding messages between nodes
US7512714B2 (en) * 2004-08-31 2009-03-31 Honeywell International Inc. System and method for transmitting ACARS messages over a TCP/IP data communication link
US20060101225A1 (en) * 2004-11-08 2006-05-11 Eliezer Aloni Method and system for a multi-stream tunneled marker-based protocol data unit aligned protocol
US7783880B2 (en) * 2004-11-12 2010-08-24 Microsoft Corporation Method and apparatus for secure internet protocol (IPSEC) offloading with integrated host protocol stack management
US7475167B2 (en) * 2005-04-15 2009-01-06 Intel Corporation Offloading data path functions
US7761619B2 (en) * 2005-05-13 2010-07-20 Microsoft Corporation Method and system for parallelizing completion event processing
US20070208820A1 (en) * 2006-02-17 2007-09-06 Neteffect, Inc. Apparatus and method for out-of-order placement and in-order completion reporting of remote direct memory access operations
US8190699B2 (en) * 2008-07-28 2012-05-29 Crossfield Technology LLC System and method of multi-path data communications

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102404212A (zh) * 2011-11-17 2012-04-04 曙光信息产业(北京)有限公司 一种基于InfiniBand网络的跨平台RDMA通信方法

Also Published As

Publication number Publication date
WO2006124718A2 (en) 2006-11-23
EP1880308A2 (en) 2008-01-23
WO2006124718A3 (en) 2007-11-22
US20060259570A1 (en) 2006-11-16
EP1880308A4 (en) 2010-01-13

Similar Documents

Publication Publication Date Title
CN101194250A (zh) 用于关闭rdma连接的方法和系统
CN106411767B (zh) 通过远程直接存储器访问的传输操作的方法、系统和介质
US7761619B2 (en) Method and system for parallelizing completion event processing
US7554976B2 (en) Method and system for transferring a packet stream to RDMA
RU2388039C2 (ru) Облегченный протокол ввода/вывода
US7526549B2 (en) Cluster data port services for clustered computer system
US7475167B2 (en) Offloading data path functions
CN1902585B (zh) 用于与支持多个设备的网络适配器接口的方法、系统和程序
EP2659375B1 (en) Non-disruptive failover of rdma connection
US8244825B2 (en) Remote direct memory access (RDMA) completion
JP4504762B2 (ja) ストレージネットワークの移行方法、管理装置、管理プログラムおよびストレージネットワークシステム
EP2216955B1 (en) Network interface device
US20040093389A1 (en) Light weight file I/O over system area networks
US20050060442A1 (en) Method, system, and program for managing data transmission through a network
CN1985492B (zh) 支持iSCSI读操作和iSCSI烟囱的方法和系统
US8959171B2 (en) Method and apparatus for acknowledging a request for data transfer
US7506074B2 (en) Method, system, and program for processing a packet to transmit on a network in a host system including a plurality of network adaptors having multiple ports
US7159010B2 (en) Network abstraction of input/output devices
US10154079B2 (en) Pre-boot file transfer system
JPH07168774A (ja) 無接続セッション指向プロトコルの第１メッセージの生成システム及び方法
US6374248B1 (en) Method and apparatus for providing local path I/O in a distributed file system
US20030005106A1 (en) Communication control apparatus and method
US9246754B2 (en) Automatic failover of nodes of a middle-tier layer
US7839875B1 (en) Method and system for an efficient transport loopback mechanism for TCP/IP sockets
US20050002389A1 (en) Method, system, and program for processing a packet to transmit on a network in a host system including a plurality of network adaptors

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
AD01 Patent right deemed abandoned

Effective date of abandoning: 20080604

C20 Patent right or utility model deemed to be abandoned or is abandoned