当前位置：首页 > RDMA > 正文

【Infiniband手册】第9章：传输层

RDMA
2022-10-27
21066
更新：2022-11-25 21:57:45

# 9.1 概述

每个IBA包都包含一个传输头。传输头包含终端节点(endnode)完成指定操作所需的信息，例如将数据有效负载传送到endnode内的适当实体，如线程或IO控制器。本章定义了IBA使用的传输服务。

IBA信道适配器的客户端通过操纵由发送工作队列和接收工作队列组成的“队列对”（QP）与传输层通信。**对于主机平台，传输层的客户端是Verbs软件层**。客户端向这些队列发送缓冲区或命令，硬件从缓冲区中传输数据或向缓冲区中传输数据。在本章中，发起操作的QP，即将消息注入fabric中的QP被称为请求者，而接收消息的QP被称为响应者。

当QP被创建时，它与五种IBA传输服务类型或非IBA协议封装服务之一相关联。传输服务描述了可靠性的程度以及QP传输数据的内容和方式。

IBA的五种传输服务类型是：

1）可靠连接（RC）

2）可靠数据报（RD）

3）扩展可靠连接（XRC）

4）不可靠数据报（UD）

5）不可靠连接（UC）

**非IBA协议封装服务包括：**

1）原始IPv6数据报

2）原始以太网类型数据报

表340信道适配器属性列出了主机信道适配器和目标信道适配器需要哪些服务。下面的表38“操作码（OpCode）字段”比较了这五种传输服务类型的几个关键属性。

可靠传输服务使用序列号和确认消息（ACK/NAK）的组合来验证数据包的传递顺序，防止重复的数据包和无序的数据包被处理，并检测丢失的数据包。一旦检测到错误，例如丢失的数据包，请求者将重新传输丢失的数据包以及所有后续的数据包。**IBA不支持选择性分组重传，也不支持分组的无序接收。**

IBA操作被定义为包括请求消息和对于可靠服务的相应响应。因此，请求消息由请求者生成，而响应（如果存在）则由响应者生成。

请求消息由一个或多个IBA包组成。请求消息的包称为请求包。一个响应，除了RDMA读响应，只包含一个数据包。响应也叫acknoledge（确认）。表示一个或多个包被确认收到。响应可以确认接收包，所述包包括从请求消息的一部分到多个请求消息的任何位置的确认。

**不可靠的传输服务不使用确认消息。但是它们确实生成序列号**。这允许响应程序检测无序或丢失的数据包，并执行本地恢复处理。不可靠数据报的任何恢复处理的细节都不在IBA规范的范围之内。

**XRC是基于可靠数据报（RD）模型的一种新方法，它将上述场景中完全连接所需的QP数量减少了一倍，从而显著提高了多核终端节点大型集群解决方案的可扩展性**。有关XRC的完整说明，请参阅**第9.7.9节“XRC”**。

# 9.2 基本传输头/BTH

基本传输标头（BTH）包含始终存在于所有IBA传输服务的字段——它不存在于原始数据包中。BTH的存在由Link Next Header指示(LRH:LNH)字段。

原始数据包不使用IBA传输服务，因此原始数据包不需要基本传输标头。

C9-1：所有IBA传输服务应包括一个基本传输头。

## 9.2.1 操作码（OpCode）—8 bits

操作码字段定义剩余头和有效负载字节的解释。操作码列表定义如表38“操作码字段”所示。

C9-2：表38“操作码字段”应用于定义BTH中的操作码参数以及BTH之后的报头和有效载荷。

o9-0.2.1：本合规声明已被删除，因为它包含在C9-2中。

## 9.2.2 预留传输功能操作码

为了将来扩展其传输层，IBA提供保留的和制造商定义的BTH操作码。制造商定义的操作码不应在设备之间使用，除非设备被明确标识为支持这些操作码。

## 9.2.3 请求事件（SE）-1位

**请求者将该位设置为1，以指示响应者将调用CQ事件处理程序**。其他操作指南：

<span>◼ </span>SE位只能在SEND、SEND with Immediate或RDMA WRITE with Immediate的最后或唯一数据包中设置。

<span>◼ </span>有关影响HCA的其他操作指南，请参阅第11.4.2.2节“请求完成通知”。

SE位不被视为包头验证的一部分，即接收到具有该位集的包而不满足调用要求将不会导致生成NAK。

C9-3：对于HCA，如果入站请求数据包的BTH请求事件位设置为1，并且附加SE操作指南有效，则它应调用CQ事件处理程序。

o9-1：对于支持请求事件的TCA，如果入站请求包BTH中的请求事件位设置为1，并且附加的SE操作指南有效，则它应调用CQ事件处理程序。

C9-4：响应器（responder）不应考虑包头验证BTH部分的SE位。

除了在SEND、SEND with Immediate或RDMA Write with Immediate操作中使用，SE位可以通过SEND with Invalidate操作进行设置。在这种情况下，SE位只应在发送的最后一个或唯一一个数据包中设置。在所有其他方面，SE位的使用遵循为在正常发送操作中使用SE位而定义的相同规则。

## 9.2.4 MigReq（M）-1位

用于通信迁移状态（communication migration state）。如果设置为1，则表示连接或EE上下文已迁移；如果设置为零，则表示当前迁移状态没有变化。请参阅**第17章：通道适配器内“自动路径迁移”**一章。

## 9.2.5 填充计数（PADCNT）-2位

数据包有效负载以4字节数量的倍数发送。Pad count指示附加到数据包有效负载的Pad字节数（0到3）。pad用于“拉伸”有效载荷（有效载荷的长度可能为零或更多字节）为4字节的倍数。

## 9.2.6 传输头版本（TVER）-4位

指定用于此数据包的IBA传输的版本。此版本适用于所有传输字段，包括BTH、扩展头和不变CRC—此字段设置为0x0。如果接收器不支持指定的传输版本，则丢弃该数据包。

C9-5：使用IBA传输的请求者和响应者应使用BTH:TVer=0x0。

## 9.2.7 分区密钥（P_Key）-16位

P_Key标识目标QP（RC、UC、UD、XRC）或EE Context（RD）所属的分区。

## 9.2.8 目的地QP（DESTQP）-24位

指定目标队列对（QP）标识符。

## 9.2.9 FECN/RES1（F/RES1）-1位

F(FECN)：0表示未收到FECN指示。1表示数据包经过拥塞点。

Res1: 作为0传输，接收时忽略。该字段不包括在不变CRC中。

## 9.2.10 BECN/RES1（B/RES1）-1位

B（BECN）：0表示数据包没有经过拥塞点，或者经过拥塞点，但没有被标记。1表示此报头指示的数据包受到转发拥塞的影响。B位设置在ACK或CN BTH中。

Res1: 作为0传输，接收时忽略。该字段不包括在不变CRC中。

## 9.2.11 保留6（RESV6）-6位

保留（变量）-6位。作为0传输，接收时忽略。该字段不包括在不变CRC中。

C9-6：在生成数据包时，发送方应将Resv6、F/Res1和B/Res1字段设置为零。一般情况下，接收方应忽略保留字段。

## 9.2.12 ACKREQ（A）-1位

请求的响应者调度/schedule对相关QP的确认。

## 9.2.13 保留7（RESV7）-7位

作为0传输，接收时忽略。此字段包含在不变CRC中。

C9-7：生成数据包时，发送方应将Resv7字段设置为零。接收方应忽略此字段。

## 9.2.14 分组序列号（PSN）-24位

此字段用于标识数据包在一系列数据包中的位置。所有IBA请求者应按照**第9.7.3.1节“请求端生成PSN”**中的规定生成PSN。根据传输服务类型和/或实现需求，响应端可以验证PSN以检测丢失的分组。

# 9.3 扩展传输标头

## 9.3.1 可靠数据报扩展传输标头（RDETH）-4字节

可靠数据报扩展传输头（RDETH）包含端到端上下文标识符。

### 9.3.1.1 保留-8位

o9-2：如果CA实现可靠的数据报功能，则在生成数据包时，发送方应将此字段设置为0x0。接收方应忽略此字段。

### 9.3.1.2 端到端（EE）上下文-24位

此字段指示用于此数据包的端到端（EE）上下文。EE-context是一个唯一的端节点标识符（endnode identifier），用于在任意两个终端节点之间复用/解复用可靠的数据报包。EE上下文提供可靠传输状态的上下文，类似于用于可靠连接的上下文。

## 9.3.2 数据报扩展传输头（DETH）-8字节

数据报扩展传输头（DETH）包含可靠和不可靠数据报服务的附加传输字段。

### 9.3.2.1 Q_Key-32位

需要授权才能访问目标队列时需要此字段。响应者将此字段与目标的QP的Q_Key进行比较。

### 9.3.2.2 保留-8位

C9-8：生成数据包时，发送方应将此字段设置为0x0。接收方应忽略此字段。

### 9.3.2.3 源QP（SRCQP）-24位

此字段指定源队列对（QP）标识符。这被用作响应包的目标QP。

## 9.3.3 RDMA扩展传输头（RETH）-16字节

RDMA扩展传输头（RETH）包含RDMA操作的附加传输字段。

### 9.3.3.1 虚拟地址（VA）-64位

缓冲区的起始地址。RDMA VA可以从任何字节边界开始。

### 9.3.3.2 R_Key-32位

R_Key具有以下属性：

<span>◼ </span>R_Key作为保护密钥，用于访问给定操作的指定内存地址和范围，即，它是一种保护机制，可确保对目标内存的正确访问。响应程序将R_Key与本地保护机制相关联，以验证请求者的访问权限。

<span>◼ </span>必须向请求者输出R_Key-此过程（还包括起始虚拟地址和内存大小的输出，即长度）不在本节的范围内。

<span>◼ </span>为RDMA读、RDMA写和原子的任何组合授予访问权限-包括“无”和“全部”。

<span>◼ </span>在任何给定时刻，每个存储区域或窗口都有一个有效的R_Key。一个几乎连续的内存位置范围可以同时有多个区域或窗口与之关联，每个区域或窗口都有一个关联的R_Key。

<span>◼ </span>R_Key可以导出到多个远程响应者/responder。

<span>◼ </span>R_Key仅用于RDMA和原子操作。包头中包含一个R_Key。

支持RDMA和/或原子操作的响应者应验证R_Key、相关的访问权限和指定的虚拟地址。响应者还必须执行边界检查（即，验证被引用的数据的长度没有跨越相关的内存起始地址和结束地址）。任何违反都必须导致数据包被丢弃，而对于可靠的服务，则会生成NAK。

### 9.3.3.3 DMA长度（DMALEN）-32位

此字段指示远程DMA操作的长度（以字节为单位）。

C9-9：对于执行RDMA操作的HCA，在DMALen字段中指定的最小长度为0；最大长度为2^31。

o9-3：如果TCA实现RDMA功能，则在DMALen字段中指定的最小长度为0；最大长度为2^31。

## 9.3.4 原子扩展传输头（ATOMICETH）-28字节

原子扩展传输头（AtomicETH）包含用于原子请求操作的附加传输字段。

### 9.3.4.1 虚拟地址（VA）-64位

缓冲区起始地址。

### 9.3.4.2 R_Key-32位

用于验证对指定虚拟地址的远程访问的R_Key。见**第9.3.3.2节“R_Key-32位”**。

### 9.3.4.3 交换（添加）数据（SWAPDT）-64位

原子操作中使用的数据操作数。在CmpSwap操作中，如果CmpDt与现有的缓冲区内容匹配，则将该字段交换到寻址缓冲区中。在FetchAdd操作中，此字段被添加到寻址缓冲区的内容中。

### 9.3.4.4 比较数据（CMPDT）-64位

在CmpSwap原子操作的比较部分中使用的数据操作数。

## 9.3.5 ACK扩展传输头（AETH）-4字节

ACK扩展传输头（AETH）包含ACK数据包的附加传输字段。ACK扩展传输报头包含在所有ACK和RDMA读取响应消息的第一个和最后一个包中。

### 9.3.5.1 综合征/Syndrome

此字段指示这是ACK还是NAK。如果包是ACK并且QP与可靠的连接传输服务相关联，则综合征还提供了限制序列号（LSN）-参见**第9.7.7.2节“端到端（消息级）流控制”**。如果数据包是NAK，则表示错误代码。对于RNR NAK，此字段指示在重新传输请求之前要使用的响应程序请求的计时器。

### 9.3.5.2 消息序列号（MSN）

Responder上完成的最后一条消息的序列号。此字段用于优化请求者的完成处理。

### 9.3.5.3 原子应答扩展传输头（ATOMICACKETH）-8字节

原子应答扩展传输头（AtomicETH）包含用于原子响应操作的附加传输字段。

### 9.3.5.4 原始远程数据（ORIGREMDT）-64位

数据来自原子操作。这是从远程内存缓冲区读取的初始内容。

## 9.3.6 立即扩展传输头（IMMDT）-4字节

立即数据（ImmDt）包含放置在接收完成队列元素（CQE）中的数据。ImmDt只允许在具有立即数据的发送或RDMA写入数据包中使用。

## 9.3.7 失效扩展传输头（IETH）-4字节

SEND with Invalidate操作附带一个R_Key字段。一旦应答方接收并执行SEND with invalidate请求，应答方将使用该R_Key使内存区域或内存窗口失效。

R_Key携带在一个新的扩展传输头中，称为无效扩展传输头（IETH），如下所示。

### 9.3.7.1 R_Key-32位

定义应答方要使其失效的内存区域或内存窗口的R_Key。

## 9.3.8 XRC扩展传输头（XRCETH）-4字节

扩展传输头（XRCETH）包含目标XRC SRQ标识符。

o9-3.a1：如果CA实现XRC传输服务，那么在生成请求包时，发送方应按如下所述设置XRCE字段。

### 9.3.8.1 保留-8位

生成数据包时，发送方应将该字段设置为0x0。接收方应忽略此字段。

### 9.3.8.2 XRCSRQ-24位

此字段表示应答方将用于此数据包的XRC共享接收队列号。

# 9.4 传输功能

QP为传输层的客户端（例如HCA中的verbs层）提供特定的传输服务。不同的传输服务对于有连接和无连接的通信有不同的可靠性级别。本节介绍每个传输服务使用的基本功能。其他传输部分将更深入地介绍响应包、排序、错误恢复等的细节。本节提供了功能及其工作方式的高级概览。

如下文表39所述，并非所有的功能都适用于每项传输服务。原始数据报传输服务不使用IBA定义的传输功能。相反，原始数据报包传输的数据是其他一些非IBA协议的一部分。

## 9.4.1 发送操作

发送操作有时被称为推送操作或具有通道语义。这两个术语都指传输服务的软件客户端（SW client）如何查看数据的移动。通过发送操作，数据传输的发起者将数据推送到远端QP。发起程序不知道数据在远程节点上的去向。远程节点的通道适配器将数据放入该QP的下一个可用接收缓冲区。在HCA上，接收缓冲区的位置由QP接收队列头的WQE指向。

发送操作被称为具有通道语义，因为它移动数据很像主机IO通道——数据被标记为鉴别器（对于IBA，鉴别器/discriminator是目的地LID和QP号），目的地根据鉴别器选择数据放置的位置。

发送操作移动单个消息。对于RC、RD、UC和XRC传输服务，此消息可能比单个数据包长。一条消息的大小可以从零字节到2^31字节不等。

C9-10：请求者生成的发送操作的大小应在0到2^31字节之间（包括2^31字节）。

C9-11：对于HCA中的RC和UC传输服务，长度大于PMTU的请求消息应分段为PMTU大小的段，以便通过多个包进行传输。类似地，HCA接收方应将这些分组重新组合成一个单独的消息。

o9-4：对于HCA中的RD和XRC传输服务，长度大于PMTU的请求消息应分段为PMTU大小的段，以便通过多个包进行传输。类似地，HCA接收方应将这些分组重新组合成一个单独的消息。

o9-5：对于TCA中的RC、UC、RD和XRC传输服务，长度大于PMTU的请求消息应分段为PMTU大小的段，以便通过多个包进行传输。类似地，TCA接收方应将这些分组重新组合成一个单独的消息。

C9-12：对于不可靠的数据报传输服务，发送操作应仅包含单包消息（即消息数据有效载荷限制为请求方和响应方之间的最大PMTU，即256、512、1024、2048或4096字节）。

根据客户机的判断，发送操作可以在每个发送消息中包含4个字节的立即数据（Immediate data）。如果包含，则立即数数据包含在发送操作的最后一个数据包的附加头字段（立即扩展传输头或ImmDt）中。

例如，下面的图76显示了需要3个发送包共700字节的消息发送操作（假设是256字节的PMTU）。

上图中有几点需要注意：

<span>◼ </span>BTH操作码字段确定发送消息的开始和结束。

<span>   </span><span>✸ </span>如果发送信息小于或等于PMTU，则使用BTH操作码“仅发送（SEND Only）”或“仅立即发送（SEND Only with Immediate）”。

<span>   </span><span>✸ </span>如果发送消息的长度为零，则使用BTH操作码“仅发送”或“仅立即发送”。在本例中，没有Data Payload字段，但所有其他字段如图所示。

<span>   </span><span>✸ </span>如果发送消息大于PMTU，则第一个包的BTH操作码为“SEND first”，最后一个数据包的BTH操作码为“SEND last”或“SEND last with Immediate”。

<span>   </span><span>✸ </span>如果发送消息大于PMTU的两倍，则第一个和最后一个之间的包使用BTH操作码“SEND Middle”。

<span>   </span><span>✸ </span>报文中没有操作码“仅发送”、“仅用立即数发送”、“最后发送”或“最后发送并立即发送”的每个数据包应具有PMTU长度的数据字段。

<span>◼ </span>响应节点（发送操作的目的地）直到最后一个带有“SEND last”或“SEND last with Immediate”操作码的数据包到达时才知道发送消息的最终长度。

<span>◼ </span>接收端使用数据包序列号字段来检测无序或丢失的数据包。

<span>◼ </span>如果整个消息不是PMTU的倍数，则消息的初始分组携带完整的PMTU字节数，而最后一个分组将剩余的数据作为部分有效载荷。

<span>◼ </span>对于给定请求节点的QP，一旦多包发送操作开始，在“最后发送”或“立即发送”分组之前，不可能生成其他请求分组（注：QP中的消息的发送是按序进行的）。

C9-13：具有多包的消息不应与同一发送队列上的其他操作交织。

<span>◼ </span>并非所有发送信息都携带立即数据。如果有，则在消息的最后一个或唯一的包中包含一个特殊的报头。报头的存在由BTH中一个特殊的“SEND Last with Immediate Data”或“SEND Only with Immediate Data”操作码指示。

<span>◼ </span>对于HCA，发送消息的源或目标缓冲区没有对齐要求。对于TCA中的缓冲区，任何对齐要求都是特定于实现的。

verbs一章解释了HCA的上层软件客户机如何使用工作请求来发布缓冲数据，而缓冲数据又被分割并作为包在fabric中发送。同一章还描述了目的节点如何发布接收到的缓冲数据，在该缓冲区中目的地HCA将数据重新组装到其中。由TCA发起的发送消息使用特定于实现的机制来创建（并响应）发送包。

C9-14：当为发送操作生成数据包时，请求者应在请求的每个数据包中至少包括这些头和字段：LRH、BTH、ICRC、VCRC。

C9-15：当生成对发送操作的响应时，接收方应至少包括这些报头和响应字段：LRH、BTH、AETH、ICRC、VCRC。

### 9.4.1.1 随失效发送/SEND WITH INVALIDATE

在大多数方面，带有Invalidate的SEND操作与正常的SEND操作完全相同。重要的变化是消息的最后一个（或唯一的）数据包在IETH（失效扩展传输头）中带有一个R_Key。这是使响应端无效的R_Key。实际上，Invalidate功能被附加(piggy-backed)到一个正常的SEND操作上。

对于正常的SEND操作，使用SEND with Invalidate有几点需要注意。下面的所有语句都假定Invalidate操作被附加到“正常”SEND操作上。

<span>◼ </span>如果携带无效操作的发送消息小于或等于PMTU，则使用BTH操作码“仅发送失效/SEND Only with Invalidate”。

<span>◼ </span>如果搭载无效操作的发送消息的长度为零，则使用BTH操作码“仅使用失效发送/SEND Only with Invalidate”。在本例中，没有data payload字段，但所有其他字段如图所示。

<span>◼ </span>如果搭载失效操作的发送报文大于PMTU，则第一个包的BTH操作码为“SEND first”，最后一个包的BTH操作码为“SEND last with invalidate”。该消息的所有其他包的BTH操作码是“SEND Middle”。

<span>◼ </span>发送消息中没有操作码“仅发送”、“仅使用立即发送”、“仅使用无效发送”、“最后发送”、“立即发送”或“最后发送带有无效”操作码的每个数据包都应具有PMTU长度的数据字段。

<span>◼ </span>响应节点（发送操作的目的地）直到最后一个带有“SEND last with invalidate”操作码的数据包到达之前，不知道无效操作所附加到的发送消息的最终长度。

<span>◼ </span>对于给定请求节点的QP，一旦多包发送操作开始，在生成“SEND Last”、“SEND Last with Immediate”或“SEND Last with Invalidate”包之前，不可能生成其他请求包。

远程失效操作用于禁止通过IETH中包含的R_Key访问内存。但是，Invalidate操作会维护与要失效的R_Key相关联的内存转换和保护资源。SEND with Invalidate操作不会禁用对R_Key引用的内存的所有访问，它只是意味着该被失效的R_Key不能再用于访问这些内存区域或内存窗口。引用相同内存的其他R_Key仍然有效。

其目的是使失效操作由通道接口执行，该接口可能包括verbs下面的硬件和软件驱动程序。因此，失效操作可由紧接在传输层硬件上方的软件驱动程序执行。在这种情况下，传输层硬件简单地将IETH向上传递到信道接口的软件部分，该部分执行必要的失效。因此，IETH不作为正常传输包报头验证的一部分进行验证。invalidate操作不会对被引用内存的状态进行任何更改。

#### 9.4.1.1.1 无效的操作顺序

o9-5.2.1：对于任何支持通过Invalidate发送的HCA，在收到IETH时，必须在成功完成正常的传输头验证检查之后才能进行失效操作。

如果包含IETH的包（例如，使用Invalidate发送）不是正常包验证过程中描述的有效包，则不得执行无效操作。然而，由于无效操作不是由传输层执行的，所以无效操作可以在传输层确认生成之前或之后发生，但是在任何情况下，传输层确认（ACK/NAK）并不反映无效操作的成功或失败。

下面定义了SEND with Invalidate操作的排序规则：

1） 在任何SEND with Invalidate操作和任何后续操作之间没有排序保证。因此，请求者不能依靠SEND with Invalidate操作本身来阻止后续操作访问响应者的无效区域。

2） 正常的排序规则适用于RDMA写入、发送或原子操作，然后是SEND with Invalidate操作。在这种情况下，RDMA WRITE、SEND或ATOMIC操作在响应程序执行后续SEND with Invalidate操作之前执行。

3） SEND with Invalidate操作可能会影响以前的RDMA读取操作。因此，当以前的RDMA读取操作仍然未完成时，请求者不应执行带有Invalidate的发送。请求者可以在给定的工作请求（如SEND with Invalidate）上设置Fence属性，以确保在启动后续SEND with Invalidate操作之前，先前未完成的RDMA读取操作已经完成。

4） 与往常一样，响应器总是按顺序返回确认，请求方的WQE总是按顺序完成。

#### 9.4.1.1.2 响应器—R_Key验证

传输层在传输级（transport-level）数据包报头验证期间不验证IETH的R_Key字段。通道接口负责在执行失效之前验证IETH的R_Key字段。因此，IETH不被视为传输头，因此本节不讨论远程失效操作的R_Key验证。

参见第9.4.1.1.3节“使远程内存失效的R_Key验证”，以获取IETH的R_Key字段验证。

#### 9.4.1.1.3 使远程内存失效的R_Key验证

o9-5.2.2：对于支持远程失效的CA，在执行远程失效操作之前，必须验证IETH中包含的R_Key。要被视为有效，必须满足以下所有条件：

1） R_Key不能处于无效状态。

2） 如果该实现支持L_Key和R_Key的单个密钥空间，则IETH中包含的R_Key不得与保留的L_Key相同。

3） 对于HCA，R_Key不能引用（reference）通过注册内存区域或重新注册内存区域创建的内存区域。

4） 对于HCA，R_Key不能引用共享内存区域。

5） 对于HCA，R_Key不能引用与接收IETH的QP不同的保护域相关联的内存区域。

6） 对于HCA，R_Key不能引用类型1内存窗口。有关Windows内存类型的说明，请参见第10.6.7.23节“Windows内存类型”部分。

7） 对于HCA，R_Key不能同时处于有效状态，并且引用的是与接收IETH的QP不同的QP相关联的2A型内存窗口。有关2型内存窗口的说明，请参阅第10.6.7.2.4节“2类内存窗口”。

8） 对于HCA，R_Key不能同时处于有效状态，并且必须引用与接收IETH的QP不同的保护域或QP相关联的2B型内存窗口。有关2型内存窗口的说明，请参阅第10.6.7.2.4节“2类内存窗口”。

9） 对于HCA，R_Key不能同时处于空闲状态并且引用与接收IETH的QP的保护域不同的保护域相关联的类型2内存窗口。有关2型内存窗口的说明，请参阅第10.6.7.2.4节“2类内存窗口”。

注意：如果L_Key及其伴随的R_Key处于空闲状态，则远程失效操作不会更改L_Key及其伴随的R_Key状态。

如上文合规性声明o9-5.2.2：失败中定义的R_Key验证的行为，在表61“响应器错误行为摘要”中标题为“远程失效错误”的条目下定义。

## 9.4.2 RESYNC操作

只有可靠的数据报传输服务才支持RESYNC操作。重新同步/RESYNC请求本质上与零长度可靠数据报只发送(Reliable Datagram Send-Only)请求相同，但有几个独特的属性：

1） 请求端使用RESYNC强制接收端将其预期PSN重置为请求端定义的值，

2）RESYNC携带长度为零的数据负载，

3）要求响应端接受重新同步请求，即使当前执行的请求尚未完成。

4）重新同步请求本身不会直接使用请求端的send WQE，也不会直接使用响应端的receive WQE。

C9-15.a1：重新同步请求应携带零长度的数据有效载荷。

## 9.4.3 RDMA写入操作

RDMA写入操作由请求节点用于写入目标节点的虚拟地址空间。消息可以在0到2^31字节（包括0和2^31字节）之间，并且被写入目的地QP的虚拟地址空间的连续范围（不一定是物理存储器的连续范围）。

C9-16：对于执行RDMA写入操作的HCA请求端，RDMA写入消息的长度，如RETH:DMALen字段指定，应在0到2^31字节之间（包括2^31字节）。

o9-6：如果TCA请求端实现RDMA写入功能，则RDMA写入消息的长度，如RETH:DMALen字段指示，应在0到2^31字节之间（包括2^31字节）。

在允许传入的RDMA写入之前，目标节点首先分配一个内存范围供相关目标QP（或QP组）访问。目的地的通道适配器将一个32位R_Key与此内存区域或窗口相关联。对于HCA，verbs层将其称为注册内存区域——参见**第10.6节“内存管理”**。TCA使用特定于实现的机制来分配和管理不再IBA规范范围之内的R_Key。

目的地将虚拟地址、长度和R_Key传递给它希望访问其内存区域的任何其他主机。地址和密钥的通信（交互）由客户端上层协议完成，不在IBA的范围内。例如，应用程序可以将地址、长度和R_Key嵌入到私有数据结构中，然后使用SEND操作将其推送到其他应用程序。

C9-17：与发送操作一样，HCA请求者应将大于PMTU的RDMA写入消息分成多个包。

o9-7：如果TCA请求端实现RDMA写入功能，它应将大于PMTU的RDMA写入消息分成多个包。

如果由verbs层指定，则立即数据将包含在RDMA写入消息的最后一个数据包中。立即数据不会写入目标虚拟地址范围，而是在成功处理最后一个RDMA写入数据包后传递给客户端。例如，在HCA上，立即数据被放在完成队列上。

例如，下面的图77显示了一个700字节的RDMA写入（在256B PMTU的路径上）。

上图中有几点需要注意：

<span>◼ </span>BTH操作码字段确定RDMA写入消息的开始和结束。

<span>   </span><span>✸ </span>如果RDMA写入请求的长度为零，则使用BTH操作码“RDMA WRITE Only”或“RDMA WRITE Only with Immediate”。在本例中，没有datapayload字段，但所有其他字段如图所示。

<span>   </span><span>✸ </span>如果RDMA写入消息小于或等于PMTU，则使用BTH操作码“RDMA只写”或“RDMA只写立即数”。

<span>   </span><span>✸ </span>如果RDMA写入消息大于PMTU，则第一个数据包的BTH操作码为“RDMA WRITE first”，最后一个数据包的BTH操作码为“RDMA WRITE last”或“RDMA WRITE last with Immediate”。

<span>   </span><span>✸ </span>如果RDMA写入消息大于PMTU的两倍，则第一个和最后一个之间的数据包使用BTH操作码“RDMA写入中间”。

<span>   </span><span>✸ </span>RDMA WRITE消息中没有操作码RDMA WRITE Only、RDMA WRITE Only with Immediate、RDMA WRITE Last或RDMA WRITE Last with IMPLICATE的每个数据包都有一个PMTU长度的数据字段。

<span>◼ </span>RETH报头出现在消息的第一个（或唯一）包中。它包含目标缓冲区的虚拟地址以及R_Key和消息长度字段。

<span>◼ </span>接收端使用数据包序列号字段来检测无序或丢失的数据包。

<span>◼ </span>如果整个消息不是PMTU的倍数，则消息的初始分组携带完整的PMTU字节数，而最后一个分组在部分有效载荷中携带剩余部分。

<span>◼ </span>对于给定的请求节点的QP，一旦开始多包RDMA写入操作，在发送“RDMA Last”或“RDMA Last with Immediate Data”包之前，不可能生成其他请求包。

C9-18：对于HCA RDMA写入请求，多包消息不应与同一发送队列上的其他操作交织。

o9-8：如果TCA请求者实现RDMA写入功能，则对于RDMA写入请求，多包消息不应与同一发送队列上的其他操作交叉。

<span>◼ </span>并非所有RDMA写入消息都携带立即数据（Immediate data）。如果是RDMA写入，则在消息的最后（或唯一）包中包含一个特殊的报头。报头的存在由一个特殊的“RDMA WRITE Last with Immediate Data”或“RDMA WRITE Only with Immediate Data”操作码指示。

<span>◼ </span>对于HCA，RDMA写入消息的源或目标缓冲区没有对齐要求。对于TCA中的缓冲区，任何对齐要求都是特定于实现的。

C9-19：当生成RDMA写入请求时，HCA请求者应在每个请求包中至少包括以下报头和字段：LRH、BTH、数据有效载荷、ICRC、VCRC。请求的第一个（或唯一一个）包也应包括RETH。

o9-9：如果TCA请求程序实现RDMA写入功能，则其行为应如下所示。生成RDMA写入请求时，TCA请求程序应在每个请求包中至少包括以下标头和字段：LRH、BTH、数据有效载荷、ICRC、VCRC。请求的第一个（或唯一一个）包也应包括RETH。

C9-20：生成RDMA写入响应时，HCA响应端应在每个响应包中至少包括以下标头和字段：LRH、BTH、AETH、ICRC、VCRC。

o9-10：如果TCA响应端实现RDMA写入功能，则在生成RDMA写入响应时，TCA应答方应在每个响应包中至少包括以下报头和字段：LRH、BTH、AETH、ICRC、VCRC。

## 9.4.4 RDMA读取操作

RDMA读取操作与RDMA写入操作类似。它们允许请求节点读取远程节点上几乎相邻的内存块。与RDMA写入一样，响应节点首先允许请求节点根据权限访问其内存。响应者向请求者传递一个虚拟地址、长度和R_Key，以便在RDMA读取请求包中使用。

单个RDMA读取请求可以读取0到2^31字节（包括2^31字节）的数据。

C9-21：对于响应RDMA读取请求的HCA，如果请求的数据大小大于PMTU，则响应者应将数据分成PMTU大小的数据段，作为多个RDMA读取响应包进行传输。数据在请求节点的内存中重新组合。

o9-11：如果TCA应答端实现RDMA读取功能，并且请求的数据大小大于PMTU，则应答端应将数据分成PMTU大小的数据段，作为多个RDMA读响应包进行传输。数据在请求节点的内存中重新组合。

C9-22：请求者使用RDMA的数据长度，反映在RDMA中RETH:DMALen字段，应在0到2^31字节之间（包括2^31字节）。

o9-12：如果TCA请求端实现RDMA读取功能，则请求的RDMA读取数据的长度，如RETH:DMALen字段，应在0到2^31字节之间（包括2^31字节）。

下面的图78中的示例显示了一个700字节的RDMA读取操作（在一个256B PMTU的路径上）。

上图中有几点需要注意：

<span>◼ </span>如果读取长度大于PMTU，单个请求包将导致多个读响应包。

<span>◼ </span>BTH操作码字段将数据包标识为RDMA读取请求或响应，并确定是否存在任何扩展传输头。

<span>◼ </span>BTH操作码字段确定RDMA读取确认消息的开始和结束。

<span>   </span><span>✸ </span>如果RDMA读取请求消息请求零字节传输，则使用BTH操作码“RDMA READ Response Only”。所有其他字段保持如图所示。

<span>   </span><span>✸ </span>如果RDMA读取确认消息小于或等于PMTU，则使用BTH操作码“RDMA READ Response Only”。

<span>   </span><span>✸ </span>如果RDMA READ消息大于PMTU，则第一个数据包的BTH操作码为“RDMA READ Response first”，最后一个数据包的BTH操作码为“RDMA READ Response last”。

<span>   </span><span>✸ </span>如果RDMA读取响应消息大于PMTU的两倍，则第一个和最后一个之间的数据包使用BTH操作码“RDMA读取响应中间”。

<span>   </span><span>✸ </span>RDMA READ Response First或RDMA READ Response Middle消息中的每个数据包都有一个PMTU长度的数据字段。

<span>◼ </span>如果整个消息大于PMTU的倍数，则响应消息的初始分组携带完整的PMTU字节数，而最终分组携带部分有效载荷。

<span>◼ </span>数据包序列号（PSN）字段用于检测无序或丢失的响应数据包。

<span>◼ </span>在启动RDMA读取请求包之后，请求节点可以发送额外的请求包，而不必等待响应包返回。请参阅**第9.7.3.1节“请求端-生成PSN”**，了解如何为后续请求包确定PSN。

<span>◼ </span>一个特定QP在任何时候的RDMA读请求的最大数量都是在连接建立时协商的。响应程序可以将连接限制为每个QP只有一个未完成的RDMA读取请求。如果支持原子操作，则在建立连接时协商的未完成请求数包括原子操作请求和RDMA读取请求。

<span>◼ </span>RDMA读取数据包从不携带立即数据。

如果请求程序（请求发起端）没有收到正确的响应，则会重试RDMA读取请求。

<span>◼ </span>重试的RDMA读取请求不需要从相同的地址开始，也不需要与原始RDMA读取具有相同的长度。重试请求只能重新读取第一次未成功响应的部分。

<span>◼ </span>响应端验证重试请求的R_Key和RDMA读取虚拟地址。

<span>◼ </span>重试的RDMA读取的PSN必须在重复的PSN区域中。参见**第9.7.1节“分组序列号（PSN）”**。

<span>◼ </span>重试的RDMA读取请求的PSN不必与原始RDMA读取请求的PSN相同。任何重试的请求都必须与原始RDMA读取请求的子集完全对应，使得所有潜在的重复响应包必须具有相同的有效负载数据和PSN，而不管它是对原始请求的响应还是对重试请求的响应。

<span>◼ </span>对于HCA，RDMA读取消息的源或目标缓冲区没有对齐要求。对于TCA中的缓冲区，任何对齐要求都是特定于实现的。

C9-23：当生成RDMA读取请求时，HCA请求者应在其请求包中至少包括以下报头和字段：LRH、BTH、RETH、ICRC、VCRC。

o9-13：如果TCA请求者实现RDMA操作，则其请求包中至少应包括以下报头和字段：LRH、BTH、RETH、ICRC、VCRC。

C9-24：当生成RDMA读取响应时，HCA响应器应在每个响应包中至少包括以下报头和字段：LRH、BTH、数据有效载荷、ICRC、VCRC。如果响应包BTH:Opcode是“RDMA READ Response First，RDMA READ Response Last，或者仅RDMA读取响应（RDMA READ Response Only），数据包还应包括AETH。如果响应包BTH:Opcode是“RDMA读取响应中间”，不应包括AETH。

o9-14：如果TCA响应器执行RDMA操作，则每个响应包中至少应包括以下报头和字段：LRH，BTH，数据有效载荷，ICRC，VCRC。如果BTH:Opcode是“READ Response First，RDMA READ Response Last，或者仅RDMA读取响应，数据包还应包括AETH。如果响应包BTH:Opcode是“RDMA读取响应中间，不应包括AETH。

## 9.4.5 原子操作

原子操作在远程节点上的指定地址执行64位操作。这些操作自动地读取、修改和写入目标地址，并保证同一CA上的其他QP对该地址的操作不会在读写之间发生。原子性保证的范围可以选择性地扩展到其他CPU和HCA。

原子操作使用与RDMA读写相同的远程内存寻址机制。请求包中指定的虚拟地址位于原子操作所针对的远程QP的地址空间中。

原子操作包括两种包类型，“原子命令/ATOMIC Command”请求包和“原子应答/ATOMIC Acknowledge”响应包。

1）原子操作仅由可靠的连接和可靠的数据报传输服务支持。

2）原子操作不支持立即数据。

3）强烈建议严格在硬件中提供原子操作支持。

4）原子命令请求包中的虚拟地址应自然地与8字节边界对齐。响应的CA会对此进行检查，如果请求不自然对齐，则返回一个无效的请求NAK。

IBA定义了以下原子操作：

<span>◼ </span>FetchAdd（Fetch and Add）

FetchAdd原子操作告诉响应端在响应端内存中自然对齐的虚拟地址读取64位内存值，使用AtomicETH中的64位Add数据字段执行无符号加法，并将结果（必须与请求方的内存类型匹配）写回相同的虚拟地址。根据**第9.4.5.1节“原子性保证”**，响应端的操作应为原子操作（即不受其他实体干扰）。

FetchAdd操作以目标内存的endian格式执行。原始远程数据从目标内存的endian格式转换并返回。这些字段在线路上是大端格式。

请求者指定：

<span>   </span><span>✸ </span>远程数据地址和R_Key

<span>   </span><span>✸ </span>Add数据

确认数据包返回：

<span>◼ </span>原始远程数据

操作后，响应端在指定虚拟地址的内存中包含原始值和AtomicETH头中的Add字段的无符号和。对请求者内存的所有操作都是以请求者的本机endian格式完成的。

<span>◼ </span>CmpSwap（Compare and Swap）

CmpSwap原子操作告诉响应端读取响应端内存中自然对齐的虚拟地址处的64位值，将其与Atomicheth头中的比较数据字段进行比较，如果相等，则将AtomicETH头中的交换数据字段写入同一虚拟地址。如果它们不相等，响应端内存的内容不会改变。在这两种情况下，从虚拟地址读取的原始值将返回给请求者。根据**第9.4.5.1节“原子性保证”**，响应端的操作应为原子操作（即不受其他实体干扰）。

请求者指定：

<span>◼ </span>远程数据地址和R_Key

<span>◼ </span>写入（交换）数据

<span>◼ </span>比较数据

确认数据包返回:

<span>◼ </span>原始远程数据

操作后，远程数据缓冲区包含“原始远程值”（如果比较不匹配）或“写入（交换）数据”（如果比较匹配）。

CmpSwap操作涉及三个8字节的数据缓冲区：比较数据、写入（交换）数据和原始远程数据。这三种格式都是以字节big-endian（大端序）格式在请求和响应包中传输的。所有CA响应端的内存操作都是在本机内存中完成的。对请求者内存的所有操作都是以请求者的本机endian格式完成的。

例如，考虑一个big-endian CA向一个little-endian响应程序发起一个CmpSwap原子操作请求包。请求包包含两个大端数据字段：比较数据和写入（交换）数据。响应程序将这些数据字段转换为little-endian格式，并执行比较和交换操作。原始目标数据字段被转换为big-endian格式并返回到响应包中。

o9-15：生成原子操作请求时，请求者应至少包括LRH、BTH、AtomicETH、ICRC和VCRC。LRH、BTH和AtomicETH报头的数据源应如表63“分组字段和服务参数”所示。

o9-16：在响应原子操作请求时，响应端应在其响应包中至少包括一个LRH、BTH、AETH、AtomicAckETH、ICRC和VCRC。

### 9.4.5.1 原子性保证/ATOMICITY GUARANTEES

o9-17：在同一CA上的其他QP并发原子访问的情况下，原子操作对响应方节点的读/改/写的原子性应得到保证。

o9-18：CA可以选择性地保证原子操作在存在来自其他CA、IO设备和CPU的并发内存访问的情况下的原子性。对于HCA，verbs层应该报告它是否支持这种增强的原子性保证。

### 9.4.5.2 原子确认生成和排序规则

1） 对于请求者，当响应包返回时，原子操作被认为是已经完成了的。

2） 如果RDMA读取工作请求在原子操作工作请求之前发布，则原子可以在之前的RDMA读取操作读取其数据之前执行其远程内存操作。这是因为允许响应程序延迟RDMA读取的执行（执行的没有那么及时）。通过使用fence修饰符（modifier）发布原子操作工作请求，可以确保严格的排序。请参阅fence修饰符Post Send Request的说明。fence修饰符使请求者在发出原子操作之前等待RDMA读取完成。

3） 当一个请求序列到达QP时，原子操作仅在先前（非RDMA读取）请求访问内存之后和随后的请求访问内存之前访问内存。由于响应端需要时间来向原子请求发出响应，并且此响应需要更多的时间到达请求者，请求者甚至需要更多的时间来创建完成队列条目，原子之后的请求可以在请求者为原子操作请求写入完成队列条目之前访问响应程序内存。

4） 每个原子操作请求都需要显式响应和确认消息。具有正确格式的AETH的原子操作响应被视为确认消息。

### 9.4.5.3 错误行为

响应端利用特定于供应商的资源和设施来实现原子操作和RDMA读取，并实现重试的原子请求。请求者有责任确保所有未确认的原子操作和RDMA读取组合在一起不会使接收端资源溢出。这些资源的数量在连接设置时按每个QP协商设定（见**第9.4.4节“RDMA读取操作”**和**第9.4.5节“原子操作”**）。

响应节点保存应答数据、PSN和表明存储的数据来自原子操作的指示。此保存的数据用于为重试的原子操作生成响应。请注意，RDMA读取操作的执行可能会消耗用于保存原子操作PSN和应答数据的相同资源。信息存储在目的地QP的“连接上下文”中。“连接上下文”是用于可靠连接服务的QP上下文。对于可靠的数据报服务，“连接上下文”实际上是“EE上下文”。

有几个规则确定响应端何时存储原子操作的PSN和应答数据：

<span>◼ </span>只保存有效的、新的原子操作请求（即所有头检查都有效，传入的PSN与预期的PSN匹配，R_Key对正在访问的数据有效，地址与64b边界对齐）。

<span>◼ </span>如果响应的QP支持多个未完成的原子操作和RDMA读取操作，则每个有效请求的信息按FIFO顺序保存。FIFO深度与连接设置时基于每个QP协商的未完成原子操作和RDMA读取请求的最大数量相同。

<span>◼ </span>不会再次保存重复的原子或RDMA读取操作。

保存的原子和RDMA读取状态如下图所示。

原子操作保证最多执行一次。如果在目的地上没有执行原子操作，则向发送方报告该操作（例如，R_Key保护故障），并给出相应的NAK Syndrome响应。

然而，与所有操作一样，在响应端执行之后，在响应端到达请求端之前发生的不可恢复错误（例如致命的HCA错误），会导致请求端不知道响应端内存的状态。这种情况必须由客户端或上层协议检测和处理。

与所有操作一样，任何传输都可能发生错误。如果原始的“原子命令”请求丢失，或者“原子应答”丢失，发送方将使用正常的重试过程重试。如果重试失败，则无法确定原子操作是否发生在目标上，但连接将处于错误状态。

与重试Send和RDMA写操作一样，如果响应的CA实际执行了请求，它只会再次确认请求，而不会重新运行原子操作。这是必要的，因为原子操作不是幂等的。响应程序识别重试的原子操作，并从先前存储在QP（或可靠数据报服务的EE上下文）“隐藏状态”中的原始确认返回应答数据。如果满足以下条件，则响应程序返回原子操作的存储结果：

<span>◼ </span>请求有效（即报头操作码有效）

<span>◼ </span>请求为原子操作（应答方可检查原子操作操作码是否与存储操作相同）

<span>◼ </span>请求的PSN在“重复区域”。参见**第9.7.1节“分组序列号（PSN）”**中对PSN空间的描述。

<span>◼ </span>PSN与保存的原子操作相匹配。

不满足上述条件的重试原子操作将被响应程序丢弃。参见表61响应程序错误行为摘要，当原子操作被重试时，响应程序不会验证R_Key，也不会转换重试请求中的虚拟地址。

下图演示了失败的原子操作响应包，并显示了重试的请求和最终成功的响应。

如果所有重试都失败，这意味着连接丢失，并且请求CA的驱动程序中的错误恢复例程将通知本地应用程序。

操作的大小总是64位。目标必须自然对齐（虚拟地址的低3位必须为零）。如果R_Key范围没有完全包围目标，则会报告错误。如果发生此或其他保护错误，将报告（NAK_Remote_Access），但不会导致占用任何“原子操作隐藏队列”资源。也就是说，如果相同的请求被重复（相同的PSN），并且响应方随后已经分配了R_Key范围，那么这个新操作现在将成功。

## 9.4.6 保留及制造商定义的传输功能操作码

IBA的传输层未来扩展有两种机制：

<span>◼ </span>保留和制造商定义的BTH操作码

IBA传输层功能可通过定义新的BTH操作码进行扩展。指定了两个未定义的操作码块。一个用于IBA的未来修订版，另一个块用于制造商特定功能。

# 9.5 处理顺序/TRANSACTION ORDERING

本节定义了给定QP事务的传输、执行和完成顺序规则：

C9-25：请求者应按照发布到工作队列元素（WQE）的顺序传输请求消息。

C9-26：对于分割为PMTU大小数据包的消息，数据有效载荷应使用与WQE定义的数据段相同的顺序。

从给定源QP到给定目的地QP的包在通过fabric的同一路径上传输，并且以注入它们的相同顺序接收。

C9-27：对于HCA上的可靠服务，所有确认数据包都应是强有序的，例如，在随后的发送、RDMA写入响应、RDMA读取响应或原子操作响应之前，应将所有先前的RDMA读取响应和原子响应注入到fabric中。

o9-19：如果TCA响应器实现可靠的连接服务，或者CA响应器实现可靠的数据报服务或XRC服务，则所有的应答报文都应是强序的。也就是说，所有先前的RDMA读取响应和原子响应都应在随后的发送、RDMA写入响应、RDMA读取响应或原子操作响应之前注入到fabric中。

C9-28：响应端应按照接收到的消息顺序执行发送请求、RDMA写入请求和原子操作请求。如果请求是针对不受支持的功能或服务，适当的响应（例如，NAK消息、静默丢弃或错误日志记录）也应按照接收的PSN顺序生成。

<span>◼ </span>应用程序不应依赖于消息中数据写入内存的顺序。例如，如果应用程序为消息中的单独数据段设置了重叠的数据缓冲区，则不能保证最后发送的数据总是覆盖先前的数据段。

C9-29：接收方的完成按发送的顺序进行（仅适用于发送和RDMA立即写入），并不意味着以前的RDMA读取已完成，除非被请求方隔离。

C9-30：请求者应按照发送的顺序完成WQEs。

C9-31：设置了fence属性的工作请求将被阻止，直到所有先前的RDMA读取和原子工作请求都已完成。

C9-32：所有WQE应按照其发布的顺序完成，独立于其执行顺序。

由于对可靠服务的请求和响应的排序规则保证，请求者可以在收到响应后编写CQ完成事件。

o9-20：除非发生以下情况之一，否则应用程序不应依赖于响应程序处RDMA写入缓冲区的内容：

<span>◼ </span>与立即数据一起使用时，最后一个RDMA写入请求包的到达和完成。

<span>◼ </span>到达并完成后续发送消息。

<span>◼ </span>通过后续原子操作更新内存元素。

o9-21：在相应的WQE完成之前，应用程序不应该依赖于请求者的RDMA读目标缓冲区的内容。

o9-21.a1：在完成应用之前，应用程序不应依赖于响应器的发送缓冲区的内容。

C9-33：在相应的接收WQE完成之前，应用程序不应依赖于接收队列缓冲区的内容。

# 9.6 分组传输报头验证

对从较低的IBA层传递到传输层的每个包执行包传输报头验证。目的是确定入站数据包可以与特定的队列对相关联。如果不能，包将被悄悄地丢弃。数据包传输头验证仅适用于使用IBA传输的数据包。

C9-34：传输层应根据本节中的要求使用IBA传输来验证所有数据包的数据包报头（**第9.6节“分组传输报头验证”**）。如果LRH:LNH字段的msb设置为1，则认为该分组正在使用IBA传输。如果LRH:LNH字段的msb设置为0，则该分组是原始分组。原始数据包在**第9.8.4节“原始数据报”**中进行了描述。

C9-35：对于使用IBA传输的每个入站数据包，CA应根据图82所示的状态图验证数据包。状态图的细节将在本节的剩余部分中讨论。

如果分组可以与给定的队列对相关联，则通过将分组的某些特征与与队列对一起存储的上下文信息（或者在可靠数据报服务的情况下，EE上下文）进行比较来执行进一步的验证。**第9.7节“可靠服务”**和**第9.8节“不可靠服务”**对验证水平进行了说明。

在本节中，使用了 “数据包被静默丢弃”的说法。除非另有说明，否则当发生静默丢弃时，响应方的行为如下：

<span>◼ </span>不返回确认信息。

<span>◼ </span>响应器不消耗接收WQE。

<span>◼ </span>错误请求包未执行。

<span>◼ </span>在错误请求之前收到的任何请求包都将正常执行和完成。

<span>◼ </span>响应器不更新其预期PSN。

<span>◼ </span>响应程序继续等待有效的入站请求数据包。

除非另有说明，否则请求者在发生静默丢弃时的行为如下：

<span>◼ </span>没有发送WQE是由于数据包被静默丢弃而完成的。

<span>◼ </span>虽然错误计数器可能会增加或发生其他类似的事件，但不会因静默丢弃的数据包而采取直接操作。

<span>◼ </span>为了满足传输计时器的要求，静默丢弃的数据包不应计算在内。

不会更改队列状态。此外，对于已连接的传输服务或可靠的数据报，连接或EE上下文不会被破坏。

## 9.6.1 验证报文头字段

本节指定了入站数据包（请求或响应数据包）的接收方在依赖数据包的完整性之前必须验证的标头和字段。

### 9.6.1.1 BTH检查

本节描述必须为所有传入数据包验证的BTH字段。

#### 9.6.1.1.1 BTH:TVER验证

C9-36：传输应验证CA或路由器是否支持传输头的版本号。如果CA、交换机或路由器不支持指定的版本，则应静默丢弃数据包。唯一有效的传输版本是零。

tver_check

<span>◼ </span>good：BTH的tver字段为0x0

<span>◼ </span>bad：BTH的tver字段为非零

#### 9.6.1.1.2 BTH的目的地QP、操作码检查

由于入站分组的BTH中包含的操作码用于确定所选目的地QP是否有效，因此操作码验证与验证目的地QP及其当前状态相结合。

C9-37：传输层应验证目的地QP是否存在，以及QP状态对于接收入站数据包有效。

o9-22：本合规声明已作废，由o9-23.2.1代替：

o9-23：对于支持不可靠数据报多播的CA，只有当至少有一个本地管理的QP配置为IBA不可靠数据报多播服务时，0xFFFFFF的目标QP值才有效。

C9-38：应检查BTH:OpCode[7:5]以确保请求的服务（RC、UC、RD、UD、XRC）与目的地QP的配置一致。

对包含无效目的地QP或其目的地QP不处于接收入站分组的有效状态的入站分组的响应取决于所请求的服务。这是通过检查确定的BTH:OpCode [7:5]，表示请求的服务是RC、RD、UC、UD还是XRC。

此外，如果BTH:OpCode[7:5]表示数据包用于RD服务，则必须检查其余操作码位，以确定入站数据包是请求包还是响应包。

C9-39：如果BTH:OpCode[7:5]表示该数据包用于RC、UC、UD或XRC服务，且目的QP不存在，或目的QP未配置为提供所请求的服务，或目的QP状态无效，则入站数据包被静默丢弃。

C9-40：本合规声明已作废，由o9-23.2.1代替：

o9-23.2.1：对于实现RD服务的CA：如果BTH:OpCode[7:0]表示RD请求包，（SEND，RDMA READ request等），EE上下文有效，目的QP不存在，或者目的QP未配置为提供RD服务，或者目的QP状态无效，然后必须返回NAK-invalid RD请求。如果BTH:OpCode[7:0]表示一个RD响应包（RDMA读响应、应答等），且目的QP不存在，或目的QP未配置为提供RD服务，或目的QP状态无效，则应静默丢弃入站数据包。

destqp_check

<span>◼ </span>good：BTH中指定的目的QP是有效的QP，并且处于接收分组的正确状态，并且QP的配置与所请求的服务一致。

<span>◼ </span>bad：BTH中指定的目标QP不存在，或不处于接收数据包的正确状态，或配置与请求的服务不一致。

#### 9.6.1.1.3 BTH:P_Key

C9-41：如果目的地QP是QP0，则BTH:P_Key不用检查。

C9-42：如果目的地QP是QP1，则BTH:P_Key应与数据包到达的端口相关联的P_Key集进行比较。如果P_Key与端口相关联的任何一个密钥相匹配，则认为它是有效的。

C9-43：对于除QP0或QP1以外的所有目的地QP，对于除可靠数据报之外的所有传输服务，P_Key应与与响应者的接收队列相关联的P_Key进行比较。无效的P_Key将导致请求包被静默丢弃。

o9-24：对于可靠的数据报，应将P_Key与响应者的EE上下文相关联的P_Key进行比较。无效的P_Key将导致请求包被静默丢弃。

有关匹配P_Key的详细过程，请参阅**第10.9.3节“分区密钥匹配”**。

pkey_check

<span>◼ </span>good：BTH:P_Key匹配与recv queue或EE上下文关联的值。

<span>◼ </span>bad：BTH:P_Key与recv queue或EE上下文关联的值不匹配

### 9.6.1.2 GRH检查

本节描述了必须验证的GRH字段（如果存在）。

在接收入站分组之前，QP或EEC被配置为在该连接上接收的每个分组中是否期望带有GRH字段。进行此配置的机制超出了规范的范围。一种可能的实现是，通过CM REQ消息中的子网本地位（Subnet Local bit），该配置在连接建立时发生。只有当GRH的存在或不存在与QP（或EEC）配置一致时，才能保证入站数据包通过GRH检查。对于RC、RD、UC和XRC服务，如果到达的入站数据包与关于GRH存在或不存在的QP（或EEC）配置不一致，则应丢弃该数据包。对于UD服务，由于预测数据包的来源是不切实际的，因此不应检查GRH的存在与否。

如**第9.6.1.6.2节“IBA不可靠多播检查”**所述，多播数据包必须包含GRH。

C9-43.1.1：对于UD服务，如果包是**第9.6.1.6.2节“IBA不可靠多播检查”**中规定的多播数据包，并且该数据包中不存在GRH，则该数据包应静默丢弃。

C9-43.1.2：对于RC、RD、UC和XRC服务，如果接收到的数据包与QP（或EEC）在GRH存在或不存在方面的配置一致，则该数据包应被视为已通过GRH检查，符合**第9.6.1.2节“GRH检查”**的剩余部分。

#### 9.6.1.2.1 GRH:Next HEADER

C9-44：如果存在GRH，则必须检查GRH的下一个报头字段。下一个报头字段的值应设置为0x1B。任何其他值都表示此数据包不使用IBA传输，并且该数据包应静默丢弃。

nxthdr_check

<span>◼ </span>good：GRH:NxtHdr字段表示IBA传输

<span>◼ </span>bad：GRH:NxtHdr字段表示非IBA传输

#### 9.6.1.2.2 GRH:IPVERS

C9-45：如果存在GRH，则应检查GRH的版本字段。如果版本号不是6，则数据包应静默丢弃。

ip_vers

<span>◼ </span>not_v6：无效的GRH版本号

<span>◼ </span>v6：GRH版本号有效

#### 9.6.1.2.3 GRH:SGID, GRH:DGID

连接管理层负责在传输层加载主SGID和DGID。如果给定的CA支持自动路径迁移，那么还将加载一组备用SGID和DGID。主要和备用GID比较和操作按照**第17.2.8节“自动路径迁移”**中定义的规则进行。

如果存在GRH，则SGID和DGID应按照以下方式进行验证：

C9-46：如果目的地QP配置为UD传输服务，则不应在传输层验证SGID。只有当数据包是有效的多播数据包时，才应验证DGID。有关有效多播数据包的定义，请参阅**第9.6.1.6.2节“IBA不可靠多播检查”**。

C9-47：本合规声明已过时，由C9-47.1.1代替：

C9-47.1.1：如果目的地QP配置为RC、UC、RD或XRC传输服务，则SGID和DGID应在传输层进行验证。不能通过这些有效性检查的数据包必须静默地丢弃。

DGID验证如下：

1） 如果DGID设置为保留的GID，则DGID无效。

2） 如果DGID设置为环回GID，则DGID无效。

3） 如果DGID的作用域指示多播GID，但没有本地关联的QP，则DGID无效。

在这些检查之后，将DGID与以下内容进行比较。如果不匹配任何一个，则DGID无效。

4） 将DGID与主DGID进行比较。

5） DGID的高64位与默认GID前缀（0xFE80::0）进行比较，DGID的低64位与主DGID的低64位进行比较

6）如果支持自动路径迁移，则将DGID与备用DGID进行比较。

7） 如果支持自动路径迁移，则将DGID的高64位与默认的GID前缀（0xFE80::0）进行比较，并将DGID的低64位与备用DGID的低64位进行比较。

SGID的验证如下：

1） 如果SGID设置为组播，则SGID无效。

2） 如果SGID设置为环回GID，则SGID无效。

在这些检查之后，将SGID与以下内容进行比较。如果SGID至少不匹配以下一项，则它是无效的。

3） SGID与主SGID进行比较

4）SGID的高64位与默认GID前缀（0xFE80::0）进行比较，SGID的低64位与主SGID的低64位进行比较

5）如果支持自动路径迁移，则将SGID与备用SGID进行比较

6）如果自动路径迁移支持SGID的高64位与默认GID前缀（0xFE80::0）进行比较，SGID的低64位与备用SGID低64位进行比较.

gid_check

<span>◼ </span>good：GRH SGID和DGID比较成功

<span>◼ </span>bad：GRH SGID或DGID无效

### 9.6.1.3 XRC检查

本节描述了XRC的字段（如果存在），这些字段必须为XRC服务

XRC_check

<span>◼ </span>good：XRC-QP域与XRC TGT QP域相同

<span>◼ </span>bad：XRC-QP域与XRC TGT QP域不相同

o9-24.a1：如果BTH:OpCode[7:5]表示是XRC传输服务，XRCETH应根据**第9.7.9.2节“XRC数据包格式规则”**进行验证.

### 9.6.1.4 RDETH检查

本节描述RDETH的字段（如果存在的话），这些字段必须为可靠的数据报服务进行验证。

#### 9.6.1.4.1 RDETH:EE上下文

C9-47.2.1：如果BTH:OpCode[7:5]表示RD传输服务且CA不实现RD服务，则必须静默丢弃数据包。

o9-25：如果BTH:OpCode [7:5]表示RD传输服务，RDETH应被验证。

o9-26：EE上下文标识符应按照表41“EE上下文验证”中的规则进行验证。如果EE上下文无效，则必须静默丢弃数据包。

context_check

<span>◼ </span>good：RDETH中指定的EE Context有效

<span>◼ </span>bad：RDETH中指定的EE Context无效或CA不支持RD传输服务

### 9.6.1.5 DETH CHECKS

本节描述了必须检查数据报服务的DETH字段（如果存在），无论是可靠的还是不可靠的。

#### 9.6.1.5.1 DETH:Q_Key

C9-48：如果目的地QP是QP0，则DETH:Q_Key不应验证字段。

C9-49：如果目的地QP是QP1，如果DETH:Q_Key字段与著名的Q_Key 0x80010000成功比较，则认为该字段有效。

C9-50：对于为数据报服务配置的队列对接收到的所有数据包，除QP0外，Q_Key应由接收方的接收队列检查。如果Q_Key不匹配，应答方的行为取决于服务是不可靠的数据报还是可靠的数据报，并应如下所示：

不可靠的数据报：数据包应静默丢弃。

可靠数据报：

<span>◼ </span>应返回NAK-Invalid RD请求。

<span>◼ </span>NAK中使用的P_Key可以由响应者的EE上下文提供，或者可以从被确认的请求包中提取。

<span>◼ </span>NAK消息中使用的PSN是错误请求包的PSN。

<span>◼ </span>EE上下文的PSN不变；它仍然指向失败的请求包。

<span>◼ </span>响应程序继续等待有效的入站请求包。

C9-51：在接收队列检查包的Q_Key和P_Key之前，响应程序不得返回包的确认消息。

qkey_check

<span>◼ </span>good：DETH中包含的Q_Key与接收队列存储的Q_Key相匹配。

<span>◼ </span>bad：DETH中包含的Q_Key与接收队列存储的Q_Key不匹配。

### 9.6.1.6 LRH检查

本节描述必须为所有入站数据包验证的LRH字段。

#### 9.6.1.6.1 LRH:SLID、LRH:DLID

C9-52：应验证LRH中包含的16位完全解析的SLID和DLID的有效性。

C9-53：DLID仅对可靠连接、不可靠连接或可靠数据报服务（包括XRC）进行验证。对于不可靠的数据报服务，不应对DLID进行验证。

C9-54：仅对可靠连接、不可靠连接或可靠数据报服务（包括XRC）进行验证。对于不可靠的数据报服务或如果QP或EEC配置为预期GRH，则不应验证SLID-见**第9.6.1.2节“GRH检查”**。

为了有效， LRH中包含的SLID和DLID必须与以下之一完全比较：

1）许可（permissive）LID

2）多播LID（仅适用于DLID）

3）主LID

4）备用LID

C9-55：仅当目标队列对为QP0时，许可LID才被视为有效。

C9-56：如果SLID是多播LID，则无效。

C9-57：在配置为可靠连接或不可靠连接服务的HCA中，如果检测到无效的LID，则应静默丢弃数据包。对于RC和UC服务，此检查由发送或接收队列执行。

o9-27：如果TCA执行可靠连接或不可靠连接服务，并且检测到无效的LID，则应静默丢弃数据包。对于RC和UC服务，此检查由发送或接收队列执行。

o9-28：如果CA实现可靠的数据报或XRC服务，并且如果检测到无效的LID，则应静默丢弃数据包。对于RD服务，此检查由EE上下文执行。

主SLID和DLID存储在QP或EE上下文中。如果给定的通道适配器支持透明迁移，则备用SLID和DLID也作为备用路径的一部分存储在QP或EE上下文中。选择是否将入站SLID和DLID与主或备用LID进行比较，这取决于自动路径迁移状态机的当前状态和BTH中MigReq位的状态。

lid_check

<span>◼ </span>good：LRH中包含的SLID和DLID分别与QP或EE上下文中存储的SLID和DLID相匹配。

<span>◼ </span>bad：LRH中包含的SLID或DLID与QP或EE上下文中存储的SLID和DLID不匹配。

#### 9.6.1.6.2 IBA不可靠多播检查

C9-58：如果目的地QP是0xFFFFFF，则包被声明为IBA不可靠的多播数据包。要被认为是有效的，它必须具有以下三个特征：包必须包含一个GRH，DGID必须是有效的多播GID，并且必须至少有一个为多播操作配置的本地管理队列对。如果这些条件中的任何一个不成立，则该数据包不是有效的多播数据包，应静默地丢弃。

C9-59：应使用DGID将入站数据包映射到特定的本地管理QP。

multicast_check

<span>◼ </span>good：多播数据包满足上述所有有效多播数据包的标准。

<span>◼ </span>bad：多播数据包不符合上述所有有效多播数据包的标准。

# 9.7 可靠服务

可靠服务提供了一种保证，即消息从请求者传递到响应者的次数最多为一次，而且没有损坏。可靠服务的关键要素包括一个保护方案，以允许检测损坏的数据（CRC），一个允许请求者确定消息已成功传递的确认机制，一个用于检测丢失的包并允许请求者将响应与请求相关联的包编号机制，以及允许检测丢弃或丢失确认消息的计时器。

本节讨论确认和分组序列编号机制。这里不讨论检测数据包损坏的CRC机制。请注意，CRC在较低的协议层进行检查，可能导致在将数据包传送到传输层之前丢弃这些数据包。这些丢弃的包最终可能在传输层被检测为序列错误。

<span>◼ </span>可靠服务的特性

<span>   </span><span>✸ </span>在没有不可恢复的错误的情况下，消息最多可按顺序传递一次，且不会损坏。

<span>   </span><span>✸ </span>每一条消息都被明确或隐式地确认。

<span>◼ </span>可靠服务类型

<span>   </span><span>✸ </span>可靠连接

<span>   </span><span>✸ </span>可靠数据报

<span>   </span><span>✸ </span>扩展可靠连接

<span>◼ </span>可靠性机制

<span>   </span><span>✸ </span>ACK/NAK协议

<span>   </span><span>✸ </span>分组序列号（PSN）

<span>◼ </span>响应器在以下情况下认为操作完成：

<span>   </span><span>✸ </span>在BTH中接收到有效的“最后”或“唯一”操作码，

<span>   </span><span>✸ </span>以正确的PSN顺序接收到包含消息的所有数据包，

<span>   </span><span>✸ </span>有效载荷已提交至本地故障区（发送或RDMA写入），

<span>   </span><span>✸ </span>已将响应提交到用于RDMA读取或原子操作的线路（wire）上，

<span>   </span><span>✸ </span>请求的最后一个数据包的确认数据包已提交到线路（包括RDMA读取响应的相应字段）

<span>◼ </span>请求者认为操作在以下情况下完成：

<span>   </span><span>✸ </span>响应的所有数据包（用于RDMA读取或原子操作）已接收并提交到本地内存中，

<span>   </span><span>✸ </span>确认消息已接收并验证。

C9-60：在考虑WQE完成之前，请求者必须等待必要的响应到达。如果请求者需要一个明确的响应，以便能够完成给定的WQE，则请求者应负责采取必要的步骤，以确保所需的响应即将到来。

有几种机制可以实现这一点，例如：

1）在每个消息的最后一个包上设置AckReq位，从而保证响应者将生成所需的显式响应；

2）在需要显式响应的消息的最后一个包上设置AckReq位；

3）如果没有为需要显式响应的请求设置AckReq位，则请求者可以重试请求（设置AckReq），从而要求响应者返回响应，

4）如果没有为需要显式响应的请求设置AckReq位，请求者可以发送NOP命令（例如RDMA写入请求，长度为零），并设置AckReq位。此策略仅在响应程序支持RDMA写入时有效。

这些策略的实施取决于其他策略的使用。

## 9.7.1 分组序列号（PSN）

PSN在所有数据包的基本传输报头（BTH）中传输。它们用于检测丢失或无序的数据包，并且为了可靠的服务，将响应包与给定的请求包相关联。每个IBA QP由一个发送队列和一个接收队列组成；同样，EE上下文有一个发送端和一个接收端。请求者发送队列上的PSN与响应者相应接收队列上的PSN之间存在关系。因此，QP（或EE上下文）的每一半维护一个独立的PSN；在给定队列对的发送队列和接收队列上使用的PSN之间，或者在不同的连接之间没有关系。如下图所示。

有两种异常情况必须在接收端处检测并解决，以确保可靠运行。这两种情况是重复数据包和无效数据包。

1） 重复数据包。如果请求者多次将请求报文注入fabric，则响应者可以识别重复报文。当请求者检测到一个条件而使用指定的恢复机制重试该操作时，就会发生这种情况。

超时条件的两个主要原因可能会导致请求者将给定的请求包多次注入fabric中：

<span>◼ </span>响应延迟到达请求者，可能是因为响应包在fabric中丢失或延迟，如下图84所示，或者是因为响应程序在生成响应时遇到延迟，或者

<span>◼ </span>请求包可能丢失或延迟到达响应程序，如图86所示。

不管原因是什么，响应程序必须能够确定入站请求是否是以前执行过（或未执行）的重复请求，并做出适当的响应。

在前面的图中，响应在fabric中丢失或延迟，导致请求者检测到超时条件并重新传输请求。响应程序将请求包的第二次到达解释为重复请求。

由于“ghost”请求包，接收端也可以检测到重复包。当请求包在fabric中被延迟到足以导致请求者超时时，就会发生这种情况。请求者重新发送原始请求包，响应者向其生成正确的确认消息。稍后，原始（延迟）数据包到达响应器，响应器将延迟到达的数据包解释为重复请求。例如，在自动路径迁移过程中可能会发生这种情况。

2） 请求数据包序列无效。当响应程序认为一个或多个请求包已在fabric中丢失时，就会出现这种情况。如下图所示。

无效数据包和重复数据包之间的区别很重要，因为请求者的操作和响应者的操作在这两种情况下是不同的。

这两种情况必须由响应程序（对于请求数据包）或请求程序（对于可靠服务上的响应数据包）进行检测。

除了重复数据包和无效数据包外，还有第三种情况，称为Stale Packet/陈旧数据包（“时间等待数据包/TIME WAIT packet”）。如果与响应器的连接断开，并且在数据包正在传输时建立新的连接，则来自旧（过时）连接的数据包可能会到达响应器。反过来，响应程序可以将这个过时的传入数据包解释为有效的数据包，而实际上它是先前连接的残留包。没有传输层机制来防止这种情况；连接管理的责任是避免重复使用QPs，直到不可能有过时的数据包到达响应程序为止。这是通过将请求者和响应者QP置于“Time Wait”状态足够长的时间来实现的，以确保在重新使用QP之前fabric中遗留的任何过时数据包都已过期。

重复数据包与无效数据包通过基本传输报头中携带的24位PSN字段进行区分，并允许唯一命名多达16777216个数据包。

C9-61：为了使应答者能够区分重复包和乱序包，给定的发送队列在任何给定时间都应该有不大于8388608个的PSN。因此，在任何给定的时间，发送队列中未完成的数据包不得超过8,388,608个。这包括所有发送请求包加上所有RDMA写请求包加上所有原子操作请求包加上所有预期的RDMA读响应包的总和。

因此，PSN空间（由16777216个PSN组成）被分成两个区域，每个区域占据8388608个PSN的范围，称为有效区域和无效区域。如图87所示。

响应器将有效区域进一步细分为一个期望的PSN区域和一个重复区域。响应器的预期PSN（ePSN）在第9.7.4.1.2节“响应器-PSN验证”中定义，并简单描述为响应器期望在下一个要接收的新请求包中找到的PSN。因此，重复区域被定义为整个有效区域，除了单个预期的PSN。简单地说，一个重复的PSN是响应者先前看到并执行的PSN，它在有效区域内。

### 9.7.1.1 可靠服务的PSN模型

C9-62：对于使用可靠连接服务的HCA请求者，请求者应在其生成的每个请求的每个包中插入一个PSN。在响应请求时，响应器应在其生成的每个响应的每个包中插入一个PSN。

o9-29：如果TCA实现可靠的连接服务，或者如果CA请求者实现可靠的数据报或XRC服务，则请求者应在其生成的每个请求的每个包中插入一个PSN。在响应请求时，响应器应在其生成的每个响应的每个包中插入一个PSN。

除了RDMA读响应的特殊情况外，请求包中的PSN与相应响应包中的PSN之间存在1:1的关系。

在一般的PSN模型中，请求者计算要生成的下一个请求包的PSN。这个计算出的PSN称为下一个PSN。当请求者生成一个新的请求包时，“下一个PSN”被复制到BTH中，从而成为当前PSN。然后请求者计算一个新的“下一个PSN”。

为了检测丢失或无序的数据包，响应程序还计算它期望在下一个入站请求包中找到的PSN。这称为预期的PSN。

相反，在生成响应时，响应程序计算响应PSN，以将响应与给定请求关联起来。然而，由于如**第9.7.5.1.2节“合并确认消息”**所述的应答合并，请求者不一定能够预测PSN范围中的哪一个可能出现在下一个响应包中。因此，请求者必须准备好接受一系列响应PSN中的任何一个。范围由最早的未确认请求包的PSN和最近发送的请求包的预期响应PSN限定。请求者评估入站响应包的PSN，以确保它介于这两个极端之间。这个通用模型如下所示。

在以下几节中，从文本所指的四个PSN中的哪一个是不明显的。因此，通常的做法是指“PSN”或“预期PSN”或其他变体。在上下文不清楚的情况下，为清楚起见，使用上述表达式。

## 9.7.2 ACK/NAK协议

ACK/NAK协议与分组序列号一起，是可靠业务的基本组成部分，适用于可靠连接业务、XRC业务和可靠数据报业务。本节和以下章节描述协议，提供一组控制ACK和NAK响应生成的规则，指定ACK和NAK代码，并指定当请求者接收到ACK或NAK响应时所需的响应。

ACK/NAK协议的目的是允许请求者确定地确定响应者是否正确地接收到请求包。还提供了一些机制来确保正确接收完整的消息。这是通过分组序列号和分组操作码（第一/中间/最后/仅分组指示）的组合来实现的。

由于响应包可能在fabric中丢失，所以ACK/NAK协议要求请求者实现一个定时器来检测丢失的响应包。本节还介绍了传输计时器。

在本节中，“确认”一词始终用于表示否定（NAK）或肯定（ACK）确认。通用术语“响应”用于描述由响应者返回给请求者的确认。响应以一个或多个确认分组来承载，并且可以根据原始请求消息包括ACK分组、NAK分组、RDMA读取响应或原子操作响应。

以下是管理ACK/NAK协议的规则总结：

<span>◼ </span>应确认在可靠服务上收到的每个请求包。

<span>◼ </span>每个RDMA读取请求都需要显式响应。具有格式正确的ACK扩展传输头（AETH）的RDMA读取响应被视为有效响应。ACK扩展传输报头出现在RDMA读取响应的第一个数据包和最后一个数据包（或只有一个数据包）中。详细信息见下文**第9.7.5.1.9节“RDMA读取响应”**。

<span>◼ </span>每个原子请求都需要显式响应。具有正确格式的ACK扩展传输报头（AETH）和原子ACK扩展传输报头（AtomicAckETH）的应答包被认为是有效的响应。

<span>◼ </span>确认可能合并；也就是说，单个确认包可以作为一个或多个先前请求分组的确认。

<span>◼ </span>应答包应按接收原始请求包的PSN顺序返回，包括RDMA读取响应。

<span>◼ </span>RDMA读取响应由一个或多个数据包组成；所有其他响应仅由一个数据包组成。

C9-63：对于使用可靠连接服务的HCA响应器，该响应器的行为应如下所示。响应器应确认收到的每个请求包。响应程序应为收到的每个RDMA读取请求生成显式响应。响应器应为收到的每个原子请求生成一个明确的响应。响应器应按照接收原始请求包的PSN顺序生成响应包，包括RDMA读取响应。

o9-30：若TCA响应器实现可靠连接服务，或CA响应器实现可靠数据报或XRC服务，则响应器应如下所示。响应器应确认收到的每个请求包。响应程序应为收到的每个RDMA读取请求生成显式响应。响应器应为收到的每个原子请求生成一个明确的响应。响应器应按照接收原始请求包的PSN顺序生成响应包，包括RDMA读取响应。

## 9.7.3 请求者：生成请求包

本节指定在请求者生成请求包时对其提出的要求。

### 9.7.3.1 请求端—生成PSN

C9-64：对于HCA中的可靠连接服务，请求者必须在每个请求包的BTH:PSN字段中放置一个值，称为当前PSN。

o9-31：如果可靠数据报或XRC服务是在CA中实现的，或者如果可靠连接服务是在TCA中实现的，那么请求者必须在每个请求报文的BTH:PSN字段中放置一个值，称为当前PSN。

在建立连接期间，传输层的客户端将下一个PSN编程为0到16777215之间的任何值。为了正确操作，响应端的初始预期PSN值必须加载相同的值。

C9-65：对于HCA中的可靠连接服务，由传输层客户端编程的初始PSN是应出现在请求者生成的第一个请求包中的PSN。

o9-32：如果可靠的数据报服务或XRC服务在CA中实现，或者如果可靠连接服务在TCA中实现，则由传输层客户端编程的初始PSN是请求者生成的第一个请求包中出现的PSN。

此后，请求者计算下一个PSN。计算取决于正在执行的操作（SEND、RDMA READ等）和数据有效负载的大小。

除了一个例外，请求者应为其生成的每个请求包将当前的PSN值增加一个。唯一的例外是紧跟在RDMA读取请求消息之后的任何请求包。在这种情况下，紧跟在RDMA读取请求消息之后的请求数据包的PSN应大于最后预期的RDMA读取响应包的PSN。这样，请求者在请求包的PSN序列中留下一个“洞”，使得所有响应包将具有单调递增的PSN。

因此，对于RDMA读取请求：

让curr_PSN=RDMA读取请求的PSN

让next_PSN=RDMA读取请求之后的请求的PSN

让n=预期的RDMA读取响应数据包的数量

然后next_PSN=（curr_PSN+n）模2^24。

由于请求者既知道请求的RDMA读取数据的总长度，也知道请求者和响应者之间的PMTU，并且由于需要将每个响应包（除了最后一个或唯一的包）填充到完整的PMTU大小，所以请求者可以计算预期响应包的总数，从而计算出紧跟在RDMA读取请求之后的请求的PSN。

C9-66：对于使用可靠连接服务的HCA请求者，请求者的行为应如下所示。对于除了紧跟在RDMA读取请求消息之后的分组之外的每个请求分组，请求者应将下一个PSN值增加一个模2\^24。对于紧跟在RDMA读取请求消息之后的任何请求分组，该分组应具有比最后预期的RDMA读取响应分组的PSN大一个（模数2^24）。

o9-33：如果TCA请求方实现可靠连接服务，或者CA请求方实现可靠数据报服务或XRC服务，则请求方的行为应如下所示。对于除了紧跟在RDMA读取请求消息之后的分组之外的每个请求分组，请求者应将下一个PSN值增加一个模2\^24。对于紧跟在RDMA读取请求消息之后的任何请求分组，该分组应具有比最后预期的RDMA读取响应分组的PSN大一个（模数2^24）。

### 9.7.3.2 请求端—可靠数据报的特殊规则

#### 9.7.3.2.1 RDD检查

对于可靠的数据报服务，任何给定的发送队列都通过可靠数据报域（RDD, Reliable Datagram Domain）与EE上下文相关联。每个发送队列和EE上下文都有一个与之关联的RDD。在发送请求之前，EE上下文必须检查当前活动发送队列的RDD。如果发送队列的RDD与EE上下文的RDD不匹配，则终止当前消息传输，并向发送队列指示超时条件。

o9-34：对于每个请求，请求者必须确认当前活动发送队列的RDD与所选EE上下文的RDD匹配。

o9-35：本合规声明已过时，已被删除。

RDD不匹配的错误行为定义在表59“请求者侧错误行为”.

#### 9.7.3.2.2 重新同步/RESYNC生成

在某些情况下，请求者的EE上下文需要生成一种称为重新同步RESYNC请求的特殊形式的请求包。当请求者EE上下文选择中止（中止）当前请求消息时，会发生这种情况。中止当前请求消息并生成后续重新同步请求的过程在处理QP错误的第9.7.8节“可靠数据报”中描述。

RESYNC请求具有一个特殊属性，它强制响应程序将其预期的PSN重新初始化为请求方EE上下文定义的值。

以下段落控制请求者在中止当前消息并生成重新同步请求时必须使用的PSN。它还控制在响应重新同步请求的确认中应该期望的PSN。这些PSN在图88“请求/响应”PSN中标识为下一个PSN和响应PSN。

o9-35.a1：对于支持可靠数据报服务的CA，在中止当前请求消息并生成重新同步请求时，请求方EE上下文应将重新同步请求的PSN设置为比发送当前请求时使用的最大PSN（模2^24）大一个增量（模2^24）。此外，请求者应将其期望的PSN重置为相同的值。“用于传输当前请求的最大PSN”是指：

1）分配给请求消息的任何包（包括请求消息的任何重试）的（逻辑上）最大的PSN（模数2^24），或者

2）如果请求是RDMA读取请求，则最后一个预期的RDMA读取响应的PSN。

例如，如果当前正在传输的请求由PSN编号为4、5和6的三个分组组成，则重新同步请求的PSN将被设置为7。

或者，考虑请求者发送由许多包组成的较大请求消息的情况。即使响应器在传输的早期返回NAK，但是请求者已经发送了随后的包，则重新同步请求的PSN必须比发送的任何请求包的PSN大一个（模数2^24），而不管NAK包是何时生成的还是它的PSN。

在另一示例中，如果当前正在发送的请求是PSN为24的RDMA读取请求，并且请求者期望接收5个响应包，则重新同步请求的PSN将被设置为29，这比最后一个期望的RDMA读取响应包的PSN大一个。

如果请求者由于超时或其他原因执行一次或多次重试，则对于所有先前的尝试，重新同步请求的PSN必须比发送的任何请求包或预期的响应包的PSN大一个（模2^24）。

o9-35.a2：对于支持可靠数据报服务的CA，请求者应在重新同步请求中插入与当前请求（正在中止）中的源和目标QPs相同的源和目标QPN。

### 9.7.3.3 请求者—生成操作码OpCodes

请求者生成的操作码必须符合如下所示的操作码表。

C9-67：请求者必须生成符合有效操作码序列表的分组操作码，如表43有效操作码序列一览表所示。

C9-68：生成请求包时BTH:Opcode应该如表38操作码字段所示。

### 9.7.3.4 请求者—生成有效载荷

请求者应根据操作码生成有效载荷长度，如下所示：

C9-69：如果操作码指定“第一”或“中间”数据包，则数据包有效负载长度必须是完整的PMTU大小。

C9-70：如果操作码指定一个“only”包，那么包有效负载长度的大小必须介于0和PMTU字节之间。因此，创建零字节长度传输的唯一方法是使用单个分组消息。

C9-71：如果操作码指定了“最后一个”包，那么包有效负载长度的大小必须介于1和PMTU字节之间。

C9-72：对于HCA，如果操作码指定RDMA写入请求，则RETH的DMALen字段中指定的长度应不小于零，且不大于2^31字节。

o9-36：如果在TCA中实现RDMA写入，并且操作码指定RDMA写入请求，则RETH的DMALen字段中指定的长度应不小于零，且不大于2^31字节。

## 9.7.4 响应器：接收入站请求包

本节描述响应程序在接收入站请求包时使用的过程。

### 9.7.4.1 响应器-入站数据包验证

C9-73：对于HCA中的可靠连接服务，入站请求包应按图89所示进行验证。

o9-36.a1：如果可靠连接服务或XRC在TCA中实现，入站请求包应如图89所示进行验证。

o9-37：如果在CA中实现可靠的数据报服务或XRC服务，则入站请求包应按图90所示进行验证。

以下部分描述了每个验证检查和响应程序的行为/响应。

#### 9.7.4.1.1 响应器-可靠数据报检查的特殊规则

o9-38：对于HCA中的RD，当入站数据包到达时，接收队列必须根据入站数据包到达的EE上下文的RDD值测试自己的RDD值。如果它们不匹配，接收队列必须丢弃数据包并调度一个NAK无效的RD请求。用于返回NAK的P_Key和PSN应由EE上下文提供。

对于可靠的数据报服务，PSN由响应者的EE上下文检查。

在很大程度上，响应者响应请求的行为是基于对传入PSN的解释。

逻辑上，接收队列或EE上下文维护一个预期的PSN（ePSN）。这是响应器期望在它接收到的下一个新请求包的BTH中找到的PSN。响应程序用于计算其下一个预期PSN的规则与请求程序在计算要插入到下一个请求包中的PSN值时使用的规则相同。

注：参见**第9.9.3节“响应器端行”**为，了解图89入站请求包验证、RC模式和图90入站请求包验证RD模式中引用的每个错误条件的响应程序端行为描述。

o9-38.a1：如果在CA中实现可靠的数据报服务，当入站数据包到达时，响应器应执行以下操作：

1） 如果响应器接收到操作码为“middle”或“last”的新请求包（即PSN=期望的PSN）（即，响应器先前已接收到操作码为“first”的新请求包，而尚未接收到操作码为“last”的新请求包，响应器应验证新请求包中包含的源和目的QPN与最近接收到的“第一”包的QPN完全匹配。如果新的“中间”或“最后”请求包的源和目标QPN与最近接收到的“第一”请求的QPN不匹配，则响应器应忽略该分组。

2） 如果响应器接收到重复的请求包（即PSN在重复区域中），则响应器应验证重复请求包中的源QPN和目的QPN是否与最近接收到的新请求的QPN完全匹配。如果源QPN和目的QPN与最近接收到的新请求的QPN不匹配，响应器将忽略该分组。

o9-38.a2：如果在CA中实现可靠的数据报服务，当入站重新同步请求到达时，响应方应执行以下操作：

1） 如果响应器接收到重新同步请求，则不管重新同步请求中的源和目标QPN的值如何，它都应接受该请求。

2） 如果响应器接收到一个重新同步请求，它将接受该请求，而不管当前执行的请求（即最近接收到的新请求）的操作码序列（“第一个”、“中间”等）的状态如何。

3） 如果重新同步请求的PSN等于或逻辑上大于响应方的预期PSN（即，重新同步请求是一个新请求），则响应方应：

a）将其期望的PSN设置为重新同步请求的PSN加1（模数2^24），

b）使用重新同步请求的PSN作为响应的PSN，

c）如果当前执行的请求不完整（即操作码为“last”或“only”的请求包尚未完成，则中止与当前执行的请求相关的任何处理到达）。如果当前正在执行的请求是带有Immediate的SEND RDMA WRITE（因此会消耗一个receive WQE），则部分使用的receive WQE将错误地完成。

4） 如果重新同步请求的PSN逻辑上小于响应方的预期PSN，则响应方应将重新同步请求视为重复请求，因此不应更改其预期PSN。响应方应使用重复的重新同步请求的PSN作为响应的PSN。

#### 9.7.4.1.2 响应器-PSN验证

C9-74：对于HCA响应程序中的可靠连接服务，在执行入站请求之前，响应程序应通过比较入站请求来检查PSNBTH:PSN到响应者的预期PSN。PSN应通过响应器的接收队列进行检查。

o9-39：如果在CA中实现了可靠的数据报服务或XRC服务，或者如果在TCA中实现了可靠的连接服务，并且在执行入站请求之前，响应者应通过比较入站请求来检查PSNBTH:PSN到响应者的预期PSN。PSN应通过响应器的接收队列进行检查。

对于可靠的数据报服务，PSN由响应者的EE上下文检查。

在很大程度上，响应者响应请求的行为是基于对传入PSN的解释。

C9-75：对于HCA响应程序中的可靠连接服务，响应程序应使用**第9.7.3.1节“请求端—生成PSN”**中给出的规则来计算其预期PSN。

o9-40：如果可靠数据报服务或XRC在CA中实现，或者如果可靠连接服务在TCA中实现，响应器应使用**第9.7.3.1节“请求端—生成PSN”**中给出的规则来计算其预期PSN。

在建立连接时，通信管理器(Communication Manager)将响应程序的预期PSN初始化为0到16777215之间的任何值。为了正确操作，此初始值必须与加载到请求程序上的初始下一个PSN值匹配。

只有当队列处于初始化状态时，客户端才能设置初始预期PSN。传输层可能会忽略客户端在PSN处于任何其他状态时设置PSN的尝试。

C9-76：对于HCA响应器中的可靠连接服务，HCA应仅在接收队列处于适当条件以接收请求包的状态时更新其预期PSN。例如，当队列对处于初始化状态时，传输不会修改预期的PSN。

o9-41：如果可靠连接服务在TCA中实现，或XRC服务在CA中实现，则只有当接收队列处于适当状态以接收请求包时，响应器才应更新其预期PSN。例如，当队列对处于初始化状态时，传输不会修改预期的PSN。

o9-42：如果在CA中实现可靠的数据报服务或XRC服务，则只有在EE上下文处于适当条件接收请求包的状态时，响应方才应更新其预期的PSN。

与预期的PSN相比，入站请求消息的实际PSN可能属于三个区域中的一个；它可能完全等于响应者的预期PSN，它可能逻辑上“小于”响应者的预期PSN，从而落入重复区域，如图87所示，或者，它可能同时落在有效区域和预期PSN区域之外，因此是无效的。

预期（新）请求：接收到的入站请求包与响应程序的预期PSN完全匹配，这是一个新的请求包。

C9-77：对于HCA响应器中的可靠连接服务，新的请求包应正常验证，并根据执行顺序规则执行。一旦请求被执行，应按照第9.7.5节“响应者：生成响应”中的规定安排响应。

o9-43：如果在CA中实现了可靠的数据报服务或XRC，或者如果在TCA中实现了可靠的连接服务，则新的请求包应正常验证，并根据执行顺序规则执行。一旦请求被执行，应按照第9.7.5节“响应者：生成响应”中的规定安排响应。

注意，不需要为每个入站请求包返回离散的应答包。

一旦接收到具有有效期望PSN的分组，响应器通过计算新的期望PSN来提高其期望PSN，并向上滑动有效区域窗口以反映有效PSN的新范围。

有效的重复请求：在有效区域内但不是预期的PSN的PSN是有效的重复请求包。

C9-78：对于HCA响应程序中的可靠连接服务，响应程序应响应**第9.7.5.1.4节“确认重复请求”**中规定的有效重复请求。

o9-44：如果可靠数据报服务或XRC服务在CA中实现，或者如果可靠连接服务在TCA中实现，则响应器应响应**第9.7.5.1.4节“确认重复请求”**中规定的有效重复请求。

表44总结了这些行动。

无效请求：实际接收到的PSN超出有效区域而不在预期区域（期望区域）的数据包是无效的请求。无效的PSN值通常表示结构中丢失了一个或多个请求包。

响应程序响应无效请求包的详细行为如下：

<span>◼ </span>错误请求报文没有被执行。

<span>◼ </span>在错误请求之前接收到的任何请求包必须在发出NAK序列错误之前执行和完成，因为它充当了先前未处理的发送或RDMA写入请求的隐式ACK，并且作为未完成RDMA读取或原子操作请求的隐式NAK。

<span>◼ </span>向请求者返回NAK序列错误（NAK-Sequence error）。

<span>◼ </span>响应方不更新其预期PSN。

C9-79：对于HCA响应器中的可靠连接服务，当入站请求消息的实际PSN超出有效区域（无效请求）时，响应方应返回NAK序列错误。在错误请求之前接收到的任何请求包必须在发出NAK序列错误之前执行并完成。

o9-45：如果在CA中实现了可靠的数据报服务或XRC服务，或者在TCA中实现了可靠的连接服务，并且如果入站请求消息的实际PSN超出有效区域（无效请求），则响应方应返回NAK序列错误。在错误请求之前接收到的任何请求包必须在发出NAK序列错误之前执行并完成。

响应程序将继续等待有效的入站请求包，该数据包的PSN等于其预期PSN或其有效区域内。如果在等待有效的新请求时，响应程序接收到任何后续无效的请求包，则这些数据包将被默默地丢弃；不会返回NAK。

C9-80：对于HCA响应器中的可靠连接服务，在生成NAK序列错误后，响应方在收到有效的新请求或有效的重复请求之前，不得生成ACK或NAK。

o9-46：如果在CA中实现了可靠的数据报服务或XRC服务，或者如果在TCA中实现了可靠的连接服务，则在生成NAK序列错误后，响应方在收到有效的新请求或有效的重复请求之前，不得生成ACK或NAK。

对于已连接的传输服务，不要求停止队列，也不要求断开连接。

#### 9.7.4.1.3 响应者—操作码顺序检查

请求包必须符合有效操作码序列（OpCode sequence）的调度。对于可靠连接、XRC和可靠的数据报服务，响应方应检查包含请求消息的分组操作码序列，如下所示：

1） 如果这是建立连接后的第一个分组，那么分组操作码必须指示“first”或“only”。

2） 如果接收到的最后一个有效数据包具有一个操作码，指示“first”，则当前操作码必须指示“middle”或“last”。它还必须与上次有效数据包中指定的操作类型匹配（Send、RDMA、原子操作）。如果当前操作码指示“first”或“only”，则会出现错误，因为这意味着上一条消息的最后一个包丢失。

3） 如果接收到的最后一个有效数据包具有指示“middle”的操作码，则当前操作码必须指示“middle”或“last”。它还必须与上次有效数据包中指定的操作类型匹配（Send、RDMA、原子操作）。如果当前操作码指示“first”或“only”数据包，则会出现错误，因为这意味着上一条消息的最后一个数据包丢失。

4） 如果接收到的最后一个有效数据包具有一个指示“last”的操作码，则当前操作码必须指示“first”或“only”。如果当前操作码指示“middle”或“last”，则会出现错误，因为这意味着消息的第一个包丢失。

5） 如果接收到的最后一个有效数据包具有一个操作码，指示“only”，则当前操作码必须指示“first”或“only”。如果当前操作码指示中间包或最后一个包，则会出现错误，因为这意味着消息的第一个包丢失。

下表简洁地说明了这些规则。

C9-81：对于使用可靠连接服务的HCA响应程序，响应方应检查包含请求消息的分组操作码序列是否符合表45: 有效操作码序列所示的规则。如果响应程序检测到无效的操作码序列，则应向请求者返回NAK无效请求。

o9-47：如果TCA响应器实现可靠连接业务，或CA响应器实现XRC业务，响应器应检查包括请求报文的分组操作码序列是否符合表45有效操作码序列一览表所示的规则表。如果响应器检测到无效的操作码序列，它将向请求者返回一个NAK无效请求。

o9-48：如果CA响应器实现可靠的数据报服务，响应器应检查包括请求消息的分组操作码序列是否符合表45有效操作码序列一览表所示的规则表。如果响应器检测到无效的操作码序列，它将向请求者返回一个NAK无效请求。

存在无效操作码序列时的详细行为在**第9.9节“错误检测和处理”**中有详细说明。

o9-49：本合规声明已过时，已被删除。

#### 9.7.4.1.4 响应器操作码验证

C9-82：在执行入站请求之前，响应器应验证BTH的操作码字段。

检查操作码是否具有以下特征：

<span>◼ </span>此接收队列支持所请求的功能（Send、RDMA、ATOMIC）；

<span>◼ </span>如果请求是针对RDMA读取或原子操作，则应该足够的资源来接收它。

当包被传递到传输层时，BTH操作码字段[7:5]被检查以确保请求的操作是为了一个可靠的服务。如果不是的话，那数据包就被悄悄地扔了。该检查在第9.6节“数据包传输头验证”中指定。因此，在分组到达队列对以根据本节中的规则进行验证之前，已经知道它是对可靠服务的请求。

C9-83：对于HCA响应程序中的可靠连接服务，如果请求是针对该接收队列不支持的功能，则应返回一个NAK无效请求。

例如，如果队列对未配置为接受RDMA请求，但请求是RDMA写入请求，则应返回NAK Invalid请求。

o9-50：如果可靠数据报服务或XRC服务在CA中实现，或者如果可靠连接服务在TCA中实现，如果请求是针对该接收队列不支持的功能，则应返回NAK无效请求。

C9-84：对于HCA响应器中的可靠连接服务，并且BTH操作码字段[4:0]却指定了可靠连接保留操作码或可靠数据报保留操作码，则返回NAK无效请求。

o9-51：如果在CA中实现可靠的数据报服务或XRC服务，或者如果在TCA中实现可靠连接服务，并且BTH操作码字段[4:0]却指定了可靠连接保留操作码或可靠数据报保留操作码或XRC保留操作码，则返回NAK无效请求。

C9-85：对于HCA响应器中的可靠连接服务，如果BTH操作码字段[4:0]指定了第一个或中间请求包（例如，先发送或RDMA写入中间），则应验证填充计数位为b00，表示不存在pad字节。如果填充计数位不为零，则应返回NAK无效请求。

o9-52：如果在CA中实现了可靠的数据报服务或XRC服务，或者如果在TCA中实现了可靠的连接服务，如果BTH操作码字段[4:0]指定了第一个或中间的请求包（例如，SEND First，或RDMA写入中间），则应验证pad count位为b00，表示不存在pad字节。如果填充计数位不为零，则应返回NAK无效请求。

C9-86：对于HCA响应程序中的可靠连接服务，如果没有足够的资源来接收新的RDMA读取或原子操作请求，则应返回NAK无效请求。

o9-53：如果可靠的数据报服务或XRC服务在CA中实现，或者如果可靠连接服务在TCA中实现，并且如果没有足够的资源来接收新的RDMA读取或原子操作请求，则应返回NAK无效请求。

返回NAK Invalid请求的行为如下：

<span>◼ </span>错误请求包未被执行。

<span>◼ </span>在错误请求之前收到的任何请求包必须在发出NAK无效请求之前执行和完成。这一点很重要，因为NAK有效地合并了对先前未完成请求的响应，并充当了先前未完成的发送、RDMA写入、原子操作或RDMA读取请求的隐式响应（确认）。详见**第9.7.5.1.2节“合并确认信息”**。

<span>◼ </span>返回NAK Invalid请求。

<span>◼ </span>响应器不更新其预期PSN。

C9-87：对于HCA响应器中的可靠连接服务，在响应器发出NAK无效请求之前，必须执行并完成在包含无效操作码的分组之前接收到的任何请求包。

o9-54：如果可靠的数据报服务或XRC服务在CA中实现，或者如果可靠连接服务在TCA中实现，那么在包含无效操作码的数据包之前接收到的任何请求包必须在响应器发出NAK无效请求之前执行并完成。

第9.9.3节“响应端行为”中提供了有关无效请求时错误行为的更多详细信息。

#### 9.7.4.1.5 响应器—R_KEY验证

R_Key违规是由RDMA READ、RDMA WRITE或ATOMIC操作的以下任一或全部条件导致：

<span>◼ </span>RETH的R_Key字段无效（对于RDMA读或写）

<span>◼ </span>AtomicETH的R_Key字段无效（对于原子操作）。

<span>◼ </span>虚拟地址和长度，或指定的访问类型，超出了与R_Key相关的本地定义限制。对于RDMA写入请求，长度检查是基于每个数据包执行的，并且基于LRH:PktLen字段。对于RDMA读取请求，长度检查基于RETH:DMA长度字段。

<span>◼ </span>对于HCA，R_Key违规还包括违反**第10.2.3节“保护域”**中定义的保护域。

C9-88：对于使用可靠连接服务的HCA响应程序，对于每个零长度RDMA读或写请求，即使请求包含立即数据，也不应验证R_Key。

o9-55：如果HCA响应器实现可靠的数据报或XRC服务，或者如果TCA响应器实现可靠连接XRC和RDMA功能，则响应器的行为应如下所示。对于每个零长度RDMA读或写请求，即使请求包含立即数据，也不应验证R_Key。

C9-89：如果响应方的接收队列检测到R_Key违规，则应使用错误请求包的PSN向请求方返回NAK远程访问错误。

C9-90：在包含R_Key违规的包之前接收到的任何请求包都应在响应器发出NAK远程访问错误之前执行和完成。

有关更多详细信息，请参阅**第9.7.5.2.4节“远程访问错误”**。

#### 9.7.4.1.6 响应器-长度验证

C9-91：应检查LRH的PktLen字段，以确认接收WQE指定的接收缓冲区中有足够的可用空间。如果接收WQE定义的缓冲区不足以容纳入站的发送请求，则应返回NAK无效请求。

C9-92：还应通过将数据包与操作码进行比较来验证数据包的长度，如下所示：

<span>◼ </span>如果操作码指定“第一”或“中间”数据包，则数据包有效负载长度必须为完整的PMTU大小。

<span>◼ </span>如果操作码指定了“only”包，那么包有效负载长度的大小必须介于0和PMTU字节之间。因此，创建零字节长度传输的唯一方法是使用单个分组消息。

<span>◼ </span>如果操作码指定了“最后一个”数据包，则数据包有效负载长度的大小必须介于1到PMTU字节之间。

C9-93：如果检测到长度无效的数据包，则该请求应为无效请求。

在这种情况下，响应器的行为在**第9.9.3节“响应器端行为”**中有详细说明。

除了检查LRH:PktLen现场，按如下方式检查RETH的DMA Length字段。

对于RDMA写入请求，响应器可以选择性地检查RETH中的DMA Length字段，以确保它不指定大于2^31字节的传输长度。它还可以在传输结束时验证分组有效载荷的总和等于RETH中的DMALen字段。如果响应程序检测到这些情况之一，它可能会将请求视为无效请求。

C9-94：对于验证入站RDMA读取请求的HCA，应检查DMA长度字段。如果请求大于2^31字节，则应返回NAK无效请求。

o9-56：如果TCA执行RDMA操作，则对于入站RDMA读取请求，应检查DMA长度字段。如果请求大于2^31字节，则应返回NAK无效请求。

#### 9.7.4.1.7 响应器本地操作验证

有效的入站请求可能仍然无法完成，原因是响应程序出现了本地故障，例如访问本地内存时发生本地内存转换错误。所有本地响应程序错误都作为NAK远程操作错误报告给请求程序。更多详情见**第9.7.5.2.6“远程操作错误”**。

## 9.7.5 响应器：生成响应

### 9.7.5.1 响应方行为

此部分指定响应程序在生成确认消息时必须遵循的必需行为。

#### 9.7.5.1.1 为确认消息生成PSN

当响应器对每个请求生成响应时，它应通过在响应的BTH中插入PSN来标识与响应相关的请求。

这允许请求者将它接收到的响应包与其请求相关联。这一基本概念如下图91所示。

C9-95：对于发送请求或RDMA写入请求的响应，响应者应在响应的PSN字段中插入正在确认的最新请求包的PSN。

在这里和整个第9章中使用的“最近请求的PSN”具体指最近接收到的新请求包的PSN。（这与最近收到的重复请求的PSN不同）。因此，最近接收到的请求的PSN标志着最大向前进展的点，正如响应者所感知的那样，同时忽略重复的请求。

由于合并确认的规则（在第9.7.5.1.2节中给出），连续响应包的PSN不一定是连续的。

C9-96：对于对RDMA读取请求的HCA响应，响应包的PSN必须从原始RDMA读取请求消息的PSN开始按顺序单调递增。

o9-57：如果TCA实现RDMA读取功能，则对于每个RDMA读取响应，响应包的PSN必须从原始RDMA读取请求消息的PSN开始按顺序单调递增。

o9-58:由于原子操作请求需要显式响应，并且由于原子操作请求仅限于单个数据包，因此响应包的PSN必须与请求的PSN相同。

#### 9.7.5.1.2 合并确认消息

不要求每个请求包都有唯一的、独立的响应。相反，响应器可以用一个确认包来确认几个未完成的请求分组。这称为确认合并（coalescing）。

给定的响应包确认先前未完成的请求（即具有比响应包BTH中包含的PSN更早的PSN的那些请求），如下所示：

1） （从请求者的角度来看）如果有一个未完成的RDMA READ或ATOMIC操作请求，其PSN早于响该应包的BTH中的PSN，则响应包意味着对最早的此类未完成的RDMA READ或ATOMIC操作请求的否定确认（NAK）。在这种RDMA读取或原子操作请求之后，任何发送到发送队列的请求都不会被确认。这在图92“请求者对合并确认的解释”中进行了说明。

2）它意味着对所有未完成的SEND或RDMA WRITE请求包，亦即对PSN早于响应包的BTH中的PSN的确认。除非此类未完成的SEND或RDMA WRITE请求位于上述未完成的RDMA READ或ATOMIC Operation请求之后。

3） 如果给定的响应是RDMA READ response消息，则它是RDMA READ response消息的第一个（或唯一一个）数据包，它隐式地确认先前未完成的请求。

4） RDMA读取响应消息的最后一个（或唯一一个）数据包只显式地确认RDMA读取请求。

这些规则如图93所示。

#### 9.7.5.1.3 确认RDMA读取请求

RDMA读取响应与普通响应的不同之处在于它包含一个数据负载。

每个RDMA读取请求消息都需要一个分别（discrete）的确认，称为RDMA读取响应，它由一个或多个包组成。

C9-97：对于HCA，如果RDMA读取响应包含多个数据包，则第一个和最后一个数据包必须包含AETH。

o9-59：在实现RDMA的TCA中，如果RDMA读取响应包含多个数据包，则第一个和最后一个数据包必须包含AETH。

如**第9.7.5.1.2节“合并确认消息”**中所述，第一个包中的AETH隐式地确认先前未完成的请求。最后一个包中的AETH确认RDMA读取请求。

C9-98：对于HCA，如果RDMA读取响应本身是一个包，那么该包必须包含AETH。

o9-60：如果TCA实现RDMA功能，并且RDMA读取响应本身是单个数据包，则该数据包必须包含AETH。

包含在单个数据包RDMA读取响应中的AETH既可以隐式确认先前未完成的请求，也可以显式地确认RDMA读取请求本身。

C9-99：HCA响应器应生成的RDMA读响应包有效载荷长度，其应与操作码一致，如下所示：

1）操作码为“RDMA READ response only”的数据包的长度应为零到（PMTU）字节。

2）操作码为“RDMA READ Response First”或“RDMA READ Response Middle”的数据包长度应恰好为（PMTU）字节。

3）操作码为“RDMA READ response last”的数据包的长度应为1到（PMTU）字节。

4）允许零长度RDMA读取请求。

5）对零长度RDMA读取请求的响应应包含一个操作码为“RDMA READ response only”的单个数据包。

o9-61：如果一个TCA实现RDMA功能，它应生成有效负载长度如先前的符合性声明所述的响应包。

C9-100：如果HCA响应程序在返回多包RDMA读取响应的过程中检测到错误，它应通过不发送任何错误的有效载荷数据并强制将发生错误的数据包的操作码强制为“确认”而不是“RDMA读取响应最后一次”的操作码，强制RDMA读取响应提前终止。插入适当的NAK代码。

o9-62：如果TCA实现RDMA功能，并且在返回多包RDMA读取响应的过程中检测到错误，则TCA应通过不发送任何错误的有效负载数据并强制错误发生的数据包的操作码“确认”而不是“确认”来强制RDMA读取响应的提前终止“RDMA READ response last”的操作码。插入适当的NAK代码。

由于RDMA读取请求的排序规则比较宽松，因此允许响应程序开始执行在RDMA读取请求之后到达的一个或多个发送或RDMA写入请求。

C9-101：对于HCA，在执行RDMA READ请求之后的任何请求之前，必须对RDMA READ请求的头域进行校验。在发送未完成的RDMA READ响应之前，不能确认这些请求。

o9-63：在执行RDMA读取请求之后的任何请求之前，必须验证RDMA读取请求的头字段进行验证。在发送未完成的RDMA读取响应之前，不得确认这些请求。

#### 9.7.5.1.4 确认重复请求

验证重复请求后，对重复请求包的响应如下：

C9-102：在验证重复请求后，如果重复数据包有效，响应器应生成响应。

C9-103：在重复请求的整个处理过程中，响应器不应更新其预期的PSN；它保持设置为重复请求到达之前的值。即使响应程序在生成对重复请求的响应的过程中检测到错误，也是如此。

在生成适当的响应（如下段所述）之后，响应程序继续等待一个新的入站数据包，其中PSN与其预期的PSN相匹配。

在等待新的入站数据包时，响应程序可能会收到另一个重复请求。这是完全有效的，应该被视为另一个重复请求。此外，由于它是一个重复请求，因此不要求接收到的下一个请求与第一个重复请求按顺序的PSN顺序。但是，响应程序需要维护与普通新请求相同的排序规则，以生成对重复请求的响应。

C9-104：特别是，在为随后的重复发送或RDMA写入请求返回确认之前，必须使用显式响应来确认重复的RDMA读取或原子操作请求。

这在图94维护对重复请求的响应顺序中进行了说明。

要生成的响应是重复请求消息的一个功能，如下所示：

<span>◼ </span>发送、重新同步或RDMA写入请求

C9-105：对于接收到重复入站的SEND或RDMA Write请求的HCA，或接收到重复入站SEND请求的TCA，响应程序不应重新执行该请求，而只为重复数据包生成一个响应包，挂起任何未完成的重复RDMA读取请求或原子操作请求的响应。

o9-64：如果TCA响应程序实现RDMA功能，它将不重新执行RDMA写入请求，而只为重复数据包生成一个响应包，挂起任何未完成的重复RDMA读取请求或原子操作请求的响应。

确认消息的PSN必须是最近完成的新请求的PSN。把这个过程看作是合并确认能力的逻辑延伸。事实上，请求者在接收到对重复请求的响应时，会像对待任何其他联合确认一样对待它；任何未处理的重复RDMA读取或原子操作请求都被认为是NAK'ed。在这种情况下，通过返回最近完成的请求的PSN，响应程序通知请求者它认为它已经看到并执行了重复请求和最近完成的请求之间的所有请求。如图95所示。

C9-106：对于重复发送、重新同步或RDMA写入请求，如果响应程序在返回响应的过程中检测到错误，则应静默放弃重复请求。这样做是为了避免与新请求的任何未完成的NAK混淆。

<span>◼ </span>RDMA读取请求

C9-107：HCA响应程序必须重新创建请求的读取响应数据。准备好的读取数据在RDMA读取响应中返回给请求者。第一个RDMA读取响应包的PSN应与重复请求的PSN相同，后续响应包的PSN根据RDMA读取的PSN的正常生成规则递增。

C9-108：如果HCA响应程序在返回第一个响应包之前重新执行重复的RDMA读取请求时检测到错误，则该响应程序应静默放弃该重复请求。

C9-109：如果HCA响应程序在返回一个或多个响应包后重新执行重复的RDMA读取请求时检测到错误，则应中止RDMA读取响应操作，即不再返回响应包。

（发起方）当生成RDMA读取请求时，根据RDMA读取响应中预期的数据包数量分配一定数量的顺序PSN编号。这些PSN由响应程序在生成RDMA读取响应包时使用。此外，原始请求包含RETH中定义的DMA长度，该长度表示所请求的数据的范围。

如**第9.4.4节“RDMA读取操作”**所述，要被视为重复RDMA读取请求，重复请求的PSN必须在响应程序当前的重复PSN区域内。此外，要被视为有效的重复RDMA读取请求，重复请求的PSN必须在分配给原始RDMA读取响应的PSN的范围内，并且重复请求中请求的数据量必须完全包含在原始RDMA读取请求中请求的数据范围内。换句话说，在重复RDMA读取请求中请求的数据必须是原始RDMA读取请求中请求的数据的适当子集。

如果重复RDMA读取请求的起始PSN和长度不在分配给原始RDMA读取响应的PSN范围内，则请求无效，响应程序可能会静默放弃重复的RDMA读取请求。

C9-110：响应器应按PSN顺序响应所有重复请求；即（逻辑上）最早PSN的请求应首先执行。如果在响应新的或重复的请求时，使用逻辑上较早的PSN接收到重复请求，则响应器应停止对原始请求的响应，并开始使用逻辑上较早的PSN响应重复请求。

如果响应程序被重复请求中断，则不需要恢复中断的请求。请求者有责任重新发送任何未确认的请求。

o9-65：如果TCA实现RDMA功能，RDMA读取响应应符合前4个HCA符合性声明。

在重复的RDMA读取响应之后，响应者可以使用最近完成的请求的PSN来确认任何后续的重复SEND或RDMA写入请求。如图96所示。

<span>◼ </span>原子操作请求

给定的接收队列可能具有仅支持有限数量的原子操作的资源。当收到重复的原子操作请求时，将重复请求的PSN与最近执行的原子操作的PSN进行比较。

o9-66：如果重复原子操作请求的PSN与最近执行的某个原子操作的PSN完全匹配，则该操作的保存结果应返回给请求者。响应方不得重新执行请求。

o9-67：如果重复原子操作请求的PSN与最近执行的某个原子操作的PSN不匹配，则该请求无效，重复请求包应静默丢弃。只要请求者遵守未完成的原子操作请求的数量限制，就不应该发生这种情况。

o9-68：如果本地错误阻止响应程序复制原始的原子操作请求数据，则响应程序必须静默地放弃重复请求。

在所有情况下，应答消息中返回的PSN都是重复请求的PSN。

#### 9.7.5.1.5 生成NAK

有几种情况会导致响应程序生成NAK。

C9-111：除RDMA读请求外，在所有情况下，NAK包的PSN应包含响应者的预期PSN。

C9-112：在RDMA读响应包的情况下，NAK响应包中给出的PSN应指向正在NAK的RDMA读响应包。

C9-113：生成RNR NAK时，响应包的PSN应指向被RNR NAK的包的PSN。

C9-113.a1：生成NAK时，包含NAK码的包应具有应答操作码。

这意味着，即使对于RDMA读取响应，如果响应程序正在返回NAK代码，它也会通过用Acknowledge操作码代替RDMA Read response的正常操作码（first/middle/last/only）来替换数据包。

一旦响应程序返回NAK序列错误或RNR NAK，它将等待请求程序发送包含响应程序预期PSN的数据包。

响应者必须遵守的规则如下：

C9-114：一旦针对PSN序列错误返回NAK，响应程序应忽略所有其他新请求，重复请求除外，直到它收到一个PSN与预期PSN匹配的有效请求。它不应返回任何其他NAK包，除非响应一个有效的请求，其PSN与预期的PSN相匹配。

C9-115：响应程序必须继续响应上面指定的重复请求。但是，响应程序不应返回NAK以响应在处理重复请求时发生的错误情况。

#### 9.7.5.1.6 确认消息调度

响应的调度本身没有被指定；但是请求者可以使用BTH中的AckReq位来要求响应者调度响应。

C9-116：当响应器接收到设置了AckReq位的有效请求包时，它应为该请求调度一个响应包。响应的PSN必须等于或逻辑上大于（模数2^24）请求的PSN。

在接收到设置了AckReq位的请求消息之后，响应器在准备发送响应包时仍然接受请求消息（包括用AckReq位集标记的附加消息）。当响应者能够发送响应时，这些额外的请求消息可能会导致合并的ACK。在这种情况下，单个响应消息可以满足多个未完成的请求消息。

当一个或多个请求在没有设置AckReq位的情况下到达时，响应程序可以选择有意地合并其响应；它甚至可以等待无限的时间等待额外的请求，直到一个请求到达需要调度响应为止。

在许多地方，AckReq位对请求者非常有用。例如，如果请求者正在把最后一个请求WQE的最后一个包发送到发送队列时，则建议请求者设置AckReq位或使用其他机制来强制响应程序返回响应。如果请求者不这样做，那么响应者就有可能选择无限期地合并响应。请求者可以使用其他一些机制来确保响应者返回响应：

<span>◼ </span>始终在每条消息的最后一个（或唯一的）数据包上设置AckReq位

<span>◼ </span>在给定请求后使用NOP设置AckReq位

<span>◼ </span>在设置了AckReq位的情况下，重试需要响应的请求

对于SEND或RDMA写请求，可以在数据实际写入响应程序的内存之前安排ACK。ACK只是表示数据已成功到达响应节点的容错域。也就是说，数据已经被信道适配器接收到，并且信道适配器将把该数据写入响应节点的内存系统，或者至少向响应应用程序通知故障。

缺少AckReq位并不禁止响应程序生成响应包。一如既往，RDMA读取和原子操作请求需要显式响应，因此AckReq位对请求没有影响。

#### 9.7.5.1.7 响应格式

响应可以采取以下三种形式之一：

1）正常发送、重新同步或RDMA写入操作的确认数据包，

2）RDMA读取响应，以及

3）原子操作的确认消息——参见**第9.4.5节“原子操作”**。

这三种形式之间的关键区别在于，正常的应答包（用于发送、重新同步和RDMA写入）不携带有效载荷字段，而RDMA读取和原子操作的响应都携带有效载荷字段。此观察结果会影响响应的格式和合并确认的规则。

确认包包含以下信息：

<span>◼ </span>用于通知请求者给定请求消息成功或失败的syndrom（综合证），

<span>◼ </span>请求者用于将确认消息与其未完成请求列表相关联的PSN值，

<span>◼ </span>响应者用于通知请求者请求消息已完成的消息序列号，

<span>◼ </span>可选的端到端流控制信用/credit，

<span>◼ </span>RDMA读取响应或原子操作响应时的有效载荷数据。

以下各节将讨论这三种形式中的每一种。

#### 9.7.5.1.8 发送、重新同步或RDMA写入请求的响应格式

此格式用于确认发送、重新同步或RDMA写入请求包。正常的应答消息包含一个包，如图97所示。

#### 9.7.5.1.9 RDMA读取响应

此响应格式称为RDMA读取响应，用于确认RDMA读取请求。RDMA读取响应消息由一个或多个数据包组成。

C9-117：对于HCA，RDMA读响应包的PSN必须是连续的且单调递增的。如果响应消息包含多个包，则响应消息的第一个和最后一个包必须包含应答扩展传输头（AETH）。

o9-69：如果TCA实现RDMA功能，RDMA读响应包的PSN必须是连续的且单调递增的。如果响应消息包含多个包，则响应消息的第一个和最后一个包必须包含应答扩展传输头（AETH）。

C9-118：对于HCA，如果响应消息仅包含单个包（“only”包），则该包必须包含AETH。如图98所示。

o9-70：如果TCA实现RDMA功能，并且响应消息只包含一个包（“only”包），则该包必须包含AETH，如图98所示。

RDMA读取响应消息除了确认RDMA读取请求本身之外，还隐式地确认RDMA读取请求之前的请求。有关合并确认的规则，见**第9.7.5.1.2节“合并确认消息”**。

如**第9.7.5.1.2节“合并确认消息”**所述，第一包或唯一包的到达触发任何未完成请求消息的隐式确认。这样做是为了减少完成任何未完成的请求消息的延迟。

最后一个数据包或唯一数据包的到达触发RDMA读取请求本身的显式确认。

### 9.7.5.2 AETH格式

确认综合征/syndrome在确认信息的AETH中进行。下面的表46AETH综合征字段说明了AETH的综合征字段。

C9-119：当生成AETH时，实现RC服务的HCA响应器应编码AETH综合征字段，如表46 AETH综合征字段所示。

o9-71：如果TCA响应器执行RC服务，或者CA响应器实现RD或XRC服务，则响应器应对AETH综合征字段进行编码，如表46“AETH综合征字段”所示。

C9-119.a1：对于HCA，AETH综合征字段的msb被保留并应设置为零。

o9-71.a1：对于提供RC或RD服务的TCA或提供XRC服务的CA，AETH综合征字段的msb保留并应设置为零。

o9-72：如果CA实现可靠的数据报服务，则C CCCC位设置为零，因为没有为RD服务定义端到端信用。

位[4:0]的解释取决于位[6:5]中包含的代码。位[4:0]可以包含带或不带端到端流控制credit的肯定确认（取决于服务是RC、XRC还是RD）、RNR NAK计时器值、没有端到端credit的肯定确认或NAK代码。

C CCCC=编码的端到端流控制credit。

T TTTT=RNR NAK计时器字段——参见表48“RNR NAK计时器字段编码”。

N NNNN=NAK代码——见表47“NAK代码”。

代码011N NNNN（NAK）允许MSN与NAK包一起携带。

确认综合征在确认信息的AETH中进行。以上的表46“AETH综合征字段”说明了AETH的综合征字段。

#### 9.7.5.2.1 端到端流量控制信用/credit字段

如果AETH Syndrome字段的bits[7:5]为0，则AETH Syndrome域的位[4:0]携带从响应方到请求方的端到端流控信用编码。此字段仅对“可靠”有效连接。编码5b11111表示信用字段无效。此编码还用于接收队列不支持端到端信用的情况。有关详细信息，请参阅**第9.7.7.2节“端到端（消息级）流控制”**。

#### 9.7.5.2.2 NAK代码

如果AETH综合征字段的位[6:5]是b11，则位[4:0]携带NAK代码。代码指导请求者选择恢复策略。以下部分描述了所有可能的NAK代码。即使RNR-NAK有其自身的AETH综合征（AETH[6:5]=b01），本节也对RNR-NAK进行了描述。

有效NAK代码列表见表47“NAK代码”。

C9-120：如果请求者接收到包含保留代码的确认消息，它将认为确认包的格式不正确，并将其静默丢弃。这可能最终导致请求者在等待丢失的确认包时超时，此时它要么重新传输原始请求消息，要么停止对该发送队列的操作。

#### 9.7.5.2.3 PSN序列错误

当响应器检测到不在PSN序列中的数据包时，即PSN值既不等于预期的PSN，也不在有效的重复数据包范围内，则发生序列错误。

C9-121：响应器在构造NAK包以响应序列错误时，必须在BTH的PSN字段中插入预期的PSN值。这使得请求者将其发送队列至少备份到故障点，并开始从该点向前重新发送请求包。

PSN序列错误可由请求者多次重试。重试计数过期后，请求者的传输层通知其客户端它没有成功传输的消息。请求者在重试次数过期后所需的行为在**第9.9.2节“请求方侧错误行为”**中给出。下面的讨论指定重试计数过期之前的行为。

当响应程序检测到序列错误时，不会对接收队列产生影响，也不会消耗任何WQE。相反，接收队列只是将NAK包返回给请求者，并继续等待具有正确PSN值的入站请求包。

C9-122：一旦序列错误的NAK包被返回给请求者，响应者应丢弃所有不包含响应者预期PSN的后续请求，有效的重复请求除外。

C9-123：如果响应器接收到一个PSN在逻辑上小于其预期PSN的请求包（即有效的重复请求包），它应根据重复包处理规则对该请求进行响应。

#### 9.7.5.2.4 远程访问错误

对于RDMA读取、RDMA写入或原子操作，以下任何或所有条件都会导致R_key冲突：

<span>◼ </span>RETH的R_Key字段无效。

<span>◼ </span>指定的虚拟地址和访问长度或类型超出了与R_Key相关的本地定义限制。

<span>◼ </span>对于HCA，检测到保护域冲突。

C9-124：对于HCA响应程序，当报告RDMA远程访问错误时，确认消息的BTH字段必须包含导致远程访问错误的请求包的PSN。

o9-73：如果TCA响应程序实现RDMA功能，或者如果CA响应程序支持原子操作，则在报告远程访问错误时，确认消息的BTH字段必须包含导致远程访问错误的请求包的PSN。

除了生成NAK远程访问错误包外，响应程序检测访问错误的行为在**第9.9.3节“响应器端行为”**中有详细说明。

请求者接收NAK远程访问错误的行为在**第9.9.2节“请求方侧错误行为”**中有详细说明。

#### 9.7.5.2.5 无效请求

请求者请求的操作超出了传输服务的既定用途——通常，这是响应程序不支持的操作码，或者是长度超过可用接收缓冲区空间的请求。例如，发送到不支持RDMA的响应程序的RDMA请求将导致无效请求错误。根据特定服务，无序操作码也可能导致NAK无效请求。

C9-125：当报告无效请求时，应答包的BTH字段必须包含响应器的预期PSN值，即包含无效请求的请求包的PSN。

除了生成NAK无效请求外，响应程序在检测到无效请求时的行为在**第9.9.3节“响应方行为”**中给出。

**第9.9.2节“请求方侧错误行为”**中给出了请求者接收到NAK无效请求的行为。

#### 9.7.5.2.6 远程操作错误

当响应程序遇到阻止其接收队列完成当前请求的情况时，会发生远程操作错误。响应程序可检测到的错误条件列表，并可作为远程操作错误报告，因为该列表是特定于实现的。远程操作错误不能由请求者所做的任何操作引起。相反，它们反映了响应者的错误。

C9-126：当报告远程操作错误时，确认消息的BTH字段必须包含响应程序检测到操作错误时正在执行的请求的PSN。

除了返回NAK远程操作错误外，在**第9.9.3节“响应方行为”**中给出了响应器在检测到操作错误时的行为。

**第9.9.2节“请求方侧错误行为”**中规定了请求方在收到NAK远程操作错误时的行为。

#### 9.7.5.2.7 无效的RD请求

当响应方在RD服务中工作时检测到Q_Key或RDD违规，或者目标QP没有配置为RD服务，或者目标QP没有处于可以接受入站数据包的状态，则生成此NAK代码。或者如果检测到XRC服务的远程XRC域/XRCETH违规（参见表61响应程序错误行为摘要）

o9-74：如果响应方EE Context检测到无效的P_Key，则请求包将被EE Context静默丢弃。

如果没有检测到P_Key冲突，EE上下文将包转发到BTH中指定的接收队列。

C9-127：如果BTH指定的QP没有配置为RD业务，则返回NAK Invalid RD请求。

接收队列检查入站请求包的Q_Key，还检查其当前RDD值是否与EE上下文的RDD值匹配。

如果响应器的接收队列检测到无效的Q_Key，或者如果接收队列的RDD值与EE上下文的RDD值不匹配，则响应器应向请求方返回NAK invalid RD请求。

除了生成NAK无效的RD请求外，在检测到Q_Key或RDD违规时，响应程序的行为在**第9.9.3节“响应方行为”**中有详细说明。

请求者响应NAK invalid RD请求的行为在**第9.9.2节“请求方侧错误行为”**中指定。

#### 9.7.5.2.8 RNR NAK

在某些情况下，接收队列可能暂时无法接受入站请求消息。例如，当前可能没有发布到接收队列的有效接收WQE。当这种情况发生时，响应器可能返回一个指示接收端未就绪（RNR NAK）的响应。注：响应程序可以为任何类型的请求（例如发送、RDMA读取请求、RDMA写入请求等）返回RNR NAK。在接收到RNR NAK时，请求者可以在至少等待RNR NAK中指定的间隔之后，重试同一请求。“同一请求”是指与响应器在其RNR NAK分组中报告的具有相同PSN的分组开始的完全相同的请求消息。

C9-128：对于使用可靠连接服务的HCA请求者，在接收到RNR NAK后，请求者不得通过重用相同的PSN来替换不同的请求消息。

o9-75：如果TCA请求方实现可靠连接服务或CA实现XRC服务，则在收到RNR NAK后，请求方不得通过重用同一个PSN来替换不同的请求消息。

对于可靠的数据报服务，请求者可以准确地重复请求，将EEC移动到错误状态，放弃请求或暂停请求，如第9.7.8节“可靠数据报”所述。

C9-129：使用可靠连接服务的HCA响应器在生成RNR NAK时，应在AETH的计时器字段中指示适当的间隔。AETH定时器字段中加载的值应如表48 RNR NAK定时器字段编码所示。

o9-76：CA响应器执行可靠数据报业务或XRC业务，或TCA实现可靠连接业务时，应遵循以下规则：当生成RNR NAK时，响应器应在AETH的定时器字段中指明适当的间隔。AETH定时器字段中加载的值应如表48 RNR NAK定时器字段编码所示。

C9-130：提供可靠连接服务的HCA请求程序在收到RNR NAK之后，必须至少等待AETH的计时器字段中指定的间隔，然后才能重试请求。如果请求者在重新尝试请求之前未能等待适当的超时间隔，则响应者可能会静默地丢弃数据包。

o9-76.a1：提供可靠数据报服务或XRC服务的HCA请求程序在收到RNR NAK后，必须至少等待AETH的计时器字段中指定的间隔，然后再重试请求。如果请求者在重新尝试请求之前未能等待适当的超时间隔，则响应者可能会静默地丢弃数据包。

o9-76.a2：提供可靠连接服务或XRC服务的TCA请求程序，或提供可靠数据报服务的TCA请求程序，在接收到RNR NAK之后，必须至少等待AETH的计时器字段中指定的时间间隔，然后重试请求。如果请求者在重新尝试请求之前未能等待适当的超时间隔，则响应者可能会静默地丢弃数据包。

C9-131：此符合性声明已过时并已删除。

C9-132：使用可靠连接服务的HCA请求者应维护一个3位重试计数器，该计数器在连接建立期间加载，由响应者提供信息。此计数器用于限制请求者可以重试已被RNR NAK的操作的次数。当收到RNR NAK响应时，如果RNR NAK retry计数器不等于7（表示无限重试），则请求者应减少RNR NAK重试计数器。此后，当重试计时器过期时，如果重试计数器为非零，则请求者可以重新发出请求。

o9-77：如果CA请求方实现可靠的数据报或XRC服务，或者如果TCA请求方实现可靠连接服务，则应维护一个3位重试计数器，该计数器在建立连接时加载，由响应方提供信息。此计数器用于限制请求者可以重试已被RNR NAK'ed的操作的次数。当收到RNR NAK响应时，如果RNR NAK retry计数器不等于7（表示无限重试），则请求者应减少RNR NAK重试计数器。此后，当重试计时器过期时，如果重试计数器为非零，则请求者可以重新发出请求。

如果在RNR NAK重试计时器过期时重试计数器已减少到零，则请求程序将记录本地检测到的错误。有关更多详细信息，请参阅**第9.9.2.1节“请求端错误检测-本地检测到的错误”**。

定时器字段编码如下表所示。

不禁止对不影响整个消息（例如内存页不存在）的临时问题使用RNR NAK。特别地，对于可靠的数据报服务，响应者在发送请求消息的中间返回的RNR NAK可能导致请求者放弃当前消息，并从另一个队列对发送新消息。这可能导致响应程序出现意外的不完整消息。响应程序在执行RESYNC请求时检测到这些不完整的消息，从而允许响应程序错误地完成部分完成的WQE并开始接收新请求。

当本地资源很少、不可用时，响应程序应将此功能用作延迟传入请求的机制。RNR-NAK机制消耗带宽，因为传入的数据包将被中止并必须重新发送。

## 9.7.6 请求者：接收响应

### 9.7.6.1 验证入站响应包

在接收到入站确认包时，请求者按如下方式验证该包：

C9-133：为了验证数据包的完整性，请求者应按照第9.6节“数据包传输头验证”中的规定验证数据包。无效的数据包将由请求者自动丢弃。

C9-134：对于使用可靠连接服务的HCA请求者，应检查PSN以检测无序分组。由于可以按照**第9.7.5.1.2节“合并确认消息”**的描述合并确认，因此使用PSN来检测合并响应。

o9-78：如果TCA请求方实现可靠的连接服务，或者CA请求方实现可靠的数据报服务或XRC服务，则应检查每个确认包的PSN，以检测出无序的数据包。由于可以按照**第9.7.5.1.2节“合并确认消息”**的描述合并确认，因此使用PSN来检测合并响应。

C9-135：对于使用可靠连接服务的HCA请求者，应根据表47 NAK代码检查确认综合征的有效性。应简单地丢弃包含保留NAK代码的响应包。

o9-79：若TCA请求者实现可靠连接服务，若TCA请求者实现可靠连接服务，或若CA请求者实现可靠数据报或XRC服务，则应根据表47 NAK代码检查确认综合征的有效性。应简单地丢弃包含保留NAK代码的响应包。

o9-79.a1：如果CA实施可靠的数据报服务或XRC服务，当收到响应包时，请求者应对照当前EEC的预期QPn检查BTH中包含的目的地QPn。如果响应包不是发往当前活动的请求方侧QP，则请求方应丢弃它。

请求者还必须确保响应适合所执行的操作类型。例如，在某些拥塞的结构情况下，当预期RDMA读取或原子响应正在执行时，ACK可能到达。即使响应包中包含的PSN与请求者期望的响应PSN匹配，也可能发生这种情况。反之亦然。

因此，请求者应该验证接收到的响应包是否与未完成的请求一致。如果不是，请求者的行为应该如表59请求者侧错误行为所述。

C9-135.a1：此合规声明已过时。

如果包被确定为有效，则由请求者进行处理。在处理应答包时，请求者可能会遇到本地错误。请求者在处理确认消息时可能遇到的本地错误列表没有被指定，因为它是特定于实现的，但是包含了由请求方的错误引起的任何错误。这种情况下所需的行为在第9.9.2节“请求端错误行为”中指定。

验证入站响应包的PSN依赖于标识PSN序列中的三个关键点。这三点是：

1） 请求者的最大转发进度——请求者发送的任何请求中逻辑上最大的（模数2^24）PSN。（这包括为RDMA读取响应分配的PSN空间。）它标记有效区域的“右侧”边缘。

2） 最早的未确认请求——最早的未处理（未确认）请求的PSN。这表示由请求者查看的响应程序取得的最大前进进度。此PSN的意义在于它标记了重复区域的结束，即逻辑上小于此值的PSN响应将被视为无效或重复。

3） 最早的有效请求——此点标记有效区域的“左侧”边缘。

这三点的说明见下图。

与请求包的情况一样，每个响应包都携带一个PSN。请求者在接收到响应包时，检查PSN以确定响应是预期响应还是ghost确认包。从概念上讲，请求者跟踪最早的未确认请求包的PSN和迄今为止发送的逻辑上最大的（模数2^24）PSN，包括为RDMA读取响应保留的PSN。这两个PSN将上图中标识的一系列PSN的端点定义为未确认区域。如果响应包的PSN落在该范围内，则该包是预期的响应包。如果响应不在该区域内，则它被视为重复响应，并根据**第9.7.5.1.4节“确认重复请求”**中定义的规则进行处理，或者将其视为ghost（无效）确认包并被请求者丢弃。

C9-136：对于使用可靠连接服务的HCA请求者，请求者应丢弃ghost确认包。

o9-80：如果TCA请求方实现可靠连接服务，或者CA请求方实现可靠数据报服务或XRC服务，则请求方应丢弃ghost确认包。

#### 9.7.6.1.1 重试请求的PSN

在某些情况下（如下所述），请求者可能需要重试请求。在PSN术语中，这意味着请求者可以用逻辑上小于迄今为止传输的最大PSN的PSN（模数2^24）来重新发送分组。在下图中，这被标识为重新尝试的请求。

在重试请求的过程中，请求者应维护标记的最远PSN点（高水位线）的方法，即使它在重新尝试请求时逻辑上“备份”了PSN序列。这是必要的，因为对重试请求的响应可能具有逻辑上大于重试请求的PSN的PSN。这可能是因为在某些情况下，响应程序可能会将重新尝试的请求解释为重复请求。如果是这样，它（响应者）有义务返回标记其提前标记的最远点的PSN，这可能超出重新尝试请求的PSN。

请求者需要维护这三个指针（最大提前/advance点、最早未确认请求的PSN和重新尝试的请求的PSN）被称为三PSN范式。尽管各种实现可能会找到实现三个PSN范式的不同方法，但是请求者必须考虑这样一个事实：响应者可能返回对重新尝试的请求的响应，该PSN在逻辑上比重新尝试的请求本身的PSN大（更超前/further advanced）。

#### 9.7.6.1.2 请求者对NAK消息的响应

请求者对否定(negative)响应消息的反应取决于返回的NAK代码，以及队列对是否配置为可靠连接、XRC还是可靠的数据报服务。

NAK序列错误触发请求的自动重试。响应包中的PSN是请求者对响应者认为它错过的请求包的指示，因此，请求者可以重试该请求。为了防止请求者永远重试同一请求，请求者维护一个3位的重试计数器，该计数器用于计算某个特定请求包被重试和超时的次数。有关重试计数器的完整说明，请参阅**第9.9.2.1节“请求端错误检测-本地检测到的错误”**。

C9-137：使用可靠连接服务的HCA请求程序应在每次响应程序返回给定请求包的NAK序列错误时递减其3位重试计数器。当给定的未完成请求被清除时，计数器应重新加载。如果不支持自动路径迁移，并且再次返回NAK序列错误，则请求者应声明本地检测到的错误。

o9-80.a1：支持可靠数据报服务或XRC服务的HCA请求程序应在每次响应程序返回给定请求包的NAK序列错误时递减其3位重试计数器。当给定的未完成请求被清除时，计数器应重新加载。如果不支持自动路径迁移，并且再次返回NAK序列错误，则请求者应声明本地检测到的错误。

o9-81：实现可靠连接服务或可靠数据报服务或XRC服务的TCA请求程序应在每次响应程序返回给定请求包的NAK序列错误时递减其3位重试计数器。当给定的未完成请求被清除时，计数器应重新加载。如果不支持自动路径迁移，并且再次返回NAK序列错误，则请求者应声明本地检测到的错误。

o9-82：如果CA支持自动路径迁移，则需要执行以下操作。如果在重试计数器减至零后返回NAK序列错误，则信道适配器应尝试自动路径迁移。在自动路径迁移之后，请求者应重新加载重试计数器并重新开始该过程。如果请求者在多次重试后仍未能成功发送请求，则请求者应声明本地检测到的错误。

对于其他NAK包，发送队列的响应取决于该队列是提供可靠的数据报还是可靠连接/XRC服务。

可靠的数据报行为：可靠的数据报需要使用一个EE上下文来维护数据包序列号，从而确保请求的可靠传递。响应NAK的规则确保请求方的当前PSN和响应方的预期PSN保持同步。因此，请求者的EE上下文和响应者的EE上下文之间的连接仍然存在。这允许连接继续服务于其他发送/接收QP。

根据问题的原因和操作，在检测到一个失败的请求包后，EE上下文可以采取以下任意选项:

a） 它可以从同一个QP重试同一个失败的包（注意，不是所有NAK都可以重试，对于那些可以重试的NAK，有可能重试的次数有限制），或者

b）它可以将QP和EE上下文转换到错误状态，错误的（以错误状态）完成失败请求消息，或

c）根据第9.7.8节“可靠数据报”中详细说明的规则，可将当前QP置于SQEr状态并生成重新同步（RESYNC）请求。在这种情况下，失败的WQE通常会以错误的方式结束。

最后一个策略的目的是允许请求方的EE上下文继续服务，从而避免需要断开EE Context-to-EE Context的连接。

如果要重试“同一个失败的包”，则请求者不必从应答者的NAK中指示的PSN开始其重传序列；相反，它可以从较早的请求分组开始其重传。这些早期的请求数据包被响应程序视为正常的重复数据包，不会产生不良副作用。

有关错误和EE上下文后续行为的完整描述，请参见**第9.9节“错误检测和处理”**。

C9-138：对于使用可靠连接服务的HCA请求者，请求者必须接收和丢弃任何重复的确认消息，并且没有不良副作用。

o9-83：如果TCA请求者实现可靠的连接服务，或者如果CA请求者实现可靠的数据报服务或XRC服务，则请求者必须接收并丢弃任何重复的确认消息，而不会产生不良副作用。

可靠连接行为：对于可靠的连接（包括XRC），请求者在收到NAK时只有两种可能的选择。它可以重试同一个请求包，也可以将当前WQE标记为错误完成并通知其客户端。请注意，并非所有的NAK都可以重试。

如果请求者重试同一请求包，则不需要从响应者的NAK中指示的PSN开始其重传序列；相反，它可以从较早的请求包开始重传。这些早期的请求数据包被响应程序视为正常的重复数据包，不会产生不良副作用。

#### 9.7.6.1.3 检测丢失的确认消息和超时

在某些错误情况下，请求者不会收到响应其一个或多个请求的确认消息。出现这种情况的原因有三种：

1）响应程序生成的确认消息随后在fabric中丢失，或者，

2）响应程序由于某种原因失败，无法生成确认消息，或

3）原始请求消息在响应程序接收之前已在fabric中丢失。

这三种情况都被请求者检测为丢失的确认消息。

通常，由于确认合并，这些错误会自动更正：请求者接收到的下一个确认用于隐式地确认所有未完成的请求。

但是，有几种情况下，丢失的确认消息不会由合并的确认规则自动恢复。例如，在fabric中丢失的NAK消息将不会通过确认合并来解决，因为响应器侧规则要求在给定时间内响应器的未处理NAK消息不能超过一个。

C9-139：对于使用可靠连接服务的HCA请求者，为了检测丢失的响应，每个发送队列都需要实现一个传输计时器来计时未完成的请求。

o9-84：如果TCA请求程序实现可靠的连接服务，或者如果CA实现XRC服务来检测丢失的响应，则每个发送队列都需要实现一个传输计时器来为未完成的请求计时。

o9-85：如果CA请求者实现可靠的数据报服务，为了检测丢失的响应，每个EE上下文都需要实现一个传输计时器来计时未完成的请求。

由于信道适配器的fabric、调度算法和体系结构以及许多其他因素的变化，不可能也不希望以高精度的方式对未完成的请求进行计时。然而，传输计时器是ACK/NAK协议的一个组成部分，它提供了一种确定的方法来检测丢失的请求或响应。

请求者不需要分别为每个发送到fabric中的请求计时，而是在需要响应时简单地启动计时器。一旦启动，只要有未完成的预期响应，每当收到确认包时，计时器都会重新启动。计时器不检测特定预期应答包的丢失，而是简单地检测响应包的持续缺失。

计时器测量以下值中的较小值：

<span>◼ </span>自请求者发送在BTH中设置了AckReq位的数据包以来的时间，

<span>◼ </span>或自最后一个有效的确认数据包到达后的时间。

具体操作如下。

请求者在计时器当前未运行时启动计时器运行，并且：

1）请求者在发送或RDMA写入请求中设置AckReq位，或者，

2）请求者生成RDMA读取请求，或者，

3）请求者生成原子操作请求。

此后，只要仍有未完成的预期响应，请求者每次收到新的入站确认包时都会重新启动计时器。

当没有未完成的预期响应时，计时器将停止。

请求者通过在请求包中设置AckReq位或通过生成RDMA读取请求或原子操作请求来创建“预期响应”。未完成的预期响应是对在BTH中设置了AckReq位的任何请求包的响应，或者对尚未被确认的任何RDMA读取请求或原子操作请求的响应。

每个QP有一个与之相关联的本地ACK超时值，该值用于导出传输计时器超时间隔T_tr。

C9-140：对于使用可靠连接服务的HCA请求程序，传输计时器超时间隔T_tr应定义为4.096 uS*2^（本地ACK超时）。本地ACK超时应为5bit位值，零表示计时器被禁用。本地ACK超时的最小可接受值（零除外）应由CA供应商定义。如果在QP上下文中加载的本地ACK超时值小于CA支持的最小值，则CA可以使用其最小值。

C9-141：对于使用可靠连接服务的HCA请求者，QP应提供检测超时条件的设施。

超时时间间隔应该在调度请求之后开始。超时条件T_o的检测时间不应小于超时时间T_tr，且不应超过超时时间间隔的四倍, 4T_tr。

因此，T_tr<=T_o<=4T_tr。

一旦检测到给定请求包的超时，请求者可以重试请求。

C9-142：对于使用可靠连接服务的HCA请求者，为了防止请求者永远重试请求，请求者应维护一个3位的重试计数器，该计数器用于计算某个请求包被重试和超时的次数。对于给定的请求包，每次传输计时器过期时，该计数器应递减。当给定的未完成请求被清除时，计数器应重新加载。

有关重试计数器的完整说明，请参阅**第9.9.2.1节“请求端错误检测-本地检测到的错误”**。

C9-143：对于使用可靠连接服务的HCA请求程序，如果不支持自动路径迁移，并且如果传输计时器在重试计数器减至零后过期，则请求者应声明本地检测到的错误。

o9-86：如果支持自动路径迁移，并且如果传输计时器在重试计数器减至零后过期，则信道适配器应尝试自动路径迁移。在自动路径迁移之后，请求者应重新加载传输计时器重试计数器，并重新开始该过程。如果请求者在多次重试后仍未能成功发送请求，则请求者应声明本地检测到的错误。

o9-87：如果TCA请求者实现可靠连接服务，或者如果CA实现XRC服务，则前面五条HCA符合性声明（即未完成请求的超时规则）应适用于该TCA或CA。

o9-88：如果一个CA请求者实现了可靠的数据报服务，那么前面的五个HCA符合性声明（即未完成请求的超时规则）应适用于该CA。在这种情况下，所描述的功能适用于EE上下文而不是队列对。

#### 9.7.6.1.4 重复确认

**第9.7.1节“分组序列号（PSN）”**描述了如何生成重复请求。这些请求可能导致响应程序返回重复的确认。从请求者的角度来看，响应者还可以发送看起来像“幽灵Ghost ACK”的未经请求的ACK。

C9-144：对于使用可靠连接服务的HCA请求程序，如果将响应程序配置为生成端到端流控制信用，则请求程序必须从重复的确认中提取端到端流控制信用。

o9-89：如果TCA实现可靠的连接服务，并且如果响应程序配置为生成端到端流控制信用，则请求者必须从重复的确认中提取端到端流控制信用。

C9-145：对于使用可靠连接服务的HCA请求者，应丢弃重复的确认。

o9-90：如果TCA请求方实现可靠连接服务，则应丢弃重复的确认。

有关完整说明，请参阅**第9.7.7.2节“端到端（消息级）流控制”**。

## 9.7.7 可靠连接

可靠连接是在单个本地QP和单个远程QP之间创建的连接，该连接可以保证在本地QP和远程QP之间最多传递一次消息，并且没有损坏（在没有不可恢复错误的情况下）。

扩展可靠连接服务（XRC）具有许多与可靠连接服务相同的特性，如第9.7.9节“XRC”部分所述。

期望的可靠性特性由分组序列号的应用和ACK/NAK协议提供。

C9-146：对于HCA，为可靠连接服务配置的每个QP必须符合**第9.7节“可靠服务”**中规定的要求，表49“可靠连接服务特性”中给出的特性，以及本节中给出的任何附加要求。

o9-91：本合规声明已过时，已被删除。

o9-91.a1：如果CA实施XRC服务，则其应符合XRC服务的合规声明C9-146、C9-147、C9-148、C9-149。

### 9.7.7.1 生成MSN值

对于可靠的连接服务，消息序列号(MSN, Message Sequence Number)是响应者返回给请求者的数字，指示响应者完成的消息数。MSN在AETH的三个最低有效字节中携带。MSN作为一种服务提供给请求者，通过通知请求者响应者已完成的消息来帮助请求者完成WQEs。

C9-147：使用可靠连接服务的HCA响应程序应在包含AETH的任何响应包的AETH中返回MSN。

o9-92：如果TCA响应器实现可靠连接服务，则它应在包含AETH的任何响应包的AETH中返回MSN。

在逻辑上，请求者将一个顺序发送序列号（SSN, Send Sequence Number）与发送队列中的每个WQE相关联。SSN与每个响应包中的响应程序返回的MSN之间存在一对一关系。因此，当请求者接收到响应时，它将MSN解释为：表示由响应者完成的最新请求的SSN，以确定哪些发送WQE可以完成。

请注意，如上所述的SSN只是一个逻辑概念，其给出的目的是传达如何应用MSN的概念；如所述，不需要实现来实现它。

初始化之后，发送到发送队列的第一个WQE分配了一个SSN。响应程序将其MSN计数器初始化为零。此后，每当完成入站请求消息的执行时，响应程序都会增加其24位MSN值。如下图所示。

C9-148：使用可靠连接服务的HCA响应器应将其MSN值初始化为零。一旦成功完成对新的有效请求消息的处理，响应器应增加其MSN。对于重复请求，不应增加MSN。递增的MSN应在RDMA读取或原子响应的最后一个或唯一一个包中返回。对于RDMA读取请求，响应器可以在完成对请求的验证之后，在开始传输任何请求的数据之前增加其MSN，并且可以在第一响应包的AETH中返回递增的MSN。对于任何给定的请求消息，MSN只能增加一次。

o9-93：如果TCA响应器实现可靠的连接服务，它应按照前面的合规性声明计算和更新MSN。

#### 9.7.7.1.1 请求者接收新MSN的行为

如上所述，请求者可以将响应包中存在的新MSN值用作完成发送到其发送队列的某些WQE的信号。由于响应者可以选择合并确认，因此单个响应包实际上可以确认多个请求消息。因此，当它接收到一个新的MSN时，请求者开始评估其发送队列上的WQE，从最早的未完成WQE开始并向前推进。下面的图说明了在发送队列上没有未完成的RDMA读取请求或原子操作请求的情况。

对于存在未完成的RDMA读取请求或原子操作请求的情况，情况稍微复杂一些。在这种情况下，请求者只完成到第一个未完成的RDMA读取请求、原子操作请求或其SSN与响应包中的MSN匹配的WQE，以先到者为准。这是因为RDMA读取请求和原子操作请求需要显式响应，因此在收到此类显式响应之前无法完成。。

C9-149：对于使用可靠连接服务的HCA响应程序，无论响应是肯定确认、否定确认还是重复确认，都应在AETH中插入MSN计数器。

o9-94：如果TCA响应器实现可靠连接服务，则不管响应是肯定确认、否定确认还是重复确认，都应在AETH中插入MSN计数器。

#### 9.7.7.2 端到端（消息级）流控制

IBA为可靠的连接提供了端到端（或消息级）流控制功能，响应程序可以使用IBA优化其接收资源的使用。从本质上讲，请求者不能发送请求消息，除非它有适当的信用/credit额度。

编码的信用在AETH的“症状/Syndrome”字段中以确认消息的形式从响应者传输到请求者。AETH中的信用是针对同一AETH的MSN字段；因此，正确解释信用字段也需要对MSN字段进行解释。有关相应AETH字段的完整说明，请参阅**第9.7.5.2节“AETH格式”**。

每个credit表示接收一个入站请求消息所需的接收资源。具体地说，每个信用代表一个发布到接收队列的WQE。然而，接收信用的存在并不一定意味着已经分配了足够的物理内存。例如，即使有足够的信用额度，仍然有可能遇到内存不足，无法接收整个入站消息的情况。

另一方面，共享接收队列的概念允许一组接收队列从一个公共的接收WQE池（共享接收队列）中提取。因此，对于任何一个单独的接收队列来说，没有实际的方法来精确地度量共享接收队列中可用的WQE的数量。因此，对与共享接收队列相关联的任何QP禁用端到端流控制机制。

1）端到端信用机制仅适用于可靠连接服务。

2）端到端信用由响应者的接收队列生成，并由请求者的发送队列使用。

3）支持端到端流量控制的CA要求在第17章：通道适配器中给出。HCA接收队列必须生成端到端信用（与共享接收队列关联的QP除外），但TCA接收队列不需要这样做。如果TCA的接收队列生成端到端信用，则相应的发送队列必须接收并响应这些信用。

4）信用是根据每个消息发出的，而不考虑消息的大小。

5）端到端信用在AETH中以5位编码字段形式携带。

6）响应者可以通过使用未经请求的确认包来异步地向请求者发送信用。通过重新发送最近发送的确认包来创建未经请求的确认包。

C9-150：本合规声明已过时，已被C9-150.2.1取代。

C9-150.2.1：对于与SRQ无关的QP，每个HCA接收队列应生成端到端的流控制信用。如果QP与SRQ相关联，HCA接收队列不应产生端到端的流控制信用。

o9-95：本合规声明已过时，已被o9-95.2.1取代：

o9-95.2.1：除与SRQ相关联的QP外，每个TCA接收队列可产生端到端信用。如果TCA支持SRQ，则TCA不得为与SRQ关联的QP生成端到端流量控制信用。

C9-151：如果TCA的给定接收队列产生端到端信用，则相应的发送队列应接收并响应这些信用。这是CA的每个发送队列的要求。

#### 9.7.7.2.1 响应者向请求者发送信用

定义了两种机制来将信用从响应者的接收队列传输到请求者的发送队列。该信用可以与现有的确认信息相结合，或者由响应者生成一个特殊的未经请求的确认消息。背负/Piggybacked信用是指在已经安排好的应答包的AETH字段中携带的那些信用。

Piggybacked信用：

端到端信用的piggyback是指在一个正常的确认包的AETH中将信用转移给请求者。AETH综合征[4:0]携带信用值。当AETH中的MSN字段也有效时，信用可以被装载到任何确认包上。

主动确认包/Unsolicited Acknowledge Packet：

从PSN的角度来看，一条未经请求的确认消息在请求者看来就像是最近的肯定应答消息的副本。然而，它总是有一个确认的操作码，即使最近的肯定应答是RDMA读取响应或原子响应。由于ACK/NAK协议禁止响应器发送重复的否定应答包（NAK），因此不能通过重新发送NAK包来创建未经请求的应答。

响应者可随时发送未经请求的确认。请求者的发送队列只是从最近接收到的应答包中恢复信用字段和MSN。

由于一个未经请求的确认包在请求者看来是一个重复的响应，它对请求者没有任何影响，除了信用的传递。

C9-152：非请求确认包的MSN字段必须具有有效的MSN字段。

#### 9.7.7.2.2 协商连接：初始信用

对于已建立的每个连接，每个方向都分别确定使用（或不使用）端到端流量控制。接收队列的功能决定了这一半连接的流控制特性。

C9-153：如果接收队列发出信号说它希望生成信用，那么相应的发送队列必须遵守端到端的流控制规则。另一方面，如果接收队列发出信号，表示它不会产生端到端的流控制信用，则相应的发送队列可以不考虑信用而随意发送请求消息。这是CA的每个发送队列的要求。

C9-154：如果TCA的接收队列未产生端到端信用，则应将值5b11111放入AETH综合征[4:0]中，表示信用字段无效。

o9-95.2.2：如果CA支持SRQ，QP提供可靠的连接服务并与SRQ关联，则QP不得产生端到端信用，并应将值5b11111置于AETH综合征[4:0]中，表示信用字段无效。

C9-155：当接收队列处于重置状态时，传输应将初始信用计数设置为零。一旦队列对转换到INITIALIZED、RTR、SQD或RTS状态，它将为每个已发布的接收WQE增加其信用计数。

一旦它处于RTR、SQD或RTS状态，响应者可以使用未请求的确认将这些信用转移给请求者。

通常，通过重新发送最近发送的带有更新的信用字段的肯定确认数据包来创建主动确认。但是，在初始化时，还没有发送确认包，因此无法使用创建未经请求的确认的常规方法。因此，在初始化时，通过从初始PSN中减去“1”来创建未经请求的确认。因此，当接收队列处于复位状态时，如果PSN被初始化为0x000000，则初始主动应答的PSN应为0xFFFFFF。在此上下文中，“初始化时间”是指从接收队列转换出重置状态并且尚未在RTR、SQD或RTS状态下发送确认包时开始的间隔。

对于接收该初始未经请求的确认包的发送队列，它将显示为“ghost”确认包，如图99响应包PSN区域。请求者的发送队列可以接受未经请求的确认包中包含的MSN和credits，但忽略包的其余部分。这是ghost响应的常规规则的一个例外，该规则要求丢弃ghost确认数据包。

尽管有上述规定，请求者应负责从响应者处恢复初始信用；如果响应者使用未经请求的确认提供初始信用，请求者可以接受这些作为其初始信用，以履行其恢复初始信用的责任。

C9-156：如果响应者不提供初始信用，请求者应按照**第9.7.7.2.5节“请求者行为-受限发送WQEs”**中的规定进行操作。

图104“请求者端到端信用流程”和图105“响应者端到端信用初始化过程”描述了这种行为。请注意，这些图并没有描述接收和发送队列的所有正常状态转换。这些在软件接口一章中有详细说明。

#### 9.7.7.2.3 计算信用的响应程序算法

C9-157：本合规声明已过时，已被C9-157.2.1:取代。

C9-157.2.1：对于在与SRQ无关的QP上使用可靠连接服务的HCA，接收队列应增加发送到接收队列的每个WQE的信用计数。对于接收到的消耗WQE的每个入站请求消息，它应减少其信用计数。因此，当响应程序收到入站RDMA读取请求、没有立即数据的RDMA写入请求或原子操作请求时，不会调整其信用计数。如果接收队列与SRQ关联，则无论可能发布到接收队列的WQE如何，响应程序都不会调整其信用计数。

o9-96：如果TCA实现可靠的连接服务，并且如果接收队列生成端到端的流控制信用，则它应增加发送到接收队列的每个WQE的信用计数。对于接收到的消耗WQE的每个入站请求消息，它应减少其信用计数。因此，当响应程序接收到RDMA读取请求、没有立即数据的RDMA写入请求或原子操作请求时，不会调整其信用计数。

C9-158：此符合性声明已过时，已被C9-158.2.1:取代。

C9-158.2.1：对于在与SRQ无关的QP上使用可靠连接服务的HCA，对于生成的每个确认消息（无论是正常的确认消息还是未经请求的确认消息），接收队列应插入其当前编码的信用计数，如表50“端到端流量控制信用编码”，AETH综合征[4:0]字段所示。例如，如果接收队列有五个可用的信用，它应在AETH中插入5位值b00100。它还包括其当前的MSN值。如果QP与SRQ关联，则接收队列应在AETH 中插入5位值5b11111。

o9-97：如果TCA实现可靠的连接服务，并且如果接收队列生成端到端流控制信用，则对于生成的每个确认消息，无论是正常的确认消息还是未经请求的确认消息，在AETH综合征[4:0]中，应插入表50“端到端流量控制信用编码”中所示的当前编码信用计数。例如，如果接收队列有五个可用的信用，它应在AETH中插入5位值b00100。它还包括其当前的MSN值。如果TCA未生成端到端流量控制，则应插入表50“端到端流量控制信用编码”中所示的值，以指示“信用计数”字段无效。

#### 9.7.7.2.4 请求者行为

信用的存在或不存在限制了发送方传输请求的能力，这将消耗接收WQE（发送请求或具有立即数据的RDMA写入请求）。

C9-159：发送队列在没有可用信用时的行为应符合**第9.7.7.2.5节“请求者行为-受限发送WQEs”**的规定。

请求者可以始终发送不使用接收WQE（没有立即数据的RDMA写入请求、RDMA读取请求或原子操作请求）的请求，而不考虑信用。

C9-160：请求者不得违反本规范中所述的正常处理顺序规则，尤其是**第9.5节“处理顺序”**。

特别是，请求者不能在发送队列中搜索不使用接收WQE的请求并无序地传输这些请求，请求者也不能违反控制fenced WQE的规则。

可用的信用在AETH综合征[4:0]中编码和携带；MSN携带在AETH的最低有效3字节中。下表50显示了每个有效编码信用的实际信用数。

在逻辑上，请求者将一个顺序发送序列号（SSN）与发送队列中的每个WQE相关联。SSN与每个响应包中的响应程序返回的MSN之间存在一对一关系。因此，请求者将MSN解释为表示由响应者完成的最新请求的SSN。

C9-161：响应程序在AETH中返回的编码信用计数应指定相对于MSN发布到响应程序接收队列的接收WQE数量，除非响应程序未生成端到端流控制信用，在这种情况下，AETH中携带“无效”代码。

由于MSN与请求者的SSN直接相关，所以信用计数是响应者完成的最近一个请求的SSN到发送队列中的一个简单偏移量。逻辑上，MSN加上信用计数的总和就是请求者的限制序列号（LSN，Limit Sequence Number）。请求者可以自由地发送其SSN小于或等于计算的LSN的任何请求。

如果响应者返回AETH中的“无效”代码而不是信用计数，则请求者可以随意地传输请求。响应程序使用“无效”代码表示AETH credit count字段无效，因为响应程序不生成端到端信用。

即使是产生端到端信用的响应器也可以选择发送AETH中的“无效”代码。但是，一旦请求者从响应者接收到AETH中的“无效”代码，请求者可以选择忽略AETH credit count字段，以用于该连接上的所有未来事务。因此，如果响应器在发出“无效”信号后继续返回有效信用，结果可能是不可预测的。

任何SSN大于当前计算的LSN的请求都被称为受限的。发送队列遇到受限请求时的行为如**第9.7.7.2.5节“请求者行为-受限发送WQEs”**中所述。

图106说明了AETH中的响应程序返回的值与请求者的发送队列之间的关系。

请求者每次收到包含有效信用的确认数据包时都会计算一个新的LSN。请求者还动态地调整LSN，为它希望发送的每个不消耗接收WQE的请求（RDMA读取请求、没有立即数据的RDMA写入请求或原子操作请求）添加一个LSN。这种调整是允许请求者发送不使用接收WQE的请求的机制。

任何给定的实现都不需要实现上述LSN和SSN机制，但必须在语义上符合所描述的行为。

#### 9.7.7.2.5 请求者行为—受限发送WQES

C9-162：当请求者在其发送队列上遇到没有可用信用的WQE时，该WQE被称为受限。当发送队列遇到受限WQE时，其行为应如下所示：

<span>◼ </span>如果受限请求WQE是RDMA读取请求、没有立即数据的RDMA写入请求或原子操作请求，则可以正常发送，而不考虑信用的可用性。请求排序的常规规则仍然有效（即，发送队列可能不会搜索已发布的WQE列表，以尝试查找要无序发送的不受限的WQE）。在发送这样的请求之后，请求者增加其计算的LSN值，因为发送的请求不消耗receive WQE，因此也不消耗credit。

<span>◼ </span>如果受限请求WQE是一个发送请求，则发送队列在必须停止传输并等待确认包之前可发送不超过请求消息的单个包。为确保响应器将生成响应，请求者应在该单个包中设置AckReq位。

<span>◼ </span>如果受限请求WQE是具有立即数据的RDMA写请求，则请求者可以在必须停止传输并等待确认包之前发送整个请求消息。这是允许的，因为实际使用接收WQE的是包含请求立即数据的单个包。为确保响应器将产生响应，请求者应在请求消息的最后一个分组中设置AckReq位。

C9-163：对于使用可靠连接服务的HCA，如果有限的WQE是一个发送请求，则发送队列应发送不超过请求消息的单个包。在该单包内，应设置BTH的应答请求（AckReq）位。然后，请求者应停止传输并等待确认包。

o9-98：如果TCA实现可靠的连接服务，并且如果有限的WQE是一个发送请求，则发送队列应发送不超过请求消息的单个包。在该单包内，应设置BTH的应答请求（AckReq）位。然后，请求者应停止传输并等待确认包。

o9-99：在使用可靠连接服务的HCA中，或者如果TCA实现可靠连接服务，并且如果有限请求WQE是RDMA写入请求，则请求者可以在必须停止传输并等待确认包之前发送整个请求消息。为确保响应器生成响应，请求者应在RDMA写入请求的最后一个数据包中设置应答请求（AckReq）位。

C9-164：由于响应者的接收队列可能在任何时候生成未经请求的确认消息，请求者应准备随时从响应者接收未请求的确认消息，前提是接收队列已发出信号，表示它将生成端到端流控制信用。

未经请求的确认仅用于将信用从响应者转移到请求者。在收到未经请求的确认后，请求者按照上述规定重新计算其LSN并相应地作出响应。信用不足并不影响请求者重新传输以前传输的请求的能力，这是从丢失的数据包中恢复的一部分。端到端信用仅限制新请求消息的传输。例如，如果请求者在发送了一个有限发送请求的单个数据包后检测到超时情况，则它将一如既往地减少其超时重试计数器并重新传输该请求。

## 9.7.8 可靠数据报

可靠数据报提供可靠的通信，即可靠性和错误恢复水平与可靠连接相同，采用一对多模式。请求者的发送队列可以在相同或不同节点上的不同QP处向不同的响应者发送顺序消息。响应器QP可以从相同或不同终端节点上的多个请求者接收消息。与不可靠数据报传输服务一样，源端节点和源QP被提供给响应者。

使用可靠数据报的动机是为参与“all to all”通信的应用程序节省QP名称空间。考虑N个处理器节点，每个节点有M个进程。如果所有M个进程都希望与所有节点上的所有进程通信，那么可靠的连接服务需要每个节点上有M^2*（N-1）个QPs（M*(N-1)*M）。相比之下，可靠的数据报服务只需要在每个节点上建立M个QPs+N个“端到端”（EE）连接，以实现完全相同的通信。

每个远程终端节点至少使用一个“QP-like”的上下文来实现可靠性，这被称为端到端上下文（EE上下文或EEC）。此上下文提供定位远程节点、序列化和交换确认以及维护可靠性所需的信息。

服务仍然使用QPs来提供队列、WQE指针、保护检查参数等。QP和EEC一起包含将消息可靠地移动到目的地所需的信息。但是许多QP可以使用单个EEC来发送或接收，并且QP可以通过几个不同的EEC进行通信，每个EEC选择一个。

当应用程序确定要与之通信的目标时，它必须首先建立（或使用已经建立的）EE上下文。

与可靠连接一样，要用于此服务的本地QP在使用前由应用程序在RD服务模式下建立。远程QP以依赖于应用的方式被选择。

一旦EE上下文被创建，客户端可以通过这个EE上下文向响应者QP发送消息。客户端必须指定本地EE上下文编号、响应程序QP、Q_Key和任何其他消息参数。然后，该实现将来自每个源QP的消息“多路复用”到相应的EEC，并发送该消息。当消息到达目的地时，实现使用EE上下文来验证包，并将消息“解复用”到适当的QP。

可靠数据报服务使用方法（PSN、ACK/NAK协议等），如前**第9.7节“可靠服务”**所述。

### 9.7.8.1 可靠的数据报特性(支持的服务类型)

o9-100：声称支持RD模式的CA应提供能够支持RD的QP。当在RD模式下运行时，这些QP允许向相同或不同节点上的不同目的地QP的不同响应器发送顺序RD消息。当在RD模式下运行时，这些QPs应能够从相同或不同终端节点上的多个请求者接收RD消息。

o9-101：CA声称支持RD模式应提供EEC，该EEC允许多包RD消息流往返于多个QP，同时保持可靠性（消息最多从请求者发送到响应者一次，顺序正确且无损坏，否则通知上层。）

o9-102：CA声明为支持RD模式，应确保在同一EEC上发送另一条消息之前，发送方已完成RD消息（完全确认或错误完成）。

o9-103：CA声称支持RD模式，应确保在同一QP上发送另一条消息之前，已在发送方完成RD消息（完全确认或错误完成）。

o9-104：CA声称支持RD模式应满足**第9.2.1节“操作码（OpCode）”**对RD操作码编码的要求，第9.3.1节“可靠数据报扩展传输报头（RDETH）-4个字节”用于创建该报头，和**第9.6节“分组传输报头验证”**和**第9.7节“可靠服务”**用于处理RD消息的可靠传输。

o9-105：CA声称支持RD模式，在处理RD消息时，应满足**第9.9节“错误检测和处理”**的要求。

o9-106：CA声称支持RD模式，应使用**第13章：管理模式**中定义的管理设施，支持在**第12章：通信管理**中建立EEC之间的连接。

o9-107：CA声称支持RD模式应确保RD消息错误或不与底层EE上下文相关的事件（例如Q_Key或R_Key violations或RNR-NAK）不应导致EE Context关闭或阻止EE Context处理发往其他QP的其他RD消息。

o9-108：HCA声称支持RD模式应在**第11.2节“传输资源管理”**中定义和报告的范围内，为RD模式下的发送、RDMA写入、RDMA读取和原子提供支持。

o9-109：HCA声称支持RD模式应为EEC管理提供支持，如**第10.2.7节“端到端上下文”**和**第11.2.9节“EE上下文”** 所定义。

o9-110：HCA声称支持RD模式应提供对RDD域的支持，如**第10.2.8节“可靠数据报域”**、**第11.2.1.7节“分配可靠数据报域”**和**第11.2.1.8节“释放可靠数据报域”**。

实现注意：对于许多实现，EEC实际上是一般QP或EE上下文的一种特殊“模式”。对于这些实现，指定为目标EEC的上下文编号必须在可靠的数据报“EEC”模式下设置。到达未设置为“EE-context”模式的上下文（由报头中的EE-context字段标识）的可靠数据报数据包应静默丢弃。

响应程序QP上下文必须设置为支持可靠的数据报传输服务。如果可靠的数据报包到达未配置用于RD操作的QP上下文，则响应器应响应“NAK Invalid RD Request”。

此服务的一个重要区别是，与底层EE上下文无关的错误不会导致关闭该EE上下文。其中的例子是Q_Key或R_Key违规。

类似地，由与接收器的QP相关联的资源导致的接收器未就绪（RNR NAK）不会阻止EE上下文处理发往其他QP的其他消息。

在消息传输或接收期间检测到的与EE上下文相关的错误（超过重试限制等），应在WR完成中报告。

与请求者或响应者QP相关的错误应在WR completion中用通常的错误语义进行报告。有关错误的更完整讨论，请参见**第9.9节“错误检测和处理”**。

由于端到端信用机制在“无连接”类型的服务中不实用，如果请求者的发送到达而响应者的接收队列为空，则响应者应发送NAK Receiver not Ready响应。更多详情见**第9.7.5.2.8节“RNR NAK”**。

为了保留该服务所需的排序规则，并降低设计复杂度，从源QP一次发送一条关于该服务的消息，要求在下一条消息可以启动之前，在请求QP处接收每个消息确认。

### 9.7.8.2 RD操作示例

以下内容不是规范性材料，但包含在本文件中是为了澄清本主题。这些示例基于HCA实现；其他实现也是可能的。例如，TCAs可能不使用虚拟内存，可能会修改本例的其他细节。

这个实现示例维护WRs的标准发送队列。

它还维护一个Send QP的链表，在每个EEC中定义。该列表包含QP，每个QP在其发送队列的首部有一个WR，该队列将发往EEC。

为了管理数据包和消息的有序传输，该实现使用了一个调度程序。这个调度程序维护一个有数据包要发送的EEC的列表。当每个EEC到达调度程序列表的头时，发送一个或多个数据包（取决于QoS和其他不重要的因素）。

在响应端，实现示例维护一组标准的接收队列。

该实现还保留了每个EEC中的空间，以复制处理单个传入消息所需的参数。这些参数从QP（PD、CQ、Q_ Key等）和接收WQE（数据段L_Key、虚拟地址、大小等）复制。然后，EEC有足够的信息来处理整个消息，而不需要进一步参考WQE或QP，即使消息包含许多包。

#### 9.7.8.2.1 出站请求示例

1）可靠数据报的客户端将待发送消息（由WQE描述）发送到其QP的发送队列。这包括：

<span>◼ </span>描述发送消息的数据段列表（虚拟地址、L_Key和长度）;

<span>◼ </span>本地EE上下文编号

<span>◼ </span>目标QP编号

<span>◼ </span>目标Q_Key

2）当WQE到达发送队列的头（通过QP上下文的指针找到）时，EE上下文位于WQE中，QP“链接”到EECs“QP列表”用于处理（EEC包含排队和出列指针，每个QP包含指向下一个要运行的QP的链接指针。在排队指针处取QP，更新其“next”链接指向新的QP，将排队指针调整到新链接的QP）。

如果EEC当前没有发送消息，EEC也被放入调度程序中。

3） 当EEC被安排发送一条消息时，HCA通过访问EEC“QP列表”（取出列指针处的QP）头部的QP并使用QP的工作队列指针来定位WQE参数。

4） HW使用排队进程的内存保护参数（存储在QP上下文中）和虚拟地址等, 来自WQE。这允许发送队列HW直接访问发布发送消息缓冲区的每个进程的虚拟地址空间。

5） HCA硬件读取数据缓冲区，构建传输头（包括与EE上下文相关联的“分组序列”号），并将分组放到线路上。

6） 从步骤3开始重复此过程，直到发送完整个消息。“EE上下文”根据用于可靠连接QPs的相同调度算法进行服务。

7） 当消息被完全发送后，CA将等待直到消息的所有确认都已到达。

8） 由于EEC在继续之前必须等待消息ACK（一次只有一条消息未完成），因此EEC被安排了一个适当的超时，并且更新了EE上下文。

9） 当最后一个确认到达并且WQE完成时，HCA确定是否有额外的WQE被发布到当前的QP中（在EEC的QP列表的前面）。如果是这样，则检查下一个WQE以定位QP的下一条消息的EEC（这可能与当前的EEC不同）。然后CA从当前EEC的QP列表中取出QP，并将其排队到下一条消息的EEC QP列表的尾部。这与上面的步骤2类似。

10） 检查EEC的QP列表，以确定是否有任何QP对该EEC有效。

11） 该过程从步骤3重复，直到没有更多的消息可供发送。此时，EEC将从调度程序中删除并设置为“非活动”状态。

#### 9.7.8.2.2 入站请求示例

入站请求需要访问与响应者的接收队列、接收WQE和维护源信息的EE上下文相关联的QP状态。为此，报头中提供了QP和EEC。

以下列出了HCA处理传入请求包所采取的步骤。

第一个或只有一个数据包：

1）传入的请求数据包到达并被发现未损坏，并且是消息的第一个或唯一一个数据包。

2） 包头指定目的地QP号码。这是与可靠数据报服务的客户端相关联的QP。这个QP指向接收队列和WQE，但是没有任何序列号信息。包报头还包括用于访问EE上下文的“EE Context number”。序列号信息与连接到请求主机的EE上下文一起存储。

3） 将传入请求的序列号与连接到请求节点的EE上下文的状态进行比较。

4） 如果序列号和其他分组内容正确，则将目的地QP的内存保护（memory protection）和WQE条目信息临时复制到EE上下文中。这个实现是有用的，因为其他EEC可能针对相同的QP，而其他消息将以相同的QP为目标。通过将WQE和内存相关的信息复制到EEC，QP可以自由地指向后续的WQE以获取额外的消息。这也是接收WQEs可能会出现故障的原因。

5） 内存保护检查完成后，如果接收缓冲区有效，则将传入的请求写入内存（或者在RDMA读取的情况下，存储以供以后处理）。

6） CA将EEC置于调度程序上以发送ACK响应。

7） 如果数据包是“only”，则CA使用EEC的WQE和QP值的副本来完成消息，而没有额外引用QP或WQE。

中间或最后一个数据包：

1）对于来自同一消息的后续数据包，仅根据报头EEC号访问EE上下文。这允许其他eec独立地利用来自QP接收队列的其他wqe。

2） 如果序列号和其他头检查正确，则执行内存保护检查，如果接收缓冲区有效，则将传入的请求数据写入内存。

3） CA将EEC置于调度程序上以发送ACK响应。

4） 如果数据包是“最后一个”，则CA使用EEC的WQE和QP值的副本来完成消息，而没有额外引用QP或WQE。

#### 9.7.8.2.3 出站确认示例

当EEC到达调度程序队列的头部时，CA注意到必须发送一个ACK，并发送它。如果在EEC到达调度程序的头之前有多个数据包到达，这将创建一个合并的ACK。

根据ACK/NAK规则，EE上下文的最后一个有效接收序列号被发送到ACK包中。

如果操作是RDMA读取，则可能需要多个响应包。在这种情况下，EEC在每个包之后被放回调度器，直到响应的PSN达到预期的PSN。

#### 9.7.8.2.4 入站确认示例

返回的ACK响应表示请求包已成功完成。当ACK到达时，检查EE上下文并检查返回的PSN。如果这是预期的（下一个连续的）ACK，则更新预期的PSN。如果这是一条消息的最后一次确认，并且所有以前的包都被确认，那么可以使用EEC的QP和WQE信息副本来完成该消息。如果确认不是连续的，则应用常用的合并确认规则。因为一次只有一条消息是未完成的，所以在同一时间只有一条消息被确认。

对于RDMA读取，CA使用EEC复制的QP保护信息和WQE数据段信息来存储数据。

### 9.7.8.3 可靠数据报操作

处理与为可靠连接服务定义的处理非常相同。显著的区别在于在响应者处对重复包的处理，以及在请求者处重复请求的规则。

不同之处用斜体突出显示。

#### 9.7.8.3.1 发送和RDMA Write WITH IMMEDIATE DATA处理

发送和RDMA写入与可靠连接服务的处理方式相同，但端到端信用不返回给发送QP。

o9-111：CA声称对可靠数据报服务的支持应使用NAK-RNR协议来指示RD消息的接收队列溢出。

#### 9.7.8.3.2 RDMA读取处理

RDMA读取的处理方式与可靠连接服务相同。传入的请求存储在响应者的“隐藏资源”中，附加到EE上下文，内存保护信息从QP上下文访问或复制。与可靠的连接服务不同，单个QP或EEC发出的RDMA读取请求消息的数量应限制为一个。

#### 9.7.8.3.3 原子处理

原子以与可靠连接服务相同的方式处理。传入的请求存储在响应者的“隐藏资源”中，附加到EE上下文，内存保护信息从QP上下文访问或复制。与可靠的连接服务不同，单个QP或EEC的未完成原子请求数应限制为一个。

### 9.7.8.4 顺序规则

接收队列为先进先出队列。一旦排队，WQEs应按FIFO的顺序开始处理，但也可以无序完成。来自任何单一来源QP的消息应始终有序。

o9-112：CA声称支持RD模式应为RD消息的无序接收队列完成提供上层支持。

发送队列是FIFO队列。一旦排队，WQE应按其排队顺序进行发送处理。

o9-113：CA声称支持RD模式应确保在RD模式下发送队列上的WQE按顺序完成，无论它们是针对同一个或不同的端节点(endnode)上的不同目的QP，还是针对同一个目的地QP。WQEs的完成信息应始终以先进先出的顺序返回给传输消费者。

这并不意味着实现必须以任何特定的顺序将消息的数据部分放在内存中。因此，在消息至少一侧标记为完成之前，不能保证到达顺序。在消息完成之前，应用程序应预期内存缓冲区是未定义的。

请注意，在同一HCA上为同一目的地endnode或甚至是同一目的地QP的不同QP的发送队列中排队的项目不会相互排序。例如，如果目的地为目的地“X”和QP“75”的WQE“A”被发布到QP 1，并且目的地为目的地“X”和QP“75”的WQE“B”随后被发布到同一CA的QP 2，则无法保证“A”将在“B”到达目的地之前到达。

o9-114：CA声称支持RD模式，上层必须容忍不同发送QP的RD消息之间缺乏排序。也就是说，在同一HCA上为同一目的地endnode或甚至是同一目的地QP的不同QP的发送队列中排队的项目不相互排序。

### 9.7.8.5 处理QP错误——重新同步(RESYNC)

由于RD服务允许多个QP共享一个EEC，因此希望将QP错误定位到QP，不影响共享同一EEC的其余QP。为了支持这一点，RD服务允许EEC在某些错误情况下“放弃”或“暂停”QP上的操作。

如果消息在源QP错误地完成，并且QPn转换到错误状态，则该消息被“放弃”。

如果在源QP处没有完成一条消息，则该消息被“挂起”，但另一条消息在同一个EEC上启动。稍后恢复时，如果挂起的消息是发送或RDMA写操作，则必须从头开始重新启动。如果它是RDMA Read或RDMA Write，不需要立即执行，那么它可以（实现选项）在停止的地方重新启动，但必须看起来像是给响应程序的新消息。

“挂起”和重新启动仅适用于RNR NAK条件，此时响应程序暂时无法执行与特定QP相关的请求，请求者可以通过从同一EEC上的其他QP发送消息来提高性能，同时等待RNR NAK超时。

不允许请求者挂起原子操作。

为了方便起见，我们有时会说一个消息是“中止”的，用于当作“放弃”或“暂停”的意思。

“放弃”或“挂起”的概念确实要求RD服务处理当与消息相关的数据包被延迟、重复或同时发生时可能发生的一类错误。为了解决这个问题，每当消息被“放弃”或“挂起”时，都需要重新同步操作。下面的图108显示了这个问题的一个例子，其中被RNR的请求实际上是由响应程序执行的。

如果请求者只是在原始PSN上启动一条新消息，则可能会发生数据损坏。此外，请求者在稍后重新启动RNR NAK消息时，将获得两个副本。

为了解决这个问题，在任何影响QP的错误之后使用一个重新同步，但是让EEC能够继续工作。重新同步有多种用途，它使EEC两端的PSN同步，它让响应者知道先前的消息，如果不完整，将被放弃，并且它允许请求者确定响应者当前消息的状态。下面的流程图显示了请求者处的重新同步过程。

下面的梯形图说明了一个重新同步操作，以纠正图108中描述的问题。重新同步过程允许两端就一个适当的PSN达成一致，确定响应方中止消息的状态，并通知响应方中止正在进行的消息（如果是这样的话）。

RESYNC纠正的另一个问题是处理“Ghost”包。

这在一个多包消息在一个早期包上有一个错误，请求者将发送队列放入SQEr中，上层最终将发送队列返回给RTS。同时，一个fabric“事件”导致一个包被极大地延迟。

在上面的图中，“r3”极度延迟，在对相同QPs的消息进行分组处理期间到达响应器。在这种情况下，响应程序必须将“r3”视为重试的数据包。因此，至少对于发送和RDMA写入，除了调度一个ACK外，该数据包被忽略。对于RDMA读取，响应程序必须创建显式响应。如果已在进行正确的RDMA读取，则必须中断该读取并生成不同的响应。这将在请求者处创建ghost响应，并导致其RDMA读取请求超时，并重试进行恢复。对于原子，响应在请求者处也显示为ghost或意外响应。在任何一种情况下，它都将被删除，操作将恢复。

如果没有执行重新同步，消息2将以PSN=2开始。在PSN=3时接收到的“r3”将导致数据损坏问题。

o9-114.a1：对于CA声称支持RD模式，当RD模式下的消息发生QP相关错误时，请求者可以：

1）将QP和EEC转换到错误状态并完成错误消息，或

2）执行**第9.7.8.5节“处理QP错误-重新同步”**中所述的重新同步过程。

重新同步请求生成在**第9.7.3.2.2节“重新同步生成”**中描述。

o9-114.a2：对于支持RD传输服务的CA，在发送重新同步后，请求者应在重新同步PSN处等待Ack。其他响应无效。

与往常一样，应该设置AckReq位以确保响应程序调度响应。

如果**第9.7.6.1.3节“检测丢失的确认消息和超时”**中所述的没有正确响应，则重新同步应超时，并使用通常的重试次数重试。

与往常一样，请求者在从EEC发送另一条消息之前更新请求PSN。

重新同步响应实际上可能完成两条消息，前一条消息和“重新同步”消息。

### 9.7.8.6 响应器生成MSN

对于可靠的数据报业务，消息序列号（Message Sequence Number）是响应器返回给请求方的数字，表示响应器在EE上下文中完成的消息数。MSN在AETH的三个最低有效字节中携带。MSN通过通知请求者响应者已完成的消息来帮助请求者完成WQEs。

o9-114.a3：CAs中实现可靠数据报服务的响应器应在每个响应包的AETH中返回一个MSN。

o9-114.a4：使用可靠数据报服务的CA响应程序应将其MSN值初始化为零。一旦成功完成对新的有效请求消息的处理，响应器应增加其MSN。对于重复请求，不应增加MSN。递增的MSN应在RDMA读取或原子响应的最后一个或唯一一个包中返回。

#### 9.7.8.6.1 请求者接收新MSN时的行为

请求者可以使用响应包中存在的新MSN值作为完成消息的信号。

对“重新同步”消息的响应中的MSN也可用于确定前一消息的完成状态：

<span>◼ </span>如果由于先前的重试操作，上一条消息实际上已完成，则MSN将比NAK响应中返回的最后一个值高两个。

<span>   </span><span>✸ </span>如果前一条消息是Send或RDMA Write，则应该正常完成（这意味着它最终没有被放弃或挂起）。

<span>   </span><span>✸ </span>如果前一条消息是RDMA读取，则请求者没有获得返回数据，因此必须根据错误类型暂停或放弃消息。

<span>   </span><span>✸ </span>如果前一条消息是原子的，则必须错误地完成，附加信息“响应器处已知完成”可能返回到上层。

<span>◼ </span>如果MSN如预期（比上一个值大一个），则应适当处理前一条消息：

<span>◼ </span>如果被放弃，则错误地完成，消息在响应程序中“已知不完整”的附加信息；

<span>◼ </span>如果发送或RDMA Write with immediate，则未启动，稍后重试

<span>◼ </span>如果它是RDMA读或RDMA写，且不立即作为新消息重新启动，则为不完整

如果MSN是任何其他值，EEC应进入错误状态。

## 9.7.9 XRC

### 9.7.9.1 简介

XRC可显著节省在大型集群中建立all to all连接所需的QP数量。

多核处理器的既定趋势导致典型IB连接集群的每个终端节点上通常运行的进程数量直接增加。如今，多核节点系统非常普遍，在不久的将来，每个节点的路径图显示的核数甚至更多。

对于可靠连接（RC）传输服务，每个终端节点实现完整进程到进程连接所需的QP数量等于N*p*p（其中N是集群中的节点数，p是每个节点的进程数）。随着进程的数量与每个系统的内核数量一起增长，RC QP（及其相关的内存资源）的数量开始变得具有重要的影响。

XRC在几个方面不同于RD，但它首先消除了RD传输服务的最大限制：即每个EE上下文支持的单个未完成消息（太少了）。使用XRC，对于XRC QP，线路上未处理消息的数量没有限制。为了实现这一点，XRC QP与请求方的常规RC QP类似。对于XRC，SQ和EE上下文（如RD）之间没有动态关联。这意味着发起端(initiator)的XRC QP（表示为XRC INI QP）通常是逐进程创建的，并且静态地（通过连接上下文）绑定到单个目标节点。

由于XRC在响应端的操作方式，所需QP总数会节省（变少）。响应程序的连接上下文（表示为XRC TGT QP）允许请求程序进程发往针对多个目标QP（表示为XRC SRQ）的消息，这些目标QP属于目标节点上的多个进程。因此，对于单个（XRC INI）QP，节点中的单个进程可以与一个远程节点上的所有进程通信，从而将完全连接所需的总QP的数量减少p倍（与使用RC QP时相比——N*p*p --> N*p）。

The savings in the overall number of required QPs occurs because of the way XRC operates on the responder side. The responder connection context (denoted as XRC TGT QP) allows the requester process to send messages targeting multiple destination QPs (denoted XRC SRQs) which belong to the multiple processes on the destination node. So with a single (XRC INI) QP a process in one node can communicate with ALL processes on one remote node thus reducing by a factor of p the number of overall QPs required for full connectivity (as compared to when RC QPs are used).

XRC SRQs是目标节点每个进程的接收队列，可以通过XRC TGT QPs从多个远程终端节点接收消息。它们在某种程度上等同于RD QPs中的接收队列，因此每个进程只需要一个队列，就可以从集群中任何节点上的任何进程接收消息。这种操作模式要求请求方端（XRC INI QP）指定每个已发布请求消息的目标XRC SRQ。如第9.7.9节“XRC”所述，该信息通过新的扩展传输头传输到线路上。

与RD QP仅限于在其相同的可靠数据报域（RDD）中与RD EE上下文一起使用类似的方式，XRC传输服务实现了一个用于相同目的的等效XRC域机制。XRC TGT QPs只能用作访问在同一XRC域上设置的XRC SRQ的管道。

由于XRC SRQ的共享特性（接收WQE可以从多个XRC TGT QP中获取），因此不能在ACK包上携带端到端信用，而是使用无效的信用代码（类似于常规SRQ）。

如上所述，可以观察到，XRC在请求端与RC类似，在响应端与RD类似，由于这种不对称性，XRC传输服务中的传输对象具有一些独特的特征，即：

<span>◼ </span>XRC INI QP类似于常规RC QP，但没有响应端。

<span>◼ </span>XRC TGT QPs与RD EEC类似，但没有请求方。

<span>◼ </span>XRC SRQ与RD QP类似，但没有请求方。

值得注意的是，由于这种不对称性，XRC通过单个XRC INI/TGT对（pair）进行通信是一种方式。

XRC的另一个方面是，由于在响应端XRC SRQ没有SQs，因此不包括窗口绑定、快速注册和本地失效等本地操作，并且需要在需要时在辅助RC QP上执行。XRC也不支持类型2窗口。

从上面的描述可以很容易地计算出一个由N个节点组成、每个节点有p个进程的群集上实现完全连接需要多少个XRC传输对象（每个节点）：

<span>◼ </span>每个过程需要N个XRC INI QPs，每一个都可用于与每个远程节点上的所有进程通信。每个节点需要整体N*p XRC INI QP。

<span>◼ </span>每个进程需要一个XRC SRQ，允许它从集群中的任何其他进程接收消息。每个节点需要总体p XRC SRQ。

<span>◼ </span>假设一个同质集群，其中所有N个节点都有p个进程，每个节点都有N*p个XRC TGT QP，它们是远程节点上的XRC INI QP的对应物，用于在本地节点中定位进程。

所以每个节点的队列总数是：N*p XRC INI QPs，p XRC SRQ和N*p XRC TGT QPs。

### 9.7.9.2 XRC数据包格式规则

o9-114.a5：单个XRC消息的所有数据包应携带相同的XRCETH。

o9-114.a6：响应器应验证由第一个/唯一入站包标识的XRCSRQ的XRC域与XRC TGT QP的XRC域相同。

响应器可以验证由中间/最后一个分组标识的XRCSRQ是否与消息中所有先前分组相同。

o9-114.a7：响应器应使用XRC包识别的XRCSRQ的PD（而不是XRC TGT QP的PD）。

o9-114.a8：如果消息需要接收WQE，则响应器应从消息所指的XRCSRQ的RQ中获取。

o9-114.a9：如果要生成消息的完成，响应器应使用XRC包标识的XRCSRQ中的CQ。

o9-114.a10：XRC ACK数据包中的E2E信用（MSN字段）应设置为“无效”。

# 9.8 不可靠服务

IBA定义了两种不可靠服务：不可靠连接（SEND、RDMA WRITE）和不可靠数据报（SEND Only）。这些服务具有以下特点：

1）请求者不会收到消息接收的确认

2）没有数据包顺序保证

3）响应程序正常验证传入的数据包（验证适当的报头字段、CRC检查）。损坏的数据包可能会被静默丢弃，从而导致消息被丢弃。

4）当检测到传入数据包（如丢弃/无序的数据包）中的错误时，响应程序不会停止，而是继续接收传入的数据包。

5） 一旦响应器以正确的顺序接收到完整的消息，所有数据已提交到本地故障区，并且所有适当的有效性检查（包括变量和不变的CRC检查）都已完成，则认为操作完成。对于不可靠的连接服务，已完成消息的定义在第9.8.2.2.7节中给出。

6）一旦“最后一个”或“唯一”数据包提交到fabric，请求者认为消息操作完成。

## 9.8.1 验证和执行请求

本节适用于不可靠连接和不可靠数据报服务。如果服务之间存在差异，则应注意这些差异。这两种服务之间的主要区别在于，不可靠数据报服务仅限于单包消息，而不可靠连接服务则没有此限制。此外，不可靠数据报服务仅限于使用Send功能，进一步简化了请求验证过程。

下面描述对响应程序的要求，以验证入站请求包。

C9-165：响应器应验证报头的各个字段，以验证包的完整性。该验证过程在**第9.6节“分组传输头验证”**中有详细说明。包含无效字段的数据包将被响应程序静默丢弃。

C9-166：对于使用不可靠连接服务的HCA，应检查PSN以检测无序分组。通过检查PSN，响应程序可以确定该包是新请求还是无效包。有关该检查的说明，请参见**第9.8.2.2.1节“响应器-验证PSN”**。

o9-115：如果TCA实现了不可靠的连接业务，则应检查PSN以检测无序分组。通过检查PSN，响应程序可以确定该包是新请求还是无效包。有关该检查的说明，请参见**第9.8.2.2.1节“响应器-验证PSN”**。

C9-167：对于使用不可靠连接服务的HCA，响应器应检查分组操作码，以确定分组操作码序列是否有效。此检查不适用于不可靠的数据报，因为该服务仅限于单个分组消息，因此操作码序列的概念不适用。

o9-116：如果TCA实现不可靠的连接业务，响应器应检查分组操作码，以确定分组操作码序列是否有效。此检查不适用于不可靠的数据报，因为该服务仅限于单个分组消息，因此操作码序列的概念不适用。

C9-168：响应器应检查分组操作码，以确定该接收队列是否支持所请求的操作。

C9-169：响应器应验证其是否有足够的可用资源来接收消息。必要的资源包括一个有效的接收WQE（对于带有立即数据的SEND或RDMA写入），对于SEND请求，还有足够的缓冲区空间来接收请求。

C9-170：对于使用不可靠连接服务的HCA响应程序，如果请求是RDMA写入操作，则响应程序应检查R_Key。如果发现包是有效的，有序的，并且有足够的资源可用，它将由响应程序执行。在执行过程中，响应程序可能会遇到本地错误。

o9-117：如果TCA响应器实现了不可靠的连接服务，并且如果它支持RDMA操作，则其行为如下。如果入站请求是RDMA写入操作，则响应程序应检查R_Key。如果发现包是有效的，有序的，并且有足够的资源可用，它将由响应程序执行。在执行过程中，响应程序可能会遇到本地错误。

C9-171：对于使用不可靠连接或不可靠数据报服务的HCA响应程序，或使用不可靠数据报服务的TCA响应程序，在验证入站请求包时，响应程序应遵循图114所示的顺序。

o9-118：如果TCA响应器实现了不可靠的连接服务，则响应器在验证入站请求包时应遵循图114所示的顺序。

对于不可靠的连接服务，这些要求将在**第9.8.2.2节“响应器行为”**中进行详细讨论。不可靠数据报服务的包验证在**第9.8.3.2节“响应程序行为”**中讨论。

## 9.8.2 不可靠连接

不可靠连接由两个QP之间的一对一通信组成。数据包从一个QP发送到另一个QP，但是目的QP不生成确认。主要特点是没有向请求者提供交付保证。但是，响应程序可以检测数据损坏和无序数据包。

表52总结了不可靠连接服务的特征。

### 9.8.2.1 请求者行为

本节规定了请求者在为不可靠连接服务生成请求包时所需的行为。

#### 9.8.2.1.1 请求程序—生成PSN

C9-172：对于使用不可靠连接服务的HCA请求者，请求者必须在每个请求包的BTH:PSN字段中放置一个值，称为当前PSN。

o9-119：如果TCA请求者实现了不可靠连接服务，请求者必须在每个请求报文的BTH:PSN字段中填入一个值，称为当前PSN。

在建立连接期间，传输层的客户端必须将下一个PSN编程为0到16777215之间的任何值。

C9-173：对于使用不可靠连接服务的HCA请求者，由传输层客户端编程的初始PSN应作为请求者生成的第一个请求报文中的BTH:PSN。

o9-120：如果TCA实现了不可靠连接服务，则由传输层客户端编程的初始PSN应作为请求者生成的第一个请求报文中的BTH:PSN。

C9-174：对于使用不可靠连接服务的HCA，传输层只有在发送队列处于合适的状态以传输请求包时，才应该修改（更新）PSN。例如，对于HCA，当队列对处于INITIALIZED状态时，传输层不会更新下一个PSN。

o9-121：如果TCA实现了不可靠连接业务，传输层只有在发送队列处于合适的状态以发送请求包时，才会修改（更新）PSN。

C9-175：对于使用不可靠连接服务的HCA，请求方生成的每个请求报文都必须有一个PSN值，该PSN值是前一个请求报文的PSN值的增量（模2^24）。

o9-122：如果TCA实现了不可靠连接业务，则请求方生成的每个请求报文的PSN值必须是前一个请求报文的PSN值的乘积，取模2^24。

#### 9.8.2.1.2 请求者—生成操作码

请求者生成的操作码必须符合如下所示的操作码一览表。

C9-176：对于使用不可靠连接服务的HCA请求者，请求者必须生成符合有效操作码序列表的分组操作码，如表54有效操作码序列表所示。生成请求包时BTH:OpCode应该如表38操作码字段所示。

o9-123：如果TCA请求者实现不可靠连接服务，请求者必须生成符合有效操作码序列表的分组操作码，如表54有效操作码序列表所示。生成请求包时BTH:OpCode应该如表38操作码字段所示。

#### 9.8.2.1.3 请求者—生成有效载荷

请求者应根据操作码生成有效载荷长度，如下所示：

C9-177：对于使用不可靠连接服务的HCA，如果操作码指定“第一”或“中间”包，则包有效负载长度必须是完整的PMTU大小。

C9-178：对于使用不可靠连接服务的HCA，如果操作码指定“仅”数据包，则数据包有效负载长度的大小必须介于0和PMTU字节之间。因此，创建零字节长度传输的唯一方法是使用单个分组消息（Only）。

C9-179：对于使用不可靠连接服务的HCA，如果操作码指定了“最后”数据包，则数据包有效负载长度的大小必须介于1和PMTU字节之间。

o9-124：如果TCA实现不可靠连接服务，则应符合前面三个HCA对操作码的要求。

#### 9.8.2.1.4 完成消息发送或RDMA写入

C9-180：对于使用不可靠连接服务的HCA请求者，当出现以下任一情况时，请求者应认为消息发送（或RDMA WRITE）完成：请求者已提交最后一个数据包的VCRC字段的最后一个字节发送到wire线路（并且未检测到与消息传输相关的本地错误），或者请求者检测到与消息传输相关的本地错误，导致请求者终止发送请求。

o9-125：如果TCA请求程序实现了不可靠的连接服务，则当出现以下任一情况时，请求者应认为消息发送（或RDMA写入）完成：请求者已将最后一个数据包的VCRC字段的最后一个字节提交到线路上（且未检测到与消息传输相关的本地错误），或请求程序检测到与消息传输相关联的本地错误，该错误导致请求程序终止发送请求。

请注意，在请求者完成send WQE时，响应者的内存状态是未知的。同样，如果请求者在发送请求包时检测到本地错误，则响应者内存的状态是未知的。

### 9.8.2.2 响应器行为

本节规定了响应器在接收入站请求时所需的行为。

#### 9.8.2.2.1 响应器—验证PSN

响应器保持一个预期的PSN值（ePSN），用于检测多包请求消息中的丢失包和检测丢弃的消息。由于对于UC业务，每个入站请求包的PSN都是连续且单调递增的，PSN序列中的中断表示请求包丢失或丢失。

C9-181：对于使用不可靠连接服务的HCA响应器，响应器应保持预期的PSN值（ePSN）。这是响应程序希望在下一个入站请求包的BTH中找到的PSN。

o9-126：TCA响应器执行不可靠连接服务时，响应器应保持预期的PSN值（ePSN）。这是响应程序希望在下一个入站请求包的BTH中找到的PSN。

响应器的预期PSN可以在连接建立时由传输的客户端初始化为0到16777215之间的任何值。然而，由于响应器将接受操作码为“first”或“only”的任何有效分组，并使用该分组中包含的PSN值作为其期望PSN，因此不需要对响应器的初始期望PSN进行编程。有关在连接建立时加载预期PSN的机制的完整描述，请参阅**第12章：通信管理**。

只有当队列处于初始化状态时，客户端才能设置初始预期PSN。传输层可能会忽略客户端在PSN处于任何其他状态时设置PSN的尝试。

C9-182：对于使用不可靠连接服务的HCA，只有当接收队列处于接收入站请求包的适当状态时，传输层才应修改（更新）其预期PSN。例如，对于HCA，当队列对处于初始化状态时，传输层不会修改PSN。

o9-127：如果TCA实现了不可靠的连接服务，则只有当接收队列处于接收入站请求包的适当状态时，传输层才应修改（更新）其预期的PSN。例如，对于HCA，当队列对处于初始化状态时，传输层不会修改PSN。

C9-183：对于使用不可靠连接服务的HCA响应者，如果入站请求报文的PSN与响应者当前的ePSN不完全匹配，则应声明入站请求报文乱序。

o9-128：如果TCA响应器实现了不可靠的连接服务，如果一个入站请求包的PSN与响应器当前的ePSN不完全匹配，则该入站请求包将被声明为乱序。

C9-184：使用不可靠连接服务的HCA响应器应如下所示。如果在包验证期间，发现一个入站请求包的操作码为“first”或“only”，则响应器应接受该包，并接受该请求消息的PSN作为其新的ePSN，而不管入站包是否有故障。无论之前的ePSN值如何，都应进行此操作。

o9-129：实现不可靠连接服务的TCA响应器应表现如下。如果在包验证期间，发现一个入站请求包的操作码为“first”或“only”，则响应器应接受该包，并接受该请求消息的PSN作为其新的ePSN，而不管入站包是否有故障。无论之前的ePSN值如何，都应进行此操作。

C9-185：对于使用不可靠连接服务的HCA响应器，在执行入站请求之前，响应器应通过比较入站BTH中的PSN与响应器的预期PSN来检查PSN。响应器用于计算其下一个预期PSN的规则应与请求方计算要插入下一个请求包的PSN值时使用的规则相同。这些规则在**第9.8.2.1.1节“请求程序—生成PSN”**中给出。

o9-130：对于使用不可靠连接服务的HCA响应器，在执行入站请求之前，响应器应通过比较入站BTH中的PSN与响应器预期的PSN来检查PSN。

响应器用于计算其下一个预期PSN的规则应与请求方计算要插入下一个请求包的PSN值时使用的规则相同。这些规则在**第9.8.2.1.1节“请求程序—生成PSN”**中给出。

o9-131：如果入站消息的PSN与响应程序的ePSN不匹配，则响应程序可以通知其客户端存在一个或多个丢失的消息。响应程序通知其客户端的机制不在本规范的范围内。

C9-186：对于使用不可靠连接服务的HCA响应者，如果检测到乱序包时正在处理多包消息，则应静默丢弃当前消息。然后响应方等待新消息的第一个数据包。当前包（乱序包）可能是新消息的第一个包。如果是，应作为新的消息处理。

o9-132：如果TCA响应程序实现不可靠的连接服务，如果在检测到异常分组时正在处理多分组消息，则应默默地丢弃当前消息。然后响应程序等待新消息的第一个包。可以，当前分组（无序分组）是新消息的第一分组。如果是，应将其视为新的消息。

“新消息”由一个入站请求包表示，该请求包的操作码在位于BTH中会有“first”或“only”的标记。

“当前消息”是指自最近接收到的“first”或“only”操作码以来接收的所有分组，不包括当前分组。

#### 9.8.2.2.2 响应程序-操作码序列检查

请求包必须符合有效操作码序列的列表（A request packet must fit within a schedule of valid OpCode sequences.）。OpCode序列通过检查BTH:OpCode确定。

C9-187：对于使用不可靠连接服务的HCA响应程序，响应方应检查以下项目（1）至（5）中所述的分组操作码顺序：

1） 如果这是建立连接后的第一个分组，那么分组操作码必须指示“第一”或“仅”。“中间”或“last”的操作码意味着至少丢失当前消息的第一个包，并表示无效的操作码序列。

2） 如果接收到的最后一个有效数据包具有一个操作码，指示“first”，则当前操作码必须指示“中间”或“last”。它还必须与上次有效数据包（发送、RDMA写入）中指定的操作类型匹配。当前的“first”或“only”操作码意味着至少丢失了前一个消息的最后一个包，并表示无效的操作码序列。

3） 如果接收到的最后一个有效数据包具有指示“中间”的操作码，则当前操作码必须指示“中间”或“last”。它还必须与上次有效数据包（发送或RDMA写入请求）中指定的操作类型匹配。当前的“first”或“only”操作码意味着至少丢失了前一个消息的最后一个包，并表示无效的操作码序列。

4） 如果接收到的最后一个有效数据包具有一个指示“last”的操作码，则当前操作码必须指示“first”或“only”。当前的“中间”或“last”操作码意味着至少丢失当前消息的第一个包，并表示无效的操作码序列。

5） 如果接收到的最后一个有效数据包具有一个操作码，指示“仅”，则当前操作码必须指示“第一”或“only”。当前的“中间”或“last”的操作码意味着当前消息的第一个包丢失，并表示无效的操作码序列。

o9-133：如果TCA响应程序实施不可靠的连接服务，响应方应检查上述项目（1）至（5）中所述的分组操作码序列。

在**第9.9.3节“响应器端行为”**中指定了响应程序在存在无效操作码序列时的行为。

C9-188：对于使用不可靠连接服务的HCA响应程序，如果响应程序检测到无效的操作码序列，则当前消息应被悄悄丢弃。然后响应程序等待一个新的入站请求包，其操作码为“first”或“only”；任何其他入站请求包都应被悄悄丢弃。

o9-134：如果TCA响应程序实现不可靠的连接服务，并且响应程序检测到无效的操作码序列，则当前消息应默默丢弃。然后响应程序等待一个新的入站请求包，其操作码为“first”或“only”；任何其他入站请求包都应被悄悄丢弃。

“当前消息”是指最近接收到的“第一”或“仅”操作码以来接收的所有分组，不包括当前分组。

C9-189：对于使用不可靠连接服务的HCA响应程序，如果导致无效操作码序列的当前分组具有“第一”或“仅”的操作码，则应将其视为新请求消息的第一个分组。

o9-135：如果TCA响应程序实现不可靠的连接服务，并且导致无效操作码序列的当前分组具有“第一”或“仅”的操作码，则应将其视为新请求消息的第一个分组。

有效操作码序列列表汇总如下表所示。

#### 9.8.2.2.3 响应器操作码验证

C9-190：对于UC，响应器应验证接收队列支持的请求功能（发送或RDMA写入），以及BTH:OpCode在执行请求之前验证其不是保留的操作码。

注意，在**第9.6节“分组传输头验证”**中，操作码也作为包验证的一部分进行了检查，以确保入站数据包包含对不可靠连接服务的请求。

C9-191：无效的UC请求应由响应者根据**第9.9.3节“响应器端行为”**悄无声息地丢弃。

9.8.2.2.4 响应器远程访问验证

C9-192：本合规性声明已被废弃并被C9-192.2.1取代：

C9-192.2.1：对于使用不可靠连接服务的HCA响应程序，如果入站请求是RDMA写入，并且RETH中请求的DMA长度非零，则应检查以下条件：

<span>◼ </span>RETH中的R_Key字段有效。

<span>◼ </span>虚拟地址和长度在与R_Key相关的本地定义限制内。基于RDMA的数据包长度进行LRH:PktLen字段检查。

<span>◼ </span>指定的访问类型（写入）在与R_Key相关的本地定义限制内。

<span>◼ </span>对于HCA，应根据**第10.2.3节“保护域”**中规定的条件检查保护域。

如果这些检查中的任何一个失败都将构成R_Key的违规行为。**第9.9.3节“响应器端行为”**中规定了响应器响应R_Key违规的行为。

o9-136：如果TCA响应程序实现了不可靠的连接服务和RDMA功能，则它应符合前面的HCA符合性声明。

C9-193：对于使用不可靠连接服务的HCA，对于零长度RDMA写入请求，即使请求包含立即数据，也不应检查R_Key字段。

o9-137：如果TCA响应程序实现了不可靠的连接服务和RDMA功能，则即使请求包含立即数据，也不应对零长度RDMA写入请求检查R_Key字段。

#### 9.8.2.2.5 响应器—长度验证

C9-194：对于使用不可靠连接服务的HCA响应器，应检查LRH的PktLen字段，以确认在接收WQE指定的接收缓冲区中有足够的可用空间。此检查仅适用于发送。

o9-138：TCA响应器执行不可靠连接服务时，应检查LRH的PktLen字段，以确认接收WQE指定的接收缓冲区中有足够的可用空间。此检查仅适用于发送。

还应通过将数据包与操作码进行比较来验证数据包的长度，如下所示：

C9-195：对于使用不可靠连接服务的HCA响应程序，如果UCBTH:OpCode指定“第一个”或“中间”数据包，则数据包有效负载长度必须是完整的PMTU大小。

o9-139：如果TCA响应程序实现了不可靠的连接服务，并且如果UCBTH:OpCode指定“第一个”或“中间”数据包，则数据包有效负载长度必须是完整的PMTU大小。

C9-196：对于使用不可靠连接服务的HCA响应程序，如果UCBTH:OpCode指定如果是“only”包，则包有效负载长度的大小必须介于0和PMTU字节之间。因此，创建零字节长度传输的唯一方法是使用单个分组消息。

o9-140：如果TCA响应程序实现了不可靠的连接服务，并且如果UC BTH:OpCode指定如果是“only”包，则包有效负载长度的大小必须介于0和PMTU字节之间。因此，创建零字节长度传输的唯一方法是使用单个分组消息。

C9-197：对于使用不可靠连接服务的HCA响应程序，如果UC BTH:OpCode指定“最后一个”数据包，则数据包有效负载长度的大小必须介于1和PMTU字节之间。

o9-141：如果TCA响应程序实现不可靠的连接服务，并且如果UC BTH:OpCode指定“最后一个”数据包，则数据包有效负载长度的大小必须介于1和PMTU字节之间。

C9-198：此符合性声明已过时并已删除。

o9-142：本合规声明已过时，已被删除。

C9-199：对于使用不可靠连接服务的HCA响应程序，如果BTH:OpCode字段[4:0]指定第一个或中间请求包（例如，发送第一个SEND First，或者RDMA写入中间），pad count位被验证为b00，表示不存在pad字节。如果填充计数位不为零，则操作码无效。

o9-143：如果TCA响应程序实现不可靠的连接服务，并且如果BTH:OpCode字段[4:0]指定第一个或中间的请求包（例如，发送第一个SEND First或RDMA写入中间包），pad count位被验证为b00，表示不存在pad字节。如果填充计数位非零，则操作码无效。

如果检测到数据包的长度无效，则该请求为无效请求。在这种情况下，响应器的行为在**第9.9.3.1节“响应器侧错误响应”**中有详细说明。

#### 9.8.2.2.6 响应程序—本地操作验证

由于响应程序本地的故障，例如访问本地内存时发生本地内存转换错误，有效的入站请求可能仍然无法完成。本地错误可能会导致接收队列转换到错误状态。更多详情见**第9.9.3节“响应器端行为”**。

#### 9.8.2.2.7 完成消息接收

响应程序认为给定的入站消息已成功完成，前提是：

<span>◼ </span>检测到有效消息的开头，如BTH中存在“第一个数据包”或“唯一数据包”操作码所示；

<span>◼ </span>检测到同一个有效消息的结尾，如BTH中存在“仅数据包”或“最后一个数据包操作码”所示，PSN序列中没有跳过（缺少）；

<span>◼ </span>成功、按顺序地接收到“第一个数据包”和“最后一个数据包”中间的数据包，或者已经成功地接收到“唯一的数据包”。

<span>◼ </span>无误地将消息有效载荷提交到本地故障区，以及，

<span>◼ </span>成功完成所有适当的有效性检查（包括可变和不变的CRC）。

在任何这些步骤中检测到的故障可能导致或可能不会导致相关的WQE错误地完成。在某些情况下，例如丢失的“第一个”包，响应器完全可能不使用WQE。请注意，在出现错误的情况下，无法保证响应程序内存的状态。在检测到错误之前，一个给定数据包的部分或全部可能已经提交到响应程序的内存中。

一旦成功完成入站消息接收后，响应程序将完成当前WQE。

## 9.8.3 不可靠数据报

不可靠数据报是一种通信形式，允许源QP将每条消息发送到可能存在于同一或多个目的地终端节点上的多个目的地QP中的一个。

<span>◼ </span>对于要发送的每条消息，必须向请求者提供目的地地址（见**第11.2.2.1节“创建地址句柄”**）、目的地QP、目的地Q_Key等。有关为HCA提供的参数，请参阅**第11.4.1.1节“发布发送请求/Post Send Request”**。

<span>◼ </span>响应者必须向客户提供请求者的地址、QP等。有关HCA要求的更多详细信息，请参阅**第11.4.2.1节“完成投票/Poll for Completion”**。

C9-200：源UD消息的设备应将UD消息大小限制为单个包。数据包不应大于源和目标之间的PMTU（否则将被丢弃）。

C9-201：发送和接收UD消息的设备应满足基本不可靠服务的要求（见**第9.8节“不可靠服务”**至**第9.8.1节“验证和执行请求”**）。

C9-202：发送和接收IBA UD消息的设备应符合**第9.9节“错误检测和处理”**的要求。

### 9.8.3.1 请求者行为

本节规定了请求者在生成请求包时所需的行为。

C9-203：发送UD消息的设备在发送UD消息的同时应满足**第9.8.3.1.1节“生成PSN”**和**第9.8.3.1.2节“完成的消息发送”**的要求。

#### 9.8.3.1.1 生成PSN

C9-204：对于UD传输服务上的每个请求消息，请求者应生成PSN，其增量为前一请求包的PSN值的加“1”（模2^24）。QP0和QP1不需要增加PSN。

当发送队列处于初始化状态时，初始PSN值应由传输的客户端加载，并且可以初始化为任何24位值。而在发送请求包的过程中，只有当发送队列处于准备发送(Ready to Send )状态时，传输层才能修改（更新）PSN。

#### 9.8.3.1.2 完成消息发送

请求者应在以下情况下认为消息发送完成：

<span>◼ </span>将数据包的VCRC字段的最后一个字节提交到线路wire上，并且未检测到与消息传输相关的本地错误。

<span>◼ </span>检测到请求者终止与请求相关联的本地传输错误。

请注意，在请求者完成send WQE时，响应者的内存状态是未知的。同样，如果请求者在发送请求包时检测到本地错误，则响应者内存的状态是未知的。

### 9.8.3.2 响应程序行为

本节指定响应程序在接收入站请求时所需的行为。

#### 9.8.3.2.1 响应器—验证PSN

o9-144：对于UD传输服务，响应器可以忽略PSN字段。

一些应用（例如基于多播的媒体流）可以从让响应器验证PSN序列从检测无序分组中获得益处。允许响应器实现这样做，但不在IBA规范的范围之内。

#### 9.8.3.2.2 响应器—长度验证

C9-205：在执行请求之前，响应器应按照**第9.8.3.2.2节“响应器-长度验证”**中所述验证LRH和BTH的PadCnt的包长度字段。

应验证以下特性：

<span>◼ </span>应检查长度字段，以确认接收WQE指定的接收缓冲区中有足够的可用空间。

<span>◼ </span>数据包有效负载长度必须介于0和PMTU字节之间（包括0和PMTU字节）。

如果检测到一个数据包的长度无效，则该请求应为无效请求，并且应按照**第9.9.3节“响应器端行为”**的规定，由响应者静默丢弃。然后，响应程序等待一个新的请求包。

#### 9.8.3.2.3 响应器操作码验证

C9-206：对于UD，响应器应验证BTH:OpCode请求的功能（SEND）受此接收队列支持，在执行请求之前确保操作码字段不是保留值，否则请求无效。

C9-207：如果UD接收队列没有保存入站发送请求的条目，则该请求无效。

如果请求无效，响应者应按照**第9.9.3节“响应器端行为”**的规定，静默地放弃请求。

#### 9.8.3.2.4 响应器—本地操作验证

由于响应程序的本地故障，例如访问本地内存时的本地内存转换错误，有效的入站请求可能仍然无法完成。本地错误可能会导致接收队列转换到错误状态。更多详情见**第9.9.3节“响应器端行为”**。

#### 9.8.3.2.5 完成消息接收

响应程序认为给定的入站消息已成功完成，前提是：

<span>◼ </span>无误地将消息有效载荷提交到本地故障区

<span>◼ </span>成功完成所有适当的有效性检查（包括可变和不变CRC）。

在任何这些步骤中检测到的故障可能导致或可能不会导致相关的WQE错误地完成。在某些情况下，例如操作码或长度错误，响应程序将不使用WQE。请注意，在出现错误的情况下，无法保证响应程序内存的状态。在检测到错误之前，一个给定数据包的部分或全部可能已经提交到响应程序的内存中。成功完成入站消息接收后，响应程序将完成当前WQE。

## 9.8.4 原始数据报

前几节描述了IBA规范定义的不同传输协议。除此之外，IBA允许IBA子网携带其他协议。封装这些流量的IBA数据报称为原始数据报。

IBA定义了两种不同的方法来支持原始数据报。在**第7.7.5节“链路下一个报头（LNH）-2位”**中的2个位用于指定LRH之后的下一个报头。下表描述了描述原始数据报的两种LNH编码。

对原始数据报进行编码的第一种方法（LNH:01）仅用于IPv6数据报。包有效载荷可以包含IETF对IPv6报头的“next header”字段编码定义的任何传输层或网络层协议，不包括指示下一报头是IBA传输报头的其他任何编码。

C9-208：CAs不应生成出站数据包，并将丢弃那些LRH字段指示其为原始数据报但其IPv6“下一个报头”表示IBA传输的任何入站数据包。TCAs可以选择任何方式报告此错误。

对原始数据报进行编码的第二种方法（LNH:00）使用IBA定义的原始报头（RWH，raw header）。RWH包含16位Ethertype字段——RWH在第5.3节“原始数据包格式”中进行了描述。RWH用于定义封装在包的有效载荷中的协议头。一般来说，第二种方法用于允许IPv6下一个报头不支持的协议—应该注意，任何一种方法都可以用于传输IPv6数据报。

o9-145：如果CA实现原始数据报支持，则原始数据报的数据包有效负载必须始终为模4大小，因为LRH数据包长度以4字节增量描述长度。如果封装的有效载荷大小不是4字节的倍数，则应将有效载荷填充到4字节的倍数。

o9-146：如果CA实现原始数据报支持，则用于注入和使用原始数据报的QP应在本地管理，即QP与给定原始数据报服务的关联依赖于实现。

o9-147：如果CA实现原始数据报支持，它可能支持一个或多个QPs来执行原始数据报操作。

### 9.8.4.1 原始数据报数据包大小

IBA MTU定义IBA传输数据有效载荷的最大大小。IBA数据包的最大大小为MTU+124字节（见**第7.7.8节“数据包长度（PKTLEN）-11位”**）。

o9-148：如果CA实现了对原始数据报支持，并且由于原始数据报不使用IBA传输头，原始数据报的数据包有效载荷可能大于支持的MTU（参见图116原始数据报）。下表总结了两种原始数据报类型中每种的最大数据包有效载荷（以及LRH PktLen字段的相应值）。

# 9.9 错误检测和处理

IBA使用分层错误管理体系结构（LEMA，layered error management architecture）方法。每个级别负责在将包或消息传递到堆栈中的下一层之前检测和管理适合该层的错误。

因此，传输层响应特定于传输层的错误，包括分组报头中的错误和正确传输消息的失败错误。

在传输层中检测到的错误将报告给传输层的客户端。在本节中，传输层与其客户端之间的接口概念上显示为发送或接收队列。在HCA的情况下，传输层通过向完成队列（CQ）上的完成队列条目（CQE）写入完成代码来向其客户端指示错误。与往常一样，TCA可以自由地报告错误（或不报告），只要他们认为合适。

为了简化讨论，分别讨论请求端和响应端的错误行为。这会导致下面描述请求方和响应方错误的总结表之间出现少量重复。具体地说，当响应程序检测到错误并向请求者报告时，会发生重叠。然而，这些重叠区域严格限于可靠的服务类别。

<center>Figure 117 Requester / Responder Error Detection 
</center>

请求者向其客户端报告的错误分为两类。第一种是本地检测到的错误：即仅由请求方检测到的错误。本地检测到的错误的一个例子是请求者在发送请求期间访问其本地内存时检测到的保护故障。

第二类是远程检测到的错误，这些错误是由响应程序检测到并通过响应包中的NAK综合征/Syndrome报告给请求者的那些错误。远程检测到的错误仅适用于可靠的服务类别（可靠的连接和可靠的数据报）。

请求端存在两类错误（本地和远程检测到），而响应端只有本地检测到的错误。

为了响应本地检测到的错误，响应方可能被要求向请求方报告错误，或者可能被要求向其本地客户端报告错误，或者两者都报告，或者两者都不报告。向谁报告错误取决于服务类别（可靠与不可靠），以及检测到的特定错误。

下面几节的重点是根据如何向传输层的客户端报告错误，以及发送（接收）队列在检测到错误后必须表现出的行为，对所有错误进行分类。因此，这一部分不仅根据检测到错误的位置，而且根据向谁报告错误进行分类。

## 9.9.1 向verbs层报告错误

对于HCA，IBA软件接口定义了可通过verbs层报告的三种类型的错误。这些被称为即时错误、完成错误和异步错误。在这三种类型中，传输层只能报告完成错误或异步错误。这是因为在WQE被发布到传输层之前，verbs层会检测到即时错误。表58:“传输层检测到的软件错误类型”总结了IBA传输层可以检测并向verbs层报告的错误类型。有关这些错误类型的更多信息，请参阅**第10.10.2节“错误处理机制”**。

完成错误分为两类：接口检查和处理错误。接口检查是在数据被放入链路之前检测到的提供给信道接口的信息中的错误。处理错误是在通道接口处理工作请求期间遇到的错误。

## 9.9.2 请求方端错误行为

如上所述，请求方检测来自本地或远程的错误。

### 9.9.2.1 请求端错误检测—本地检测到的错误

本地检测到的错误反映了请求方信道接口中出现的错误情况(condition)、响应方的响应丢失（超时）、或序列错误或RNR NAK重试过多。

在请求方本地检测到的错误可能在请求包生成期间、响应包处理过程中或由于超时而发生。

C9-209：对于使用RC、UC或UD服务的HCA请求者和使用UD服务的TCA请求者，请求者的行为应如下所示。对于在传输请求包期间检测到的本地检测到的传输错误，CA应停止对受影响QP的传输，存储与该错误相关的状态直到之前任何未完成的WQE完成，并最终完成受影响的WQE。如果错误类型需要，则应将QP置于错误状态。

o9-149：若TCA请求者实现可靠连接或不可靠连接服务，或XRC服务，则其行为如下。对于在传输请求包期间检测到的本地检测到的传输错误，CA应停止对受影响QP的传输，存储与该错误相关的状态直到之前任何未完成的WQE完成，并最终完成受影响的WQE。如果错误类型需要，则应将QP置于错误状态。

o9-150：如果一个CA请求者实现可靠的数据报或XRC服务，它应该表现如下。对于在传输请求包期间检测到的本地检测到的传输错误，CA应停止对受影响的EEC的传输，应存储与该错误相关的状态直到之前任何未完成的WQE完成，并最终完成受影响的WQE。如果错误类型需要，EEC应进入错误状态。

这是为了维持WQEs的有序完成，并确保在发生错误的WQE正确地报告错误。

#### 9.9.2.1.1 请求者错误重试计数器

C9-210：对于使用可靠连接服务的HCA，为了检测过度重试，请求者应维护RNR NAK和错误重试计数器，这些计数器执行**第9.9.2.1.1节“请求者错误重试计数器”**中描述的逻辑功能。

o9-151：如果CA请求方实现可靠的数据报服务或XRC服务，或者如果TCA请求方实现可靠连接服务，则请求方的行为应如下所示。为了检测过度重试，请求者应维护RNR NAK和错误重试计数器，这些计数器执行**第9.9.2.1.1节“请求者错误重试计数器”**中描述的逻辑功能。

实现可以以它们选择的任何方式实现这些重试计数器，但是为了清楚起见，这里将它们描述为倒数计数器（倒计时），初始化为终止操作和创建最终完成错误之前允许的重试次数。有关HCA中这些计数器的编程，请参阅**第10.2.4.3节“修改队列对属性”**。

每次响应程序返回RNR NAK时，RNR NAK重试计数器都会递减。如果请求者的RNR NAK retry计数器为零，并且接收到RNR NAK数据包，则发生RNR NAK retry错误。每一个应答计数器都被清除。以下情况的一个例外情况是，如果RNR NAK retry计数器设置为7。此值表示无限重试，计数器不递减。

每次由于本地ACK超时、NAK序列错误或隐含的NAK，请求者必须重试数据包时，错误重试计数器都会递减。如果请求者的重试计数器减少到零，则可以实现如下两件事之一。

如果不支持自动路径迁移，或已经完成，则在完成时应报告“传输重试计数器超出”错误。

o9-152：如果CA支持自动路径迁移，那么在潜在的可恢复错误及其重试之后，请求者可以迁移连接或EE上下文，并在最终报告错误完成之前再次执行错误重试。更多信息，请参见**第17.2.8节“自动路径迁移”**。

每次正确确认数据包时，应重新加载重试计数器。

#### 9.9.2.2 请求方端错误检测—远程检测到的错误

当响应程序向请求方报告错误时，会发生远程检测到的错误。远程检测到的错误对于可靠的服务类别是唯一的。

远程检测到的错误通过应答消息中携带的NAK代码报告。但是，并非所有的NAK代码都会导致向请求者的客户端报告错误。

在可能的NAK代码中，有两个（NAK Sequence Error和NAK-RNR）表示请求者应该自动重试的操作。

除NAK Sequence Error和NAK-RNR以外的NAK代码表示必须立即向请求者的客户端报告且不能重试的故障。

### 9.9.2.3 摘要—请求方错误行为

表59列出了请求方检测到的所有错误，包括本地和远程检测到的错误。如果请求者在本地检测到错误，则标记为“Syndrome”的列包含“local detected error”的标识。如果响应程序远程检测到错误，此列将列出响应程序返回的NAK综合征/Syndrome。Fault behavior类指定请求者向其客户端报告错误所采取的操作。

以下第9.9.2.4.1节至第9.9.2.4.5节规定了每种故障行为等级。为了方便起见，下面的表60“请求者错误行为类摘要/Summary”中总结了六种可能的故障行为类别。

C9-211：本合规声明已过时，已被C9-211.1.1取代：。

C9-211.1.1：对于已实现的传输服务子集，请求者应符合表59中规定的错误行为。此外，请求者的发送队列的行为应符合表60所示的每个故障行为类和每个请求者类故障描述的规定。

### 9.9.2.4 请求方错误响应

请求方必须实现五组不同的错误响应行为。上面的表59显示了针对任何给定错误执行的行为。本节指定错误响应行为。

#### 9.9.2.4.1 请求程序A类错误行为

A类错误是指传输层通过重试机制可恢复的错误。如果重试成功，则不会对传输层的客户端（例如verbs层）产生可见的影响。

A类错误指的是包序列错误、隐含NAK序列错误、本地Ack超时错误和RNR NAK。分组序列错误和RNR-NAK都会被远程检测到。请求者在本地检测到本地Ack超时错误和隐含的NAK序列错误。

C9-212：对于使用可靠连接服务的HCA，每次传输重试请求程序A类错误时，它应减少重试计数器。有一个与包序列错误和本地Ack超时错误相关联的重试计数器，以及与RNR NAK相关联的另一个重试计数器。只要重试计数没有过期（耗尽），传输就可以继续重试这些错误。重试这些错误的协议见**第9.7节“可靠服务”**。

o9-153：若TCA请求方实现可靠连接服务，或CA请求方实现可靠数据报服务或XRC服务，则请求方每次重试请求程序A类错误时，应递减一个重试计数器。有一个与包序列错误和本地Ack超时错误相关联的重试计数器，以及与RNR NAKk相关联的另一个重试计数器。只要重试计数没有过期，传输就可以继续重试这些错误。重试这些错误的协议见**第9.7节“可靠服务”**。

C9-213：对于使用可靠连接服务的HCA请求者，由于请求程序A类错误是可恢复的，除非重试计数过期，否则请求者不应向传输的客户端报告这些错误。

o9-154：如果TCA请求程序实现可靠连接服务，或者如果CA请求程序实现可靠的数据报服务或XRC服务，由于请求程序A类错误是可恢复的，除非重试计数过期，否则请求者不应向传输的客户端报告这些错误。

请参阅**第10.10.2.2节“完成错误”**，了解重试计数过期后如何报告HCA的错误。

#### 9.9.2.4.2 请求者B类错误行为

C9-214：为了响应请求者B类错误，对于可靠数据报以外的服务，请求者应错误地完成当前WQE，将发送队列转换为错误状态，并将任何后续发布到发送队列的WQE标记为flushed（刷新状态）。

o9-154.a1：对于实现可靠数据报服务的CA，请求者在响应请求者B类错误时，应执行**第9.7.8.5节“处理QP错误-重新同步”**中所述的操作。如果按照所述的重新同步过程，消息仍有错误，请求者应错误地完成当前WQE，将发送队列转换为错误状态，并将任何随后发布到发送队列的WQE标记为flushed（刷新状态）。

对于HCA，错误以“完成-处理类型（Completion - Processing type）”发布，并具有适当的错误类型（更多详细信息，请参阅**第10.10.2.2节“完成错误”**）。

传输层应将队列转换到错误状态，以防止在客户端（例如HCA的verbs层）在发现错误之前向发送队列发送更多的WQE时可能发生的争用情况。这与图126 QP/EE上下文状态图所示的发送队列状态图一致。

最后，在失败的WQE后面的发送队列中的所有WQE都通过状态“completed-flush in error”标记为已完成，。

对于RC或XRC模式，请注意，其中一些请求可能已由请求者提交到线路wire，甚至可能已由响应者执行和完成。无法阻止这种情况，因为响应程序可能在请求程序检测到本地错误之前执行了请求。因此，响应端的本地状态必须被认为是未知的。

对于可靠的数据报服务，请求者的EE上下文终止当前消息传输，向当前调度的发送队列发送错误信号，并从调度程序中删除当前调度的发送队列。然后，EE上下文调度下一个请求服务的发送队列并继续。导致错误的发送队列的行为如上所述。

C9-215：当发送队列处于错误状态时，它必须静默地丢弃任何到达的确认消息。

#### 9.9.2.4.3 请求程序C类错误行为

由于C类错误不能与任何特定的WQE关联，因此无法将特定的WQE标记为错误完成(completion in error)。

C9-216：如果请求程序C类错误可以与QP相关联，则发送队列应转换为错误状态，所有未完成的WQE均以“已完成-错误刷新（completed-flushed in error）”状态完成。

o9-155：如果CA请求方实现可靠的数据报服务，并且如果请求方C类错误可以与EE上下文关联，则其发送端应转换为错误状态，对于HCA，发布的错误为“关联异步错误”。

有关HCA错误报告的更多详细信息，请参阅**第11.6.3.2节“关联异步错误”**。

如果某个特定的错误不能与某个特定的资源相关联，则该请求程序可能无法与某个特定的错误关联。关于这种情况下的HCA错误处理，请参阅第11.6.3.4节“非关联异步错误”。

#### 9.9.2.4.4 请求者D类错误行为

D类错误仅在可靠数据报服务中发生。

o9-156：如果一个CA请求者实现可靠的数据报服务，它应该表现如下。对于请求者类D错误类，传输层应将请求者的EE上下文转换为错误状态，终止当前消息传输，向当前调度的发送队列发送错误信号，并将当前调度的发送队列取消排队。当保持错误状态时，任何其他发送队列请求服务的EE上下文继续转换到错误状态。

每个发送队列（QP）的行为与B类错误类似；它将其当前WQE标记为completed in error，将QP转换为error状态，并刷新所有后续WQE。

#### 9.9.2.4.5 请求者E类错误行为

当请求者接收到PSN与预期PSN不匹配的确认消息时，发生E类错误。这些错误只发生在可靠的服务类别上。

这些错误不会报告给上层。

具有意外PSN的确认消息被假定表示“ghost”确认消息或重复的确认消息。

ghost确认消息是在fabric中存在足够长时间的确认消息，它在连接被破坏和随后建立新连接后仍然存在。

当请求者认为其原始请求消息在fabric中丢失时，重新发送请求消息时，会发生重复的确认消息。如果两个请求消息最终都到达响应者，则响应者可以为每个请求消息生成一个确认消息。

C9-217：对于使用可靠连接服务的HCA请求者，为了响应请求者E级错误，请求者应丢弃确认消息。然而，这条规则有一个例外。对于可靠的连接服务，响应器可以使用一个重复的确认消息来向请求者传送端到端的流控制信用（一个“未请求的确认”）。因此，如果确认消息的PSN比请求者的预期PSN小1，则请求者必须恢复端到端信用并丢弃消息的其余部分。此行为在**第9.7.7.2节“端到端（消息级）流控制”**中有详细说明。

o9-157：如果TCA请求者实现可靠连接服务，或者如果CA请求者实现可靠的数据报服务或XRC服务，为了响应请求者E类错误，请求者应丢弃确认消息。然而，这条规则有一个例外。对于可靠的连接服务，响应器可以使用一个重复的确认消息来向请求者传送端到端的流控制信用（一个“未请求的确认”）。因此，如果确认消息的PSN比请求者的预期PSN小1，则请求者必须恢复端到端信用并丢弃消息的其余部分。此行为在**第9.7.7.2节“端到端（消息级）流控制”**中有详细说明。

应该指出的是，即使确认是一个真正的ghost、带有错误信用的确认，信用机制最终会恢复且不会把错误报告给上层。

#### 9.9.2.4.6 请求程序F类错误行为

C9-218：当CQ不可访问或已满且试图完成WQE时，请求程序F类错误发生。受影响的QP应转移到错误状态，并按照**第11.6.3.1节“关联异步事件”**所述生成关联异步错误。当前WQE和任何后续WQE都处于未知状态。

## 9.9.3 响应器端行为

表61列出了响应器必须检测到的错误，以及每个错误的故障行为类。故障行为/Fault Behavior类指定响应程序是否返回NAK代码、是否将错误报告给本地客户端以及接收队列的后续行为。syndrome列列出返回给请求者的NAK代码。

为了方便起见，表62“响应器故障类别行为摘要”中显示了故障行为类别的摘要。

**第9.7节“可靠服务”**中描述了可靠服务的错误检测，**第9.8节“不可靠服务”**中规定了不可靠服务的错误检测。

C9-219：本合规声明已过时，已被C9-219.1.1取代：。

C9-219.1.1：对于已实现的传输服务子集，响应器应符合表61中规定的错误行为。

此外，响应器的接收队列的行为应符合表62和以下各小节所示的每个故障行为类别的规定。

### 9.9.3.1 响应器侧错误响应

响应器侧共描述了十三类故障行为。故障行为根据是否向响应方端的客户端报告错误、是否通过NAK代码向请求方报告错误以及是否从接收队列使用WQE来分组。

#### 9.9.3.1.1 响应器A类故障行为

A类错误可追溯到格式错误或无效的WQE，或与接收器QP相关的其他错误。这些错误不是发送端造成的。

C9-220：对于响应器A类错误，应将该错误报告给响应器的客户端，QP被置于错误状态，对于可靠的服务，会生成“NAK远程操作错误”。

对于可靠的数据报服务，EEC继续运行。

如果响应程序是HCA，则这些错误将作为“完成错误”或关联的异步错误报告给verbs层。有关完成错误的讨论，请参阅**第10.10.2.2节“完成错误”**；有关异步错误的讨论，请参阅**第10.10.2.3节“异步错误”**。

如果响应程序检测到A类错误，其行为如下：

o9-157.2.1：除了上文描述的A类错误行为之外，如果一个与共享接收队列相关联的QP检测到A类错误，最初检测到错误的WQE和发送队列和接收队列上的所有后续WQE（包括随后由同一接收队列从关联的共享接收队列中取出的WQE）都应标记为错误。检测到错误的QP应转换为错误状态。共享接收队列的状态不会改变，共享相同SRQ的任何其他接收队列的状态也不会改变。

o9-157.2.2：如果共享接收队列检测到A类错误，则应将该错误报告给响应者的客户端，并将QP置于错误状态。如果响应程序是HCA，则这些错误将作为“完成错误”或“关联异步错误”报告给verbs层。

注意，如果该错误被共享接收队列检测到（而不是被接收队列检测到），则可能不会返回“NAK远程操作错误”，因为不需要SRQ来生成确认。这与接收队列检测到错误的情况略有不同，在这种情况下，要求接收队列返回“NAK远程操作错误”。

o9-157.2.3：如果接收队列试图从处于错误状态的共享接收队列获取WQE，则QP应转换为错误状态。如果响应程序是HCA，则此错误将作为“关联异步错误”报告给verbs层。

#### 9.9.3.1.2 响应器B类故障行为

B类错误报告给请求者，但不报告给响应者的本地客户端。

C9-221：对于使用可靠连接服务的HCA请求程序和B类响应端错误，传输应生成NAK代码，但不得从接收队列消耗WQE或将接收队列转换到错误状态。

o9-158：如果TCA响应者实现可靠连接服务，或者如果CA响应者实现可靠数据报服务或XRC服务，则其行为如下：对于响应器B类响应器侧错误，传输应生成NAK代码，但不应从接收队列消耗WQE或将接收队列转换为错误状态。

请注意，此故障行为类仅限于可靠服务。

如果响应程序检测到B类错误，其行为如下：

#### 9.9.3.1.3 响应器C类故障行为

C9-222：本合规性声明已过时，已被C9-222.1.1取代：。

C9-222.1.1：对于使用可靠连接服务的HCA响应器，对于C类响应器侧错误，应通过生成表61响应器错误行为摘要中规定的适当NAK代码向请求者报告该错误。如果错误可以与特定的QP相关，但不能与该接收队列上的特定WQE相关（例如，在没有立即数据的情况下执行RDMA写入请求时发生的错误），则应将该错误作为关联异步错误报告给响应方的客户端。详见**第10.10.2.3节“异步错误”**。如果错误可能与给定接收队列上的特定WQE相关，则QP应处于错误状态，并将错误作为完成错误报告给响应者的客户端。参见**第10.10.2.2节“完成错误”**。

o9-159：本合规声明已过时，已被o9-159.1.1取代：。

o9-159.1.1：TCA响应器执行可靠连接服务时，对于C类响应器侧错误，应向响应器客户端报错，QP进入错误状态。C级错误也应通过生成表61响应者错误行为摘要中规定的适当NAK代码向请求者报告。

接收队列的行为如下：

有关HCA错误报告的更多详细信息，请参阅**第10.10.2.2节“完成错误”**。

#### 9.9.3.1.4 响应器D类故障行为

C9-223：本合规性声明已作废，并由C9-223.1.1:。

C9-223.1.1：导致响应器D级错误的入站请求包应使传输按照**第9.9.3.1.4节“响应器D级故障行为”**中的规定进行响应。

在这种情况下，传输层应：

<span>◼ </span>静默丢弃数据包（详见**第9.6节“分组传输报头验证”**）

<span>◼ </span>不向请求方生成ACK或NAK代码

<span>◼ </span>不通知响应程序的客户端

#### 9.9.3.1.5 响应器D1类故障行为

导致D1类错误的入站请求数据包仅在不可靠连接模式下发生。

C9-224：对于使用不可靠连接服务的HCA响应程序，导致响应器D1类错误的入站请求包应导致传输按照**第9.9.3.1.5“响应器D1类故障行为”**中的规定进行响应。

在这种情况下，传输层应：

<span>◼ </span>静默丢弃数据包

<span>◼ </span>不通知响应程序的客户端

<span>◼ </span>在不消耗当前接收WQE（如果有）的情况下终止当前消息

<span>◼ </span>等待新消息的第一个数据包（可能大于预期的PSN）。

如果当前数据包，（导致D1类错误）BTH操作码为“first”或“only”，应将其视为新消息的第一个包。

当前的WQE（如果有）应重置为接受下一个传入的Send或RDMA WRITE with Immediate消息。

“当前消息”是指自最近接收到的“第一”或“唯一”操作码以来接收到的所有分组，不包括当前分组（这导致了D1类错误）。

“新消息”由BTH操作码为“first”或“only”的包表示。

o9-160：如果TCA响应程序实现不可靠连接服务，则它应符合上述合规性声明中描述的D1类HCA响应程序行为。

#### 9.9.3.1.6 响应器E级故障行为

此故障等级主要用于特定请求包的故障不应影响接收队列继续接收消息的能力的服务。

o9-161：如果CA实现可靠的数据报服务，则响应程序E级错误将导致响应程序执行以下操作：

1） 如果当前消息不完整，请中止该消息。可通过以下方式完成：

a）重置WQE以便可以在将来的消息中重用

b）将当前WQE（如果有）标记为以“Requester Aborted error”错误完成，

2）接收新的入站消息。接收队列应在不转换到错误状态的情况下继续运行：

符合性声明o9-161.2.1：定义更严格的要求，仅适用于与共享接收队列相关联的接收队列。

o9-161.2.1：如果QP实现不可靠的数据报服务并与共享接收队列相关联，则响应器E级错误应导致响应器执行以下操作：

1） 接收队列上检测到错误的WQE应该错误地完成。

2） 已由同一接收队列从关联的共享接收队列获取的后续接收的WQE也应错误地完成。共享接收队列上未被检测到错误的QP获取的其他WQE保持不变，并且没有错误地完成。

3） 接收队列应继续运行，而不会转换到错误状态。

4） 共享接收队列的操作不受这些错误的影响。

o9-161.2.2：如果QP实现不可靠的连接服务并与共享接收队列相关联，则响应器E级错误应导致响应器执行以下操作：

1）接收队列上检测到错误的WQE（如果有）应错误地完成。

2）已由同一接收队列从关联的共享接收队列获取的后续接收的WQE也应错误地完成。共享接收队列上未被检测到错误的QP获取的其他WQE保持不变，并且没有错误地完成。

3）接收队列应继续运行，而不会转换到错误状态。

4）共享接收队列的操作不受这些错误的影响。

#### 9.9.3.1.7 响应程序F类故障行为

F类错误行为仅用于RD服务，用于向请求方返回NAK代码和完成出错的WQE。在一些实例中，实现可以选择B类错误行为或F类错误行为。对于这些情况，类B和类F之间的唯一实质性区别在于接收WQE的处理，该接收WQE要么错误地完成，要么留在接收队列中重新使用。对于许多实现，错误地完成接收WQE要简单得多。

o9-162：本合规声明已过时，已被o9-162.1.1取代：

o9-162.1.1：如果CA实现可靠的数据报服务，则应同时向请求方和（当涉及到接收WQE时）向响应方的客户端报告响应程序F类错误。传输应将表61中规定的适当NAK代码返回给请求者，并以错误地完成当前WQE（如有）。接收队列应继续运行，而不会转换到错误状态。

对于HCA，报告的错误是“完成-处理错误 (Completion - Process Error )”。

EEC和目的地QP均保持运行。

接收队列的行为如下：

#### 9.9.3.1.8 响应器G级故障行为

当CQ不可访问或已满，并试图完成WQE时，发生G级错误。

C9-225：当CQ不可访问或已满且试图完成WQE时，会发生响应程序G类错误。受影响的QP应转移到错误状态，并按照**第11.6.3.2节“关联异步错误”**所述生成关联异步错误。当前WQE和任何后续WQE都处于未知状态。

#### 9.9.3.1.9 响应器H类故障行为

H类错误可追溯到与响应器EEC相关的本地错误。这些错误不是发送端造成的。

对于响应器H级错误，应将该错误报告给响应器的客户，并将EEC置于错误状态。

当前活动的WQE应该错误地完成。

如果响应者是HCA，则这些错误将作为完成错误（参见**第10.10.2.2节“完成错误”**）或关联异步错误（参见**第10.10.2.3节“异步错误”**）报告给verbs层。

#### 9.9.3.1.10 响应器J级故障行为

此类本地检测到的错误仅发生在RC QPs上。J类错误会报告给响应方客户端，但不会通过NAK代码向请求方报告。

当响应器接收到一个SEND with Invalidate请求（使用Invalidate发送last或仅使用Invalidate发送）时，会发生响应程序类J错误，该请求在IETH中包含无效的R_Key。

就错误优先级而言，与验证包头和执行带有Invalidate的发送操作相关的所有其他错误都会在报告R_Key冲突之前报告。

o9-162.2.1：以下语句构成了检测和报告与SEND with Invalidate请求相关联的R_Key违规的要求：

1）如果发生R_Key违规，则在成功执行invalidate的SEND请求之前，不应报告。在报告由无效操作导致的错误之前，必须报告执行发送请求导致的任何错误。

2）如果由于执行基础发送操作而发生错误，则不应报告与失效操作相关的错误。

3）如果底层的SEND操作正常执行，那么不管相关的invalidate操作的成功与否，都将使用receive WQE。换句话说，由于执行了底层的SEND请求，而invalidate已被装载到该请求上，因此将使用receive WQE。因此，即使invalidate操作失败，也始终使用receive WQE。

4）接收带有失效请求的SEND的接收WQE必须在相应的失效操作完成后才能完成。

5）如果在执行失效操作的过程中检测到错误，应执行以下操作：

a）遇到SEND with Invalidate错误的WQE被标记为completed in error。

b）QP被转移到错误状态。

c）同一个RQ上的后续wqe被标记为completed-flushed in error。

d）不向请求者发送NAK。

#### 9.9.3.1.11 响应器K类故障行为

对于HCA XRC TGT QP，对于K类响应器侧错误，应通过生成表61响应器错误行为摘要中规定的适当NAK代码向请求者报告该错误。该错误应作为附属异步错误报告给响应者的客户端。详见第11.6.3节，XRC TGT QP应处于错误状态。此外，如果错误可以与给定XRC SRQ上的特定WQE相关，则在XRC SRQ CQ中生成完成错误。由于将XRC TGT QP置于错误状态，相同或不同XRC SRQ中的其他接收WQE可能错误地完成。

#### 9.9.3.1.12 响应器L级故障行为

当CQ不可访问或已满且试图在XRC SRQ上完成WQE时，发生L级错误。

接收数据包的XRC TGT QP应移动到错误状态，并按照第11.6.3节所述生成相关异步错误。有关XRC SRQ的当前WQE和任何后续WQE处于未知状态，XRC SRQ被移到错误状态。

由于将XRC TGT QP置于错误状态，不同XRC SRQ上的其他接收WQE可能错误地完成。

#### 9.9.3.1.13 响应器M级故障行为

这类本地检测到的错误仅发生在XRC TGT QPs上。M类错误报告给响应方客户端，但不会通过NAK代码向请求方报告。

当响应器接收到一个SEND with Invalidate请求（或者使用Invalidate发送last或SEND only with Invalidate）时，会发生响应程序类M错误，该请求在IETH中包含无效的R_Key。

就错误优先级而言，与验证包头和执行带有Invalidate的发送操作相关的所有其他错误都会在报告R_Key违规之前报告。

以下语句构成了检测和报告与SEND with Invalidate请求相关联的R_Key违规的要求：

1）如果发生R_Key违规，则在成功执行invalidate的SEND请求之前，不应报告。在报告由无效操作导致的错误之前，必须报告执行发送请求导致的任何错误。

2）如果由于执行基础发送操作而发生错误，则不应报告与失效操作相关的错误。

4）接收带有失效请求的SEND的接收WQE必须在相应的失效操作完成后才能完成。

5）如果在执行失效操作的过程中检测到错误，应执行以下操作：

a）遇到SEND with Invalidate错误的WQE被标记为completed in error。

b）XRC TGT QP转换到错误状态，并按照第11.6.3.1节所述生成相关异步错误。

c）由于将XRC TGT QP置于错误状态，不同XRC SRQ上的其他接收WQE可能错误地完成。

d）不向请求者发送NAK。

# 9.10 报头和数据字段源

## 9.10.1 生成数据包时的字段来源

下表提供了各种IBA服务的数据包中各种报头和数据字段的来源的提示。表中使用了以下术语：

Link：这表示根据固定值、依赖于服务的值或基于加载到逻辑端口的参数查找的值，将值附加到数据包。由链路层完成。

Tr：这表示该值是固定的或由传输层计算的。

QP：这表示该值是从QP上下文派生的

EE：这表明该值是从EE上下文派生的

QP+EE：这表示这些值是从QP和EE上下文派生的

NA：不适用

WQE：值是直接或间接（通过地址向量）从WQE派生的

## 9.10.2 传输层连接参数

以下内容不是通过线路wire发送的，而是实现协议所必需的。包含此表是为了更好地理解传输层用于提供连接的参数。此列表仅涵盖IBA规范中提到的元素，可能需要其他元素来完全实现连接。

## 9.10.3 数据包报头和数据字段验证

下表说明了不同IBA服务的数据包中不同报头和数据字段的验证责任。表中使用了以下术语：

Link：该值由链路层检查。

Tr：这表示根据固定值检查该值，或由传输层在选项中进行选择。

QP：这表示根据QP上下文中的值检查该值

EE：这表示根据EE上下文中的值检查该值

NC：该值不检查

NA：不适用

WQE：根据WQE派生的信息检查该值

# 9.11 静态速率控制

随着fabric中流量负载的增加，资源竞争增加。拥塞管理用于平滑操作，提高fabric效率，提高有效带宽，并改善面对这种竞争的平均分组延迟。

有各种各样的机制来解决这个问题。IBA的这个版本定义了两种机制：静态速率控制（在本节中定义）和拥塞控制（在拥塞控制附件中定义）。规范的未来版本可能会提供附加机制的定义。

静态速率控制是终端节点将数据源传输到fabric中的速率保持在预先配置的值以下的能力。

IBA支持CAs中的静态速率控制，以减少由高速CA以超过路径或目标CA的接收能力的速率将数据包注入子网内的路径而引起的拥塞。例如，具有10gbps链路的CA通过中间交换机向具有2.5gbps链路的CA发送分组。在这种情况下，为了防止流量过快，需要在反向链路中引入反向流量控制。

IBA提供三种机制来管理静态速率控制。

<span>◼ </span>设备提供的端口速率信息（见**第16.3.3.1节“ClassPortInfo”**）

<span>◼ </span>支持SM的源/目标对的最佳速率报告（见**第15.2.5.16节“PathRecord”**）。

<span>◼ </span>连接设置MADs中的CA“包间延迟（Inter Packet delay）”参数（如下所述）

## 9.11.1 异构链路的静态速率控制

信道适配器能够限制注入的数据包速率。此速率基于子网本地目标端口。

o9-163：如果端口支持以大于2.5 Gbits/s的速率注入到fabric中，则该端口应提供本节中定义的静态速率控制。

支持的链接速率由PortInfo:LinkWidthSupported和PortInfo:LinkSpeedSupported和可选PortInfo:LinkSpeedExt-Supported组件定义。参见表155 PortInfo了解这些说明。

o9-164：如果端口配置为以大于2.5 Gbits/sec的速率注入到fabric中，则它不应调度数据包以注入到本地子网，直到自最后一个数据包被调度从此源端口注入到同一目标端口以来经过了可编程的时间量。

支持的链接速率由PortInfo:LinkWidthSupported和PortInfo:LinkSpeedSupported和可选PortInfo:LinkSpeedExt-Supported的组件定义。参见表155 PortInfo了解这些说明。

在上面，目的端口是指本地子网内目的端口的完整DLID（即基本DLID加上路径位），即使是全局路由的数据包，而源端口指的是入口端口，而不考虑SLID（即适用于与该端口相关联的所有SLID）。

发送后续数据包之前等待的时间基于当前数据包的传输时间。

o9-165：如果一个端口可以支持以大于2.5 Gbits/s的速率注入到fabric中，则发送到同一个DLID和来自同一端口的调度数据包之间的等待时间由包间延迟（IPD，Inter Packet Delay）决定。具体地说，如果分组b将被发送到同一DLID并且使用与分组a相同的源端口，则分组b不应被调度，直到自分组a被调度以来经过了时间Ts，其中Ts计算为：（IPD+1）乘以发送第一个分组所需的时间。此外，发送分组所需的时间计算为LRH:PktLen*4/Lr，其中Lr是从PortInfo:LinkWidthActive和PortInfo:LinkSpeedActive属性中获得的。

包间延迟（IPD）值是一个实的非负数。下表展示了一些示例值对IPD的解释。

请注意，下表只是一个示例，并不包括所有必需的IPD。见**第17.2.6节“静态速率控制”**，IPD CA值需要支持。

C9-226：如果CA被请求使用不支持的值，CA应选择一个支持的值，并在适当的MAD或verbs中返回该值。

如果请求的IPD值不受支持，建议CA使用比请求值大的最近支持值。

每个连接的QP（RDs的EE context）应该有一个可编程的IPD值。UDs应在WQE中包括IPD。

应该使用相同的端口和DLID为每个连接的QP和WQE编程相同的IPD值。如果编程了不同的IPD值，则CA可能使用这些值中的任何一个用于这些通信。

> 参考资料：”IB Specification Vol 1-Release-1.3-2015-03-03.pdf”

> 声明：本文禁止转载！素材来源于网络，仅供学习使用，如有侵权请联系网站删除(ngdcn_admin@163.com)。由于本人水平有限，如有纰漏，请以参考资料为准。

Infiniband手册