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

【Infiniband手册】第10章：软件传输接口

RDMA
2022-11-08
5816
更新：2022-11-25 22:20:35

# **10.1 概述**

本章描述了IBA的**软件传输层**。软件传输层定义了**通道接口（CI）**的功能和行为，即向verbs用户呈现通道。**此接口是作为主机通道适配器（HCA）、其相关固件和主机软件的组合实现的**。verbs使用者用于访问CI功能的API规范超出了此体系结构的范围。

本规范中经常遇到的一个概念是Verbs Consumer。词组的确切含义随着上下文的变化而变化，但正如术语表中所定义的，它始终意味着执行实体利用CI的能力来完成某些目标。**在某些情况下，Verbs Consumer可能是操作系统内核线程，在另一些情况下，是用户级应用程序，在另一些情况下，是某些特殊的特权进程**。如果差异对实现的正确行为很重要，则应明确定义，如**第11.1节 “Verbs介绍和概述”**；其他地方，则不作说明。

虽然分区部分并不是严格意义上的软件传输层的一部分，但它描述了与队列对（QP）的语义密切相关的思想，因此在本章中进行了合理的阐述。

此外，在这里给出必要实体的描述可以确保它们包含在体系结构规范中。

## **10.1.1 简介**

CI是IBA服务消费者与IBA fabric实例化之间互动的场所。对HCA的访问是通过Verbs进行的，Verbs可以创建和管理QPs，管理HCA，并处理可能通过Verbs出现的来自CI的错误指示。必须执行所有这些活动，以使Verbs使用者能够享受与主机操作系统支持的其他实体相同的保护和安全级别。

CI交互的基础是**管理HCA**，包括安排对它们的访问、访问和修改选定的属性，以及关闭它们。下面将描述这些活动，下一章将给出相应verbs层语义的详细信息。

对CI操作具有核心重要性的实体是QPs。它们必须被创建、与保护域关联、根据需要进行修改、并在不再需要时将其销毁以释放资源。在使用中，它们提供存储库(repositories)来处理Verbs使用者所需的信息，以及保护信息，以保证自身和主机系统的操作完整性。根据用户的要求，QPs提供各种操作模式。下面将描述这些模式的详细信息，以及为QP建立它们的方法，下一章将详细介绍相应的Verbs语义。有关QP的图形描述，请参见**图11**。

作为QP操作的一种中心模式(central mode)，直接、受保护地访问消费者内存是实现IBA性能潜力的关键。本章描述了为体系结构定义的内存访问的语义，详细介绍了内存区域和窗口及其注册、本地和远程访问已注册内存的访问密钥，以及在此上下文中可能出现的错误的管理。

**工作请求（WR）**是软件传输层中的一个基本对象，用户使用它将**工作队列元素（WQE）**排队到QP的发送和接收队列中。WQE用于标识IBA Fabric上的单个通信事件。WQE和QP的图形说明见**图12**。WR类型及其通过**完成队列条目（CQE）**创建、使用和处置的动态过程将在接下来的章节中进行描述，以及在使用时可能出现的错误的处理。下一章将详细介绍它们的内容。

## **10.2  管理HCA资源**

### **10.2.1 HCA**

Verbs允许使用者打开HCA、检索HCA属性、修改可由使用者更改的HCA属性以及关闭HCA。

队列对、完成队列和与特定HCA实例关联的其他资源不能在多个HCA之间共享，即使它们是由同一设备驱动程序软件管理的。

该体系结构的目的是允许实现在没有内核参与的情况下，将工作请求和完成状态在用户空间使用者进程之间传递给HCA。

### **10.2.1.1 打开HCA**

用于打开HCA的Verbs返回一个不透明的对象或句柄，以唯一地引用每个HCA，以便消费者能够区分端节点(endnode)中的HCA。

打开HCA可为消费者准备HCA。一旦打开HCA，在关闭之前不能再次打开。

### **10.2.1.2  HCA属性**

HCA属性是设备特性。消费者必须能够检索这些属性。HCA属性的完整列表在**第11.2.1.2节 “查询HCA”**中定义。

**第11.2.1.2节 “查询HCA”**中描述了与**第11.1.1节**中定义的Verbs扩展相关的附加属性。

### **10.2.1.3 修改HCA属性**

允许修改一组受限的HCA属性。这主要受性能和错误计数器管理信息的限制。大多数HCA属性要么是固定的，要么是通过fabric管理接口或通用接口（General Services Interface）进行操作的。

### **10.2.1.4 关闭HCA**

关闭将HCA恢复到其初始化状态，并释放HCA打开期间分配的所有资源。

通道接口不负责跟踪打开HCA时未分配的任何资源。

## **10.2.2寻址**

### **10.2.2.1 源地址寻址/Source Addressing**

对于全局寻址，每个HCA源端口都有一个GID表，其中包含源端口的有效GID。GID表是通过查询HCA Verb (Query HCA Verb)获得的。

C10-1：对于每个HCA源端口，CI应维护一个包含源端口有效GID的GID表。

每个地址向量包含一个源GID索引。源GID索引指定源GID表中的索引。源GID索引引用的条目定义与Address Vector关联的源GID。

C10-2：对于每个GID表，表中的第一个条目应包含GID索引0的只读不变值。

对于本地寻址，IBA通过使用基址LID (Base LID)、LMC和路径位（Path Bits），使每个HCA port都能使用多个LID。

C10-3：每个地址向量应包含特定的源端口LID路径位。

当HCA通过从端口的Base LID获取最高有效位和从地址向量的位中获取最低有效位来构造SLID时，端口的LMC指定了来自后者的位的数量。

### **10.2.2.2 目的地寻址**

端点的目的地寻址根据QP的服务类型确定：

C10-4：对于面向连接的QP，**目的地址应存储在QP上下文中**，并通过修改队列对属性Verbs（Modify Queue Pair Attributes Verbs ）进行独占操作。

o10-1：如果CI支持RD服务，那么对于可靠的数据报QPs，**目的地址应存储在EE上下文中**，并通过Modify EE Context Attributes Verbs进行独占操作，并且每个单独的工作请求都应引用一个EE上下文（见**第10.2.7节 “端到端上下文”**）。

o10-2：如果CI支持原始数据报服务，则对于原始QPs，应通过每个单独的工作请求提供目标地址。

o10-2.1.1：如果CI支持地址句柄（Address Handle ）端口号检查，则只有当队列对的主要物理端口与地址句柄的物理端口匹配时，才允许对访问地址句柄的不可靠数据报队列对进行操作。如果存在不匹配，CI将返回无效的地址句柄作为立即错误，或本地QP操作错误作为完成错误。

如果CI不支持地址句柄端口号检查，并且在UD QPs上处理操作时，如果队列对的主要物理端口号与Address Handle中的物理端口号不匹配，则不会因为端口号不匹配而生成错误。

C10-5：对于不可靠的数据报QPs，节点的目的地址应包含在一个地址句柄中，每个单独的工作请求都应引用一个地址句柄。

地址句柄是一个使用者不透明（consumer-opaque）的对象，它指向了本地或全局目标。Verbs用于创建、修改和销毁地址句柄。地址句柄与保护域相关联。保护域在**第10.2.3节“保护域”**中描述。

当有未完成的WR引用地址句柄时，Verbs使用者应避免修改或销毁该地址句柄。在任何情况下，都必须根据CQE规则成功地完成或销毁CQE的任何一个进程。CA可以仅在完成成功时发送包，但是目的地址可能是不确定的。当完成出错时，根本不会发出任何数据包。

C10-5.2.1：CI应处理引用地址句柄的任何WR，该地址句柄在WR未完成时被修改或销毁。WR应成功或错误地完成（适用正常的CQE生成规则）。尽管目的地址可能是不确定的，但只有当操作成功完成时，数据包才会发出。如果完成错误，CI将不发出数据包，并且报告的完成返回状态应为本地QP操作错误。

C10-6：CI应支持从QP或EE向该发送HCA中同一端口上相同或不同的QP/EE发送消息。此类信息不得通过fabric传输，但应包含在该HCA中。

实现这一点不需要特殊的寻址机制；相反，源QP、EE、地址向量或工作请求中的目的地信息与fabric上的任何其他节点将用于寻址目的地QP/EE的信息相同。

地址向量信息可以通过PathRecord属性上的SubnAdmGet方法从子网管理中获取。PathRecord信息用作地址句柄、端到端上下文或队列对上下文中地址向量的一部分。然后根据**表67**从这些位置获取该信息以创建包。如果除了从一个适用的PathRecord获得的参数之外的参数被用作地址向量的一部分，这可能会产生不良后果，包括但不限于包丢弃和连接断开。每当PathRecord信息用于多播目的地或具有非零跳限制时，应在地址句柄或EEC/QP中设置发送全局路由报头标志。

### **10.2.2.3 环回**

数据包环回通过**第17.2.2节**和C17-18所述的自寻址数据包来支持。**自寻址包**是其DLID和SLID地址位于同一CA、同一端口的数据包。此外，HCA可以选择支持环回指示符（Loopback Indicator）。当支持环回指示符时，地址句柄和QP/EE地址向量都可以使用环回指示符代替目的地LID。当获取基于数据报的QPs的完成时，如果消息的来源是环回，则也会报告环回指示符。

环回指示符寻址在端口LID未分配或可能更改的情况下非常有用，例如由于子网合并。使用环回指示符时，HCA应环回数据包，而不管端口状态如何。环回发生在特定的端口上，因此，在多端口信道适配器中，环回只允许连接到同一端口的QP之间。

使用环回指示符时，不使用的属性有：Path MTU、Source Path Bits和Static Rate。属性**服务级别**可用于HCA中的调度。

o10-6.2-1.1：如果CI支持环回指示符，则CI应通过查询HCA Verbs进行报告。CI应接受环回指示符作为创建地址句柄、修改地址句柄、修改QP和修改EEC Verbs的输入修饰符。CI应支持环回指示符作为查询QP、查询EEC和完成轮询verbs的输出修饰符。

o10-6.2-1.2：如果CI支持环回指示符，则当环回指示符设置在QP/EEC上时，CI应在RC QPs、UC QPs和EEC上对数据包进行环回。当地址句柄上设置了指示符时，CI应该在UD QP上环回报文。

## **10.2.3 保护域**

**保护域（PD）**用于将**队列对（QP）和共享接收队列**与**内存区域**相关联，作为启用和控制HCA访问主机系统内存的手段。

此外，保护域（PD）用于将队列对（QP）与未绑定内存窗口（Unbound Memory Windows）相关联，作为启用和控制HCA对主机系统内存访问的方法。

PDs还用于将队列对与绑定内存窗口（Bound Memory Window）相关联，如下所示：

◼ 对于**类型1内存窗口**，PD用于将队列对与绑定的类型1内存窗口相关联

◼ 对于**2A型内存窗口**，QP号用于将队列对与绑定的2A型内存窗口相关联；以及

◼ 对于**2B型内存窗口**，使用PD和QP号将队列对与绑定的2B型内存窗口相关联。

有关不同内存窗口类型的说明，请参阅**第10.6.7.2.2节 “通过内存窗口**进行**远程访问”**。

PDs还用于将不可靠的数据报队列对与Address Handles相关联，作为控制对UD目的地的访问的一种方法。队列对在**第11.2.5节“队列对”**中进行了描述。内存区域和内存窗口在**第11.2.10节“内存管理”**中有详细说明。每个HCA对应不同的PD。

C10-7：HCA中的每个队列对应与单个PD关联。多个队列对应能与同一PD相关联。

o10-2.2.1：如果HCA支持SRQ，则HCA中的每个共享接收队列都应与单个PD相关联。多个共享接收队列和队列对应能够与同一个PD相关联。

注意，SRQ有自己的PD。SRQ可以使用同一个PD（或不同的PD）与和其关联的一个或多个QP相关联。

C10-8：每个内存区域、未绑定内存窗口或地址句柄都应与单个PD相关联。多个内存区域、未绑定内存窗口或地址句柄应能够与同一PD关联。

C10-9：本合规声明已作废。

C10-9.2.1：如果QP与SRQ不相关，则只有当队列对的PD与内存区域的PD匹配时，才允许对访问内存区域的队列对进行操作。

o10-2.2.2：如果HCA支持SRQ，并且QP与SRQ关联：

◼ 只有当SRQ的PD与内存区域的PD匹配时，才允许传入发送操作访问MR或PMR （Physical Memory Region）

◼ 只有当QP的PD与内存区域的PD匹配时，才允许传入RDMA或原子操作访问MR，并且

◼ 只有当QP的PD与Memory Region的PD匹配时，才允许传入RDMA、Atomic或Invalidate操作访问PMR。

对内存窗口的访问取决于使用分配内存窗口Verbs分配内存窗口时消费者选择的内存窗口类型（参见**第11.2.10.9节“分配内存窗口”**）。

C10-10：只有当队列对的PD与地址句柄的PD匹配时，才允许不可靠数据报队列对对访问地址句柄进行操作。如果存在不匹配，通道接口将返回无效的地址句柄作为立即错误，或者返回Local QP操作错误作为完成错误。

### **10.2.3.1 分配保护域**

保护域通过Verbs来分配。

创建队列对、注册内存区域、分配内存窗口或创建地址句柄时，需要PD。

PD没有IB架构属性。操作系统通常需要强制执行这样的策略：当Verbs使用者创建队列对、注册内存区域、分配内存窗口或分配地址句柄时，必须指定PD以与其拥有的IB资源相关联（即由它分配）。

### **10.2.3.2 解除分配保护域**

通过Verbs解除分配。

C10-11：本合规声明已作废。

C10-11.2.1：如果CI不支持SRQ，如果PD仍然与任何队列对、内存区域、内存窗口或地址句柄相关联，则不应释放PD。如果试图这样做，Verbs将返回立即错误 (immediate error )。

C10-11.2.2：如果CI支持SRQ，如果PD仍然与任何队列对、内存区域、内存窗口、地址句柄或共享接收队列相关联，则不应释放PD。如果尝试这样做，verbs将返回立即错误。

## **10.2.4 队列对**

Verbs使用者使用Verbs向发送队列或接收队列提交工作请求（WR）。相关联的发送和接收队列统称为队列对（Queue Pair，QP）；这些QP驱动信道接口。QP是通道接口的一个组件，不能由Verbs使用者直接访问，只能通过使用Verbs进行操作。有关WR提交过程的描述，请参阅10.8工作请求处理模型。

### **10.2.4.1 创建队列对**

通过verbs创建QP。

创建QP时，消费者必须指定一组完整的初始属性。创建QP时需要定义的属性在**第11.2.5.1节“创建队列对”**中表示。

创建QP时，必须指定使用者期望在队列对的每个工作队列上未完成的最大工作队列条目（WQE）数。通过通道接口返回每个工作队列的实际条目数。

设置工作队列上未完成工作请求的最大数量时，使用者必须考虑到，这个数字必须足够大，以包含该队列上尚未完成的工作请求的数量加上该队列中尚未通过相关CQ释放的已完成工作请求的数量（参见**第10.8.5.1节“已释放资源计数”**）。注：对于未报告/unsingaled的完成，在根据**第10.8.6节“未**报告**完成”**确认完成工作请求之前，消费者不能将工作请求视为已完成。

### **10.2.4.2 队列对属性**

队列对具有可通过查询队列对Verb (Query Queue Pair Verb)检索的属性。QP属性的完整列表在**第11.2.5.3节“查询队列对”**中描述。

### **10.2.4.3 修改队列对属性**

一些QP属性可以在QP创建后进行修改。可修改的QP属性子集在**第11.2.5.2节“修改队列对”**中定义。

可以使用QP上未完成的工作请求来修改QP属性。当属性更改时，指定QP上未完成的任何工作请求可能无法正确执行。

设置工作队列上未完成工作请求的最大数量时，使用者必须考虑到，这个数字必须足够大，以包含该队列上尚未完成的工作请求的数量加上该队列中尚未通过相关CQ释放的已完成工作请求的数量（参见**第10.8.5.1节“已释放资源计数”**）。注：对于未标记的完成，在根据**第10.8.6节“未**报告**完成”**确认工作请求之前，消费者不能认为工作请求已完成。

CI可以支持修改QP上未完成工作请求的最大数量。如果这样做了，它必须能够在工作请求未完成时支持它。此外，它必须支持在每个QP上调整两个工作队列的大小。如果返回立即错误，则工作队列的状态必须与尝试调整工作队列大小之前的状态相同。可以理解的是，这可能会对性能产生不利影响，但不能导致立即、完成或异步错误，修改队列对Verb返回的立即错误除外。注意，调整大小操作可能会以超时和重试的形式对在调整大小操作期间尝试与QP通信的其他QP产生不利影响。对于不可靠的服务类型QPs，它还可能导致以丢包的形式丢失数据。

### **10.2.4.4 销毁队列对**

通过通道接口销毁队列对。

当QP被销毁时，任何未完成的工作请求不再被视为在通道接口的范围内。消费者有责任清理任何相关资源。

QP的销毁会释放代表QP在信道接口下分配的任何资源。此Verb返回后，未完成的工作请求将不会完成。

o10-2.2.3：如果CI支持IBA不可靠数据报组播（见**第10.5 节 “组播**服务”**），并且在目标QP仍附加到一个或多个多播组时调用了销毁队列对Verb，则CI应返回立即错误，QP不应被销毁。

在销毁QP之前，将QP修改为错误状态并检索相关CQE是一种良好的编程实践。销毁QP并不保证在销毁时从CQ释放该QP的CQE。即使CQE已经在CQ上，也可能无法检索它们。在销毁QP时，最好不要对CQ中CQE的数量作出任何假设。为了避免CQ溢出，建议在调整CQ大小、将新QP附加到CQ或重新打开QP（如果CQ容量有限）之前从与其相关联的CQ检索被破坏的QP的所有CQ。

如果此QP是连接的一部分，则应在QP被销毁之前释放该连接。更多信息，请参见**第12.9.4节 “状态图说明”**。

类型1 MWs从不绑定到QP。因此，1型MWs不会影响销毁QP的能力。

o10-2.2.4：如果HCA支持基本内存管理扩展并支持2A型内存窗口，那么当2A型内存仍然绑定到QP时，如果用户试图销毁QP，HCA必须返回一个错误。

o10-2.2.5：如果HCA支持基本内存管理扩展并支持2B型内存窗口，则HCA必须允许用户销毁QP，而2B型内存仍绑定在QP上。

有关内存窗口类型的说明，请参阅**第10.6.7.2.2节**。

### **10.2.4.5 特殊QPs**

被指定为特殊QP的是SMI QP（QP0）、GSI QP（QP1）以及原始IPv6和原始以太网类型QPs。这些QP类型是特殊的，因为它们比一般用途的QP具有不同和更严格的属性。

子网管理代理（SMA）或通用服务代理（GSA）可以在Verbs下面分别使用到SMI或GSI QPs的传入消息。如果MAD是在Verbs下面消费的，从Verbs消费者的角度来看，语义必须是一致的。

C10-12：在Verbs下面执行的任何消息处理，例如由SMA执行的，不得干扰代表Verbs使用者发布的任何WQE和CQE。

C10-13：CI应仅允许特权模式用户直接访问SMI和GSI QPs。

SMI和GSI QP可以共享一个完成队列，但也不能与任何非SMI或GSI类型的QP共享。

单个HCA上允许多个原始IPv6和原始以太网类型QP。然而，用于在QP之间接收消息的解复用算法不在本规范的范围之内。

## **10.2.5 Q_Keys**

队列密钥(Q_Key)是数据报服务QPs中使用的一种结构，用于验证远程发送方访问本地接收队列的权限。它们是通过Modify Queue Pair Verb以及在工作请求中设置的。用于Q_Key的值不在Verbs下面进行管理。**Q_Key包含在IB数据报包的报头中**。

Q_Key具有以下属性：

◼ 在接收描述符(Receive Descriptors)可以发布到QP之前，必须在QP上下文中建立Q_Key。

◼ Q_Key是Post Send Request Verb中的修饰语(modifier)。

C10-14：对于UD业务类型QPs，除QP0和QP1外，QP上下文中的Q_Key应用于验证传入数据包。如果Q_Key不匹配，包将被静默丢弃。有关验证QP0和QP1上传入数据包中的Q_Key的规则，请参见**第9.6.1.5.1节**。

o10-3：如果CI支持RD服务，则对于RD QPs，应使用QP上下文中的Q_Key验证传入的数据包。如果Q_Key不匹配，则数据包应置为NAK。该NAK将导致远程节点的发送队列按照状态图被置于适当的错误状态。

C10-15：Q_Key应是数据报服务类型队列对的发送请求Verb（Post Send RequestVerb）中的修饰符。通道接口应检查工作请求中的Q_Key。如果设置了Q_Key的高阶位，则出站分组应包含来自QP上下文的Q_Key。

如果没有设置Q_Key的高阶位，则传出数据包应包含来自工作请求的Q_Key。

对于RD服务类，Q_Key冲突会导致源发送队列转换为错误状态。目的地可以选择支持Q_Key冲突计数器和陷阱/trap。可以通过Verbs查询和设置此可选计数器。

Q_Key不会在Raw QP上强制执行。

## **10.2.6 完成队列**

CQ可用于在同一HCA上跨队列对从多个工作队列复用工作完成。

C10-16：CI应支持使用完成队列（CQ）作为工作请求完成的通知机制。CQ应具有零个或多个关联的工作队列。任何CQ应能够为发送队列、接收队列或两者提供服务。来自多个QP的工作队列应能够与单个CQ相关联。

### **10.2.6.1创建完成队列**

通过通道接口创建完成队列。

创建CQ时，必须指定CQ上可能未完成的完成队列条目（CQE）的最大数量；这称为CQ的容量。实际容量可通过通道接口返回。如果CQ上未完成的CQE的数量等于其容量，并且添加了另一个条目，则CQ溢出。用户有责任确保所选容量足以满足用户的操作；在任何情况下，必须安排处理由CQ溢出引起的错误。

C10-17：CI应在CQ中提取下一个WC之前检测并报告CQ的溢出。此错误必须报告为关联异步错误--请参见**第11.6.3.2节“关联异步错误”**。

### **10.2.6.2 完成队列属性**

唯一的完成队列属性是CQ的容量。可以通过查询完成队列Verb（Query Completion Queue Verb ）检索此属性。

请注意，没有提供检索CQ的一组相关工作队列的Verb；如果需要，使用者负责跟踪这些信息。

### **10.2.6.3 修改完成队列属性**

当与指定CQ相关联的队列上的工作请求未完成时，必须能够通过通道接口更改CQ的容量。可以理解的是，这可能会对性能产生不利影响，但不能导致立即或完成错误，但Resize Completion Queue Verb返回的立立即错误除外。

### **10.2.6.4 销毁完成队列**

完成队列将通过通道接口销毁。

C10-18：如果在工作队列仍与CQ关联的情况下调用了销毁CQ的Verb，则CI将返回一个错误，并且不应销毁CQ。

对CQ的销毁会释放代表CQ在Channel Interface下分配的任何资源。

## **10.2.7 端到端上下文**

**端到端上下文（EE Context）是本地HCA资源，本地HCA使用它来跟踪自身和另一个HCA之间传输的消息，以支持可靠的数据报服务QPs**。消费者通过Verb在HCA中建立EE上下文。

o10-4：如果CI支持RD服务，则CI应支持一个EE上下文，供消费者使用，以提供两个HCA端口之间的连接。每个本地EE上下文应精确地连接到一个目标上下文。

**使用者必须在一对EE上下文（每个HCA上一个）之间建立一个通信信道，然后两个HCA之间才能开始RD消息传递**。服务建立连接时，必须在**第12章**使用正常的通信方式来描述。

o10-5：**如果CI支持RD服务，HCA端口对之间应允许多个连接的EE上下文（RD通道）。**这些EE上下文允许具有相同或不同的属性集。

当属性发生更改时，指定EE上下文上未完成的任何工作请求都可能无法正确执行。

使用者向RD类型QP的发送队列提交RD工作请求。工作请求**指定**用于执行实际消息传输的EE上下文。工作请求可以提交给指定不同EE上下文的单个RD QP，只要指定的EE上下文与RD QP在同一个RDD中。

使用者有责任创建、修改和销毁EE上下文，使用通信服务收集通过状态转换EE上下文所需的信息，以及填写使用所需的属性。

需要注意的是，操纵EE上下文的Verbs（如Create EE Context和Modify EE Context）使用EE上下文**句柄**，但是通信管理和向发送队列提交工作请求都需要EE上下文**编号**。可以通过查询EE上下文Verb检索此数字。

### **10.2.7.1 创建端到端上下文**

EE上下文是通过通道接口创建的。

创建EE上下文时，使用者必须指定一组完整的初始属性。创建EE上下文时需要定义的属性在**第11.2.9.1节 “创建EE上下文”**中说明。

### **10.2.7.2 端到端上下文属性**

EE上下文具有可以通过Query EE Context Verb检索的属性。

EE上下文属性的完整列表在**第11.2.9.3节“查询EE上下文”**中描述。

### **10.2.7.3 修改EE上下文属性**

创建EE上下文后，可以修改某些EE上下文属性。**第11.2.9.2节**中定义了可修改的EE上下文属性子集。

当需要EE上下文的工作请求未完成时，也可以修改EE上下文属性。当属性更改时，任何需要指定EE上下文的未完成WR可能无法正确执行。

### **10.2.7.4 销毁端到端上下文**

端到端上下文通过通道接口销毁。

当一个EE上下文被销毁时，依赖于EE上下文的任何未完成的工作请求都将以适当的错误完成。

销毁EE上下文会释放在通道接口下代表EE上下文分配的任何资源。

如果此EEC是可靠数据报通道的一部分，则应在EEC被销毁之前释放RDC。更多信息见**第12.9.4节 “状态图说明”**。

## **10.2.8 可靠数据报域**

**可靠数据报域（RDD）**是一种将队列对与EE上下文相关联的方法。

o10-6：如果CI支持RD服务，则每个RD QP只能关联一个RDD。多个RD QP应能与同一RDD关联。

o10-7：如果CI支持RD服务，则每个EE上下文只能关联一个RDD。多个EE上下文应能与同一RDD关联。

o10-8：如果CI支持RD服务，则仅当EE上下文中的RDD与QP中的RDD匹配时，才允许在RD队列对上指定EE上下文的WRs。如果RDD不匹配，发起者的工作请求将以本地RDD违规错误（Local RDD Violation Error）完成，而不会对目标的接收队列产生影响（有关正确的错误代码，请参阅**第11.6.2节“完成返回状态”**）。

o10-9：如果CI支持RD服务，则CI至少应支持两个RDD。

定义RDD结构的目的是确保通过HCA可靠地分离用户和内核I/O RD流量。还需要注意的是，实现分离还需要两个EE上下文。

### **10.2.8.1 分配可靠数据报域**

通过通道接口，使用特权操作(privileged operation)分配可靠数据报域。

### **10.2.8.2 解除分配可靠数据报域**

通过通道接口解除分配可靠数据报域。

o10-10：如果CI支持RD服务，且如果RDD仍然与任何队列对或EE上下文关联，则不应释放RDD。如果试图这样做，CI将返回立即错误。

## **10.2.9 共享接收队列**

如果消费者将QP关联到共享接收队列，则本节中定义的语义适用。

### **10.2.9.1 支持SRQ的原因**

在没有SRQ的情况下，RC、UC或UD用户必须公布在给定QP上处理传入接收所需的接收WR的数量。如果使用者无法预测给定QP上的传入速率，因为，例如，连接具有突发性，则使用者必须：发布足够数量的RQ WR以处理每个连接的最高传入速率，或者对于RC，让消息流控制使远程发送方回退（发送速率），直到本地使用者发布更多WR。

任何一种方法都是低效的：

◼ 当接收队列处于非活动状态时，在每个QP上发布足够的WR以保持可能的传入速率，浪费WQE和相关的数据段。此外，HCA不提供回收这些WQE以用于其他连接的方法。

◼ 让RC消息流控制使得远程发送方回退可能会增加不必要的延迟，特别是当本地用户不知道RQ处于饥饿状态时。

共享接收队列通过允许多个队列对共享接收工作请求，以及更重要的是与接收工作请求关联的数据段，来解决此问题。当传入接收消息到达与SRQ相关联的任何QP时，HCA使用下一个可用SRQ WQE来接收传入数据。HCA通过与接收传入发送操作的QP关联的完成队列返回工作完成。

RC、UC或UD QPs可以与SRQ相关联。

### **10.2.9.2 创建共享接受队列**

用户可通过Create SRQ Verb 创建SRQ。

当通过Create SRQ Verb创建SRQ时：

◼ 使用者请求SRQ上可以发送(outstanding, 未完成)的WQE的最大数量，以及SRQ上每个WQE的分散/聚集元素的最大数量。CI返回SRQ上可以未完成的WQE的实际最大数量，以及SRQ上每个WQE的散射/聚集元素的实际数量。每个值必须大于或等于请求的数字。

完整的创建SRQ属性列表在**第11.2.3.1 节 “创建共享接收队列”**中描述。

### **10.2.9.3 修改共享接收队列**

使用者通过Modify SRQVerb设置SRQ限制。当用户将SRQ限制设置为大于零的任何值时，SRQ启用限制。当SRQ WQE的数量小于SRQ限制时，将生成关联的异步事件。使用者可以使用SRQ Limit Reached关联的异步事件作为需要发布更多WQE的指示器。当SRQ限制达到关联异步事件时，CI应将SRQ限制重置为零。

注意：用户模式使用者可以使用以下顺序在SRQ和QP初始化时减少用户到特权模式的转换次数：

◼ 用户模式使用者（User mode Consumer）调用Create SRQ。此步骤需要用户特权用户(user-privileged-user)模式转换。当Create SRQ返回时，消费者将得到一个SRQ句柄。

◼ 用户模式使用者使用SRQ句柄作为Post Receive Verb的输入修饰符，并向SRQ发送工作请求。消费者应该发布足够的WR，这样WR的总数至少大于消费者为SRW设置的SRQ限制。

◼ 用户模式使用者调用Create QP和Modify SRQ的组合，在过程中传递SRQ句柄。此步骤需要用户特权用户模式转换。特权模式使用者将Create QP和Modify SRQ转换为两个独立的Verbs调用。Create QP将新创建的QP与SRQ句柄引用的SRQ相关联。Modify SRQ为SRQ句柄引用的SRQ设置SRQ限制。

请注意，如果使用者修改SRQ的SRQ限制设置为大于零，则CI将使用新的SRQ限制重新启用SRQ。SRQ可以通过Modify SRQVerb多次启用，即使它已经启用。CI为每个SRQ保留一个SRQ限制值，重新配置将覆盖此值。

注意：如果SRQ限制多次启用(armed)，则Modify SRQ可能会返回，且指明SRQ限制已启用，而实际上它没有启用，并且可能会出现1或2个Limit Reached关联异步事件。如果消费者多次启用SRQ，然后接收到一个事件，那么对于触发该事件的是哪种防护，则存在不确定性。因此，用户应查询SRQ以确定SRQ是否仍处于待命状态。

如果HCA支持修改未完成SRQ WR的最大数量，则消费者可以通过Modify SRQ Verb请求更改未完成WR的最大数量。CI返回可在SRQ上未完成的WQE的实际最大数量，此值必须大于或等于请求的数量。

o10-10.2.1：如果HCA支持修改未完成SRQ WRs的最大数量，那么对于HCA支持的每个SRQ，HCA应允许更改未完成SRQ WRs的最大数量，即使SRQ上的WRs仍然未完成。

与QP resize操作类似，SRQ resize可能会对HCA性能产生不利影响。

o10-10.2.2：如果HCA支持修改未完成SRQ WRs的最大数量，并且使用者通过Modify SRQVerb执行调整大小的操作，则HCA不应将执行修改SRQVerb的直接结果返回错误。唯一的例外是：

◼ 当SRQ大小减小到SRQ上未处理WQE的当前数量以下时，在这种情况下，CI必须返回立即错误，并且不会影响SRQ状态；以及

◼ 当HCA支持修改未完成SRQ WR的最大数量，并且使用者通过Modify SRQ Verb执行调整大小操作，该Verb将SRQ大小减小到SRQ限制以下，则CI必须返回立即错误，并且不会影响SRQ状态。

当本地HCA正在执行调整大小操作时，针对与正在调整大小的SRQ相关联的本地QP的远程QP可能遇到消息超时。这些消息超时可能间接导致连接断开。因此，建议消费者使用消费者级消息静默或QP级静默（即,通过SQD）调整SRQ大小。

### **10.2.9.4 销毁共享接收队列**

使用者通过Destroy SRQVerb销毁SRQ。Destroy SRQ Verb的属性在**第11.2.3.4 节 “销毁共享接收队列”**中描述。

o10-10.2.3：如果HCA支持SRQ，并且消费者调用Destroy SRQVerb，而仍有QPs与SRQ关联，CI将返回立即错误(Immediate Error)。

o10-10.2.4：如果HCA支持SRQ，并且用户在SRQ上仍有未完成的WRs时调用Destroy SRQVerb，HCA应执行销毁SRQ操作。

o10-10.2.5：如果HCA支持SRQ，当CI成功地从Destroy SRQVerb返回时，CI应释放与SRQ相关的所有资源，包括已发布到SRQ但尚未完成的任何WRs。

### **10.2.9.5 SRQ状态**

SRQ只有两种状态：非错误状态和错误状态。

在非错误状态下：允许使用者向SRQ发布工作请求；并且允许QP从SRQ检索接收队列WQE。处于错误状态：使用者可以向SRQ发送工作请求；但是QPs无法从SRQ检索接收队列WQEs。

创建SRQ时，它将处于非错误状态。如果发生SRQ灾难性错误，SRQ将处于错误状态。试图查询或修改处于错误状态的SRQ将返回立即错误。SRQ退出错误状态的唯一方法是通过Destroy SRQ。成功完成销毁SRQ后，SRQ退出SRQ State逻辑。

## **10.2.10 XRC软件传输接口**

XRC传输服务提供与请求方RC和响应方RD相似的语义。为此，下文定义了新的传输层服务对象，这些对象与现有服务对象（RC和RD）非常相似，即：

◼ XRC INI QP

◼ XRC TGT QP

◼ XRC SRQ

◼ XRC Domain

具体来说，我们在请求端使用XRC INI QP连接到响应端的XRC TGT QP。XRC INIQPs和XRC TGT QPs从HCA支持的QP总数中分配。

每个XRC消息可以针对(target，发往)响应方的一个XRC SRQ：此XRC SRQ是接收发布的WRs的实际RQ。XRC SRQ的选择是以每WR为基础的，所选的XRC SRQ编号是XRC INI QPs的Post Send Verb的新输入修饰符。所选的XRC SRQ编号使用**第9.3.8 节“XRC扩展传输头（XRCETH）”**中定义的新扩展传输头在XRC数据包上携带。XRC SRQ从**第11.2.1.2节 “查询HCA”**中指定的专用集合中分配。

**正如其名称所暗示的，XRC INI QP没有响应程序端，XRC TGT QPs没有请求端**。XRC SQ WRs（请求）发布到XRC INI QPs，XRC RQ WR发布到XRC SRQ（并通过XRC TGT QPs访问）。

XRC SRQ和XRC TGT QPs通过XRC域关联，该域在概念上与RD传输服务的RDD相同。当且仅当XRC TGT QP的XRC域与包所针对的XRC SRQ域相同时，将成功处理通过XRC TGT QP接收的XRC数据包。

由于响应端CQ是为目标的XRC SRQ定义的，因此对于通过单个XRC TGT QP到达不同XRC SRQ的消息没有排序保证。

在XRC SRQ上，WQE的成功轮询必须保证可以重新发布WQE。也就是说，成功地轮询通过XRC SRQ发布的工作请求相关联的工作完成情况，可以保证向同一XRC SRQ发布另一个工作请求。

XRC SRQ不支持类型2内存窗口。

XRC INI和XRC TGT QP与RC QPs遵循相同的QP状态。

值得注意的是，尽管XRC TGT QP从不生成请求，但出于路径迁移的目的，它们仍然进入RTS状态。

错误语义遵循一个与RC QPs相似的模型，只有少数例外，如本附录的错误部分所述。一旦出现错误，XRC TGT QP将生成异步事件。此外，当相关时，XRC接收WQE被错误刷新，这些错误与WQE最初发布到的SRQ相关。

PDs遵循与RD QPs相似的模型。传入的XRC请求始终使用XRC请求中指示的XRC SRQ的PD（包括不使用XRC SRQ的接收WQE的RDMA）。

## **10.2.11  INFINIBAND头数据和源**

**下表列出了IBA协议头中的每个数据项，以及发送数据包所需的一些内部状态**。对于每个传输服务类型，它列出了该数据或状态的源。其中每一个的来源都是通过Verb访问的。此表用于建立数据包字段和通过Verb建立的结构之间的关联。请注意，表67的图例如下表68所示。

下表是上一个的图例。

# **10.3 资源状态**

## **10.3.1 队列对和EE上下文状态**

本节包含QP和EE上下文状态图。相同的状态图用于QPs和EE上下文。本节将使用QP/EE这一术语，如果差异很重要，将予以说明。本节将包含QP/EE状态的定义。这里定义的QP/EE状态和状态之间的转换顺序如**图126**所示。**EE上下文仅为可靠数据报服务类型创建，而QPs用于所有传输服务类型**。

注意，虽然QPs和EE上下文共享相同的状态图，但是EE上下文状态与使用该EE上下文的发送和接收RD QPs的状态没有关系。读者不应该假设因为QP进行了状态转换，与该RD QP相关联的EE上下文也将转换，反之亦然。

即使某些传输服务类型的状态子集可以以任何顺序出现，但状态必须按指定的顺序转换。这是为了保持状态定义的一致性并简化错误语义。选择的顺序是支持可靠连接服务类型所需的顺序，并提供使用EE上下文传输数据所需信息的完整性。

注意，对于与SRQ相关联的QP，在调用Destroy QP或Modify QP到重置状态之前，使用者应该让QP通过错误状态。在等待QP执行第一个QP时，可能会在没有第一个调用关联事件的情况下调用WQE并销毁最后一个关联事件的QP。但是，如果使用者不等待关联的异步Last WQE Reached事件，则WQE和数据段泄漏可能发生。因此，使用以下过程来拆除与SRQ相关联的QP是一个好的编程实践：

◼ 使QP处于错误状态

◼ 等待关联的异步上次WQE Reached事件（Affiliated Asynchronous Last WQE Reached Event ）

◼ 要么：

✸ 通过调用Poll CQ Verb来排出CQ，并等待CQ为空或Poll CQ操作的数量已超过CQ capacity size；或者

✸ 在同一CQ上发布另一个完成的WR，并等待该WR作为WC返回；

◼ 然后调用Destroy QP或Reset QP。

o10-10.2.6：如果HCA支持基本内存管理扩展并支持2A型内存窗口，则当2A型MWs仍绑定到QP时，如果使用者尝试从任何状态到重置状态的Modify QP转换，则HCA必须返回错误。

o10-10.2.7：如果HCA支持基本内存管理扩展并支持2B型内存窗口，则HCA必须允许使用者在2B型MWs仍然绑定到QP的情况下将QP从任意状态转换到重置状态。

重要的是要理解QP/EE状态被用作连接过程的一个组成部分。这是假设您对对连接过程和连接状态图有透彻的了解情况下进行的。这在**第12.9.7.1节“主动状态”**和**第12.9.7.2节“被动状态”**中有详细讨论。

C10-19：除了一个例外，CI应为每个QP实现复位/Reset、初始化/Init、RTR、RTS、SQD、SQEr和错误状态。CI不得实施RC QPs的SQEr状态。这些状态之间的转换必须限于图126所示的状态。

o10-11：如果CI支持RD服务，则CI应为每个EE上下文实现Reset、Init、RTR、RTS、SQD和错误状态。这些状态之间的转换必须限制为**图126**所示的状态。

### **10.3.1.1 复位**

复位状态的特性为：

C10-20：新创建的QP/EE应置于复位状态。

◼ 当修改QP/EE属性时，可以通过指定复位状态从任何状态转换到复位状态。

◼ 已经分配了实施QP/EE所需的任何资源。例如，有些实现需要分配WQEs和/或控制结构。

◼ Modify Queue Pair和Modify EE Context Attributes Verbs是Verbs使用者在不破坏EE/QP的情况下从重置状态转换的唯一方法。

◼ C10-21：在创建或转换到重置状态时，必须将所有QP/EE属性设置为初始化默认值，如“创建队列对”和“创建EE上下文Verbs”中所述。

◼ 通过调用Destroy Queue Pair或Destroy EE上下文Verbs，可以实现Reset状态的转换，从而退出状态图。

**对于EEs：**

◼ 工作请求在reset状态下指定EE上下文是错误的。

o10-12：如果CI支持RD服务，并且在Reset state中向指定EE上下文的RD QP的发送队列提交了一个工作请求，则应错误地完成该工作请求。

◼ 在此状态下使用EE上下文的工作请求不能是未完成的。

o10-13：如果CI支持RD服务，则任何针对处于重置状态的EE的传入消息都必须静默地丢弃。

**对于QPs：**

C10-22：如果一个工作请求被提交到工作队列，而其对应的QP处于重置状态，则应立即返回错误。

◼ 工作队列为空。工作队列中没有未处理的工作请求。

◼ 所有工作队列处理都被禁用

C10-23：以处于重置状态的QP为目标的传入消息必须静默地丢弃。

### **10.3.1.2 初始化（INIT）**

初始化状态的特征是：

◼ 基本QP/EE属性已配置为Modify Queue Pair和Modify EE Context attributes Verbs中的定义。

◼ 只有从重置状态转换到此状态才可能。

◼ Modify Queue Pair或Modify EE Context Attributes Verbs是Verbs使用者在不破坏EE/QP的情况下使能从Init状态转换的唯一方法。

◼ 通过调用Destroy Queue Pair或Destroy EE上下文Verbs，可以实现Init状态的转换，从而退出状态图。

**对于EEs：**

o10-14：如果CI支持RD服务，则任何针对处于Init状态的EE的传入消息都必须被静默地丢弃。

◼ 工作请求在Init状态下指定EE上下文是错误的。

o10-15：如果CI支持RD服务，并且消费者在Init状态下向指定EE context的RD QP的发送队列提交工作请求，则该工作请求将错误地完成。

**对于QPs：**

◼ 工作请求可能会提交给接收队列，但不会处理传入的消息。

C10-24：CI应允许在其对应的QP处于初始状态时向接收队列提交工作请求。

◼ 向发送队列提交工作请求是错误的。

C10-25：如果一个工作请求被提交到一个发送队列，而此时其对应的QP处于Init状态，则会返回立即错误。

◼ 两个队列上的工作队列处理都被禁用。

C10-26：以处于初始化状态的QP为目标的传入消息必须立即丢弃。

### **10.3.1.3 准备接收（RTR）**

准备接收状态的特征为：

C10-27：CI应支持向处于RTR状态的QP队列发布工作请求。

C10-28：针对处于RTR状态的QP的传入消息应正常处理。

o10-16：如果CI支持RD服务，并且传入消息在RTR状态下寻址到EE上下文，则该消息应正常处理。

◼ 只能使用Modify Queue Pair或Modify EE Context AttributesVerbs从Init状态转换到该状态。

◼ 通过调用Destroy QP或Destroy EE上下文Verbs，可以实现RTR状态的转换，从而退出状态图。

**对于EEs：**

◼ 工作请求在RTR状态下指定EE上下文是错误的。

o10-17：如果CI支持RD服务，并且用户向指定了处于RTR状态的EE context的RD QP的发送队列提交了一个工作请求，则该工作请求将错误地完成。

**对于QPs：**

◼ 已禁用发送队列上的工作队列处理。将工作请求发送到发送队列是一个错误。

C10-29：如果一个工作请求被提交到一个发送队列，而其对应的QP处于RTR状态，则应返回立即错误。

### **10.3.1.4 准备发送（RTS）**

在转换到该状态之前，必须完成QP/EE通信建立协议。

准备发送状态的特征是：

◼ 已为连接的服务类型和RD通道建立了请求者的QP/EE和响应者的QP/EE之间的通道。

◼ 只能从RTR和SQD State转换到这种状态。

◼ Modify Queue Pair或Modify EE Context Attributes Verbs是Verbs使用者在不破坏EE/QP的情况下使能RTS状态转换的唯一方法。

◼ 通过调用Destroy Queue Pair或Destroy EE上下文Verbs，可以实现RTS状态的转换，从而退出状态图。

C10-30：CI应支持在RTS状态下向QP发布工作请求。

C10-31：RTS状态下QP上的工作请求应正常处理。

C10-32：RTS状态下针对QP的传入消息应正常处理。

o10-18：如果CI支持RD服务，并且传入或传出消息在RTS状态下使用EE上下文，则该消息应正常处理。

### **10.3.1.5 发送队列排出（SQD）**

发送队列排出状态的特征为：

C10-33：CI应支持在SQD状态下向QP发布工作请求。

C10-34：以处于SQD状态的QP为目标的传入消息应正常处理。

o10-19：如果CI支持RD服务，并且传入消息在SQD状态下使用EE上下文，则该消息应正常处理。

◼ 只能从RTS状态转换到该状态，使用Modify Queue Pair或Modify EE Context Attributes Verbs。

C10-35：当转换到SQD状态时，QP/EE的发送逻辑必须停止处理任何额外的消息。它还必须完成消息边界上所有未完成的消息，并处理任何传入的确认。CI不得开始处理在状态转换发生时尚未开始执行的其他消息。

C10-36：当接收到所有预期的确认，并且发送队列工作请求的处理已停止，并且如果请求了事件通知，则应生成关联的异步事件。

◼ 使用者可以使用异步事件来确定何时可以进行状态转换。

◼ 可以通过Modify Queue Pair或Modify EE Context Attributes Verbs从SQD状态进入RTS状态或错误状态。

◼ 在从SQD到RTS的转换过程中，属性可能会被修改，但是为了安全地更改属性，双方都必须接收到关联的异步事件。

o10-19.a1：如果CI支持在从SQD转换到RTS时更改与RC QP关联的物理端口的能力，则CI应在完成从SQD到RTS的转换之前，将物理端口（如果指定了不同的物理端口）与QP相关联。在从sqd到RTS的转换过程中，物理端口是Modify QP动词中的一个可选属性。

o10-19.a2：如果CI支持RD服务，并且支持在从SQD转换为RTS时更改与EE上下文相关的物理端口的能力，则CI应在从SQD到RTS过渡完成之前，将物理端口（如果指定了不同的物理端口）与EE上下文相关联。物理端口是从SQD到RTS过渡期间修改EE上下文Verbs中的可选属性。

◼ 也可以通过调用Destroy Queue Pair或Destroy EE上下文Verbs来转换出SQD状态，从而退出状态图。

**对于EEs：**

◼ EE上下文发送端的工作队列处理已禁用。

o10-20：如果CI支持RD服务，则提交到RD QP的发送队列的工作请求（指定SQD状态下的EE上下文）不得被处理，但应保持排队状态。

◼ 与EE相关联的QP不会自动转换到SQD状态，也不是固有的必须这样做。

**对于QPs：**

◼ 已禁用发送队列上的工作队列处理。

C10-37：SQD状态中提交给QP发送队列的工作请求不得被处理，但应保持排队状态。

SQD到SQD状态转换可以在SQ排出完成时执行，即CI已完成对消息边界上任何未完成消息的处理并处理了任何传入的确认，或者在SQ排出正在进行时执行。

但是，如果SQ尚未完全耗尽，则不允许更改SQD到SQD转换的某些可选属性。如果Verbs使用者执行从SQD到SQD的状态转换，并试图在SQ尚未耗尽时更改此类可选属性，则CI应报告立即错误。请参阅**第11.2.5.2 节**和**第11.2.9.2 节**，了解在SQ仍在排出时不能更改的属性列表。为了确定SQ是否已耗尽，软件可以使用关联的Affiliated Asynchronous Event 或使用Query QP或Query EE Verb。

如果SQ尚未排空，则不允许执行SQD到RTS状态转换。如果用户试图将QP/EE从SQD移动到RTS，CI应报告立即错误。

### **10.3.1.6 发送队列错误（SQER）**

发送队列错误状态的特征是：

◼ 只有在处理发送队列上处于RTS状态的工作请求时发生完成错误，才能转换到该状态。

◼ 向发送队列错误状态的转换适用于除RC QP之外的所有QP。

C10-38：在接收队列转换为SQEr状态之前提交给该队列的接收工作请求应继续正常处理。新的接收必须能够投递到这样的接收队列。以处于SQEr状态的QP为目标的传入消息必须正常处理。

C10-39：导致完成错误并导致转换到SQEr状态的工作请求必须通过完成队列为错误返回正确的完成错误代码。

◼ 此WR可能已部分或完全执行，因此可能会影响接收方的状态，如下所示：

发送操作可能已部分或完全完成；因此，可能在接收方上生成完成队列条目，也可能未生成。

RDMA读取操作可能已部分完成；因此，其工作请求的数据段所指向的内存位置的内容是不确定的。

RDMA写入操作可能已部分完成；因此，由其工作请求的远程地址指向的内存位置的内容是不确定的。如果操作指定即时数据，则可能在接收器上生成完成队列条目，也可能尚未生成。

原子操作可能尝试过，也可能没有尝试过；因此，由工作请求的远程地址指向的内存位置的内容可能具有与任一事件一致的值。在本地节点，其工作请求的数据段所指向的内存位置的内容是不确定的。

C10-40：发送队列上的工作请求，在导致转换到SQEr状态的完成错误之后，必须通过Completion Queue返回刷新错误（Flush Error）完成状态。

◼ 根据QP的服务类型，当错误发生时，一些随后的WRs可能已经在进行中。这可能影响了远程节点上的状态。可能的影响取决于上述WR类型。

◼ Modify Queue Pair Verb可用于从SQEr状态转换到RTS状态。

◼ Modify Queue Pair Verb可用于从SQEr状态转换到Reset或Error状态。

◼ 接收队列错误或异步错误将导致对错误状态的响应。

◼ SQEr状态的转换可以通过调用Destroy Queue Pair Verb来实现，从而退出状态图。

### **10.3.1.7 错误**

误差状态的特征为：

◼ 停止QP/EE上的正常处理。

C10-41：导致完成错误并导致转换为错误状态的工作请求必须通过完成队列为错误返回正确的完成错误代码。

◼ 此WR可能已部分或完全执行，因此可能会影响接收方的状态，如下所示：

发送操作可能已部分或完全完成；因此，可能在接收方上生成完成队列条目，也可能未生成。

RDMA读取操作可能已部分完成；因此，其工作请求的数据段所指向的内存位置的内容是不确定的。

原子操作可能尝试过，也可能没有尝试过；因此，由工作请求的远程地址指向的内存位置的内容可能具有与任一事件一致的值。在本地节点，工作请求的数据段所指向的内存位置的内容是不确定的。

C10-41.2.1：以处于错误状态的QP为目标的传入消息必须静默丢弃。

C10-42：导致转换为错误状态的完成错误的后续工作请求，包括在转换之后提交的工作请求，必须通过完成队列返回刷新错误完成状态。

◼ 根据QP的服务类型，当错误发生时，一些随后的WRs可能已经在进行中。这可能影响了远程节点上的状态。可能的影响取决于上述WR类型。

◼ Modify Queue Pair或Modify EE Context AttributesVerbs指定到重置状态的转换，是实现从错误状态到重置状态的转换的唯一方法。

◼ 还可以通过调用Destroy Queue Pair或Destroy EE上下文Verbs来实现从错误状态的转换，从而退出状态图。

**对于EEs：**

◼ 如果错误发生时工作请求正在处理中，则完成工作请求时会出现完成错误。

o10-21：如果CI支持RD服务，并且RD工作请求使用处于错误状态的某个上下文，则必须错误地完成该WR。这将使发送的QP进入SQEr状态。

◼ 发生在EE上的错误可能不会对QP状态产生相应的影响。

**对于QPs：**

◼ 对于关联的异步错误，可能无法继续处理工作请求。在这种情况下，未完成的工作请求将无法完成。

◼ 在处理错误通知时，用户有责任确保所有错误处理在强制QP重置之前已完成。

# **10.4 自动路径迁移**

自动路径迁移是一种可选工具，可在发生故障时恢复连接。自动路径迁移可用于可靠连接、不可靠连接和XRC QP服务类型以及可靠的数据报EE上下文。

本节从软件传输层的角度解释自动路径迁移。以硬件为中心的说明包含在通道适配器部分：**第17.2.8节“自动路径迁移”**。

Modify Queue Pair和Modify EE Context Attributes Verbs提供了加载备用路径和转换**第10.4.1节“路径迁移状态图”**中定义的路径迁移状态的基本功能。

自动路径迁移通过在一对连接的QP或EE上下文上加载备用路径并将路径迁移状态设置为Rearm来启用或重新启用。通信管理器定义协议和机制，这些协议和机制可用于在本地和远程连接的QP或EE上下文上启用或重新启用自动路径迁移。通信管理器对自动路径迁移的支持在**第12.6节“通信管理消息”**和**第12.8节“备用路径管理”**中描述。

一旦在连接的QP/EE的两端启用了自动路径迁移，就可以通过将QP/EE路径迁移状态从Armed转换为Migrated来启动迁移，无论是从Verbs接口的上方还是下方。Verbs使用者或CI用于确定何时应尝试路径迁移的策略超出了体系结构的范围。

## **10.4.1 路径迁移状态图**

o10-22：如果支持自动路径迁移，则CI应对每个可靠连接和不可靠连接队列对执行迁移、重新配置和防护路径迁移状态。这些路径迁移状态之间的转换必须限制为**图127**所示的那些状态。

o10-23：如果支持自动路径迁移和可靠的数据报服务，CI应为每个EE上下文实现迁移、重新部署(rearm)和防护(armed)路径迁移状态。这些路径迁移状态之间的转换必须限制在图127所示的范围内。

路径迁移状态适用于QP或EE上下文，但仅与**第10.3.1节 “队列对和EE上下文状态”**中描述的QP/EE上下文状态相切相关。

o10-24：如果支持自动路径迁移，并且在转换到QP/EE状态（而不是RTS）期间，Verbs Consumer尝试将路径迁移状态从Migrated更改为Rearm，则应返回Immediate Error。

o10-25：如果支持自动路径迁移，并且在从非RTS或SQD的QP/EE状态转换期间，Verbs Consumer尝试将路径迁移状态从Armed更改为Migrated，则应返回Immediate Error。

路径迁移状态与通信建立过程的关系在**第12.9.7节 “状态和转换定义”**中定义。

在路径迁移状态处于待命状态（启用自动路径迁移）时，允许将现有备用路径替换为新的备用路径。加载新备用路径的机制与发生路径迁移后重新加载备用路径的机制相同，如**第12.8节 “备用路径管理”**中所述。

路径迁移状态如图127所示。

### **10.4.1.1 迁移/Migrated**

o10-26：如果支持自动路径迁移，则QP/EE的初始路径迁移状态应该为迁移/Migrated状态。

当状态设置为Migrated时，自动路径迁移功能被抑制。

在以下情况下，Verbs使用者应该为要迁移的QP/EE保留路径迁移状态：

◼ 本地CI不支持自动路径迁移。如果Verbs使用者尝试使用“修改队列对”或“修改EE上下文属性” Verbs更改路径迁移状态，则将返回立即错误。

◼ Verbs使用者不希望在QP/EE对上启用自动路径迁移。

◼ 远程CI不支持或不希望自动路径迁移。如果Verbs使用者使用Modify Queue Pair或Modify EE Context Attributes Verbs将路径迁移状态更改为Armed，则QP/EE的路径迁移状态将相应更改，并且不会生成错误。本地CI不得将QP/EE从REAM转换为Armed。处理此条件超出了体系结构的范围。

当前路径迁移状态为Armed且QP/EE状态为SQD或RTS时，Verbs  Consumer或CI可以将路径迁移状态设置为Migrated。何时迁移的决定是一个策略问题，这超出了体系结构的范围。

o10-27：如果支持自动路径迁移，从防护/Armed到迁移/Migrated的转换应导致迁移到本地QP/EE上的备用路径。CI应引发路径迁移的关联异步事件，并应在新路径上使用该QP/EE发送下一个数据包，并且该包应带有迁移请求。

远程连接的QP/EE验证**第17.2.8节“自动路径迁移”**中定义的此请求。

o10-28：如果支持自动路径迁移，则当成功验证传入数据包的迁移请求时，CI应为要迁移的QP/EE设置路径迁移状态，迁移到备用路径，并为该QP/EE引发路径迁移关联异步事件。

o10-29：如果支持自动路径迁移，当一个传入包的迁移请求验证失败时，CI不会修改该QP/EE的路径迁移状态，也不会迁移到备用路径，而是对该QP/EE生成路径迁移请求失败的关联异步错误。

只有当当前路径迁移状态为Armed且QP/EE状态为SQD或RTS时，Verbs使用者才应将路径迁移状态设置为Migrated。当Verbs使用者试图在任何其他条件下将路径迁移状态设置为Migrated时，Modify Queue Pair或Modify EE Context Attributes Verbs应生成立即错误。

o10-30：如果支持自动路径迁移，则只有当当前状态为armed且QP/EE状态为SQD或RTS时，CI才会将本地路径迁移状态更改为Migrated。

### **10.4.1.2 REARM**

仅允许Verbs使用者使用Modify Queue Pair或Modify EE Context attributes Verbs启动从Migrated到Rearm的转换。

o10-31：如果支持自动路径迁移，则CI不应将本地路径迁移状态从Migrated更改为Rearm，除非Verbs使用者请求。

Verbs使用者应加载或重新加载备用路径，并确保远程节点在将状态从Migrated转换为Rearm之前已接受备用路径。向Rearm状态的转换向CI表明，Verbs消费者相信此QP/EE已准备好向Armed状态转换。。当Verbs使用者将状态转换为Rearm时，无效或过时的备用路径将不会生成错误。处理这种情况超出了体系结构的范围。

o10-32：如果支持自动路径迁移，则转换到Rearm状态将导致CI尝试与远程连接的QP/EE协调，以锁定步进(lock-step)方式将本地和远程连接的QP/EE移动到待命状态。

有关CI如何执行此转换的详细信息包含在**第17.2.8节“自动路径迁”**移中。

连接两端的QP/EEs必须处于Rearm状态，然后CI才能将它们转换到待命状态(Armed State)。

### **10.4.1.3 待命状态/Armed**

表示与本地和远程节点上连接的QP/EE关联的CI已准备好执行路径迁移。

# **10.5 组播（多播）服务**

组播是指将消息发送到单个多播地址并将其传送到多个队列对的能力，这些队列对可能位于多个终端端口上。多播地址由MGID和MLID定义。多个MGID可以与单个MLID关联。但是，给定的MGID不能与同一子网上的多个MLID关联。

IBA规定了两种类型的组播：IBA不可靠组播和原始数据包组播。

**IBA不可靠多播是HCA的可选功能**。可以查询HCA以确定该HCA支持的多播组的数量。如果HCA不支持IBA不可靠多播，则多播组的数目设置为零。

o10-33：如果CI支持IBA不可靠多播，则必须至少支持一个多播组。

**原始数据包**组播**是HCAs的可选功能**。可以查询HCA以确定它是否支持原始数据报多播。

## **10.5.1 多播组和多播消息接收**

多播组是接收发送到单个多播地址的多播消息的终端节点的集合。多播组是一种fabric管理职责，通过使用多播地址来确定目标。

### **10.5.1.1  IBA不可靠多播接收**

o10-34：如果CI支持IBA不可靠多播，则必须将UD QP附加/attached到多播组，以接收IBA多播消息。

QP通过Verbs连接到多播组或从多播组分离。Attach QP to Multicast Verbs的唯一功能是将接收QP分配给多播组。如果HCA不允许QP附加到多播组，它将返回一个立即错误，指示资源不足。

可以将一个或多个QP连接到每个多播组，直到HCA支持的最大数量。为了接收发送到多播组的包，附加到特定多播组的每个QP应该是与传入分组的分区相同的分区的成员。

只有不可靠的数据报QPs才能用于IBA不可靠组播。因此，所有不可靠数据报语义也适用于IBA不可靠多播。

当成功接收到有效的多播数据包时，CI将该多播数据包发送到每个UD QP，该UD QP与由传入分组的MGID和MLID定义的多播地址相关联。

注意，接收多播包是在与多播地址关联的所有UD QP上接收，无论这些UD QP中的某些是否共享SRQ。也就是说，如果多播分组到达，则与分组的多播地址相关联的所有UD QP都必须接收到达的数据包，即使UD QP共享相同的SRQ。

多个UD QP附着在同一个SRQ上且组播地址相同，当组播报文到达时引用该组播QP的组播地址对于每个与接收到多播数据包的端口上的多播地址相关联的UD QP, CI必须：

◼ 从SRQ检索WQE；注意，如果WQE不可用，则传入消息将被丢弃

◼ 接收（或复制）传入的多播数据包到UD QP的接收队列中，并且

◼ 生成与UD QP相关联的CQ的工作完成。

### **10.5.1.2 原始数据报多播接收**

原始数据报QPs不用附加到多播组以接收原始分组多播消息。如果HCA每个端口只支持一个原始IPv6 QP，则在一个端口上接收到的所有原始IPv6多播消息都将被传送到该端口的原始IPv6 QP；如果支持多个原始IPv6 QP，则原始IPv6多播消息将根据IBA范围外的实现定义的策略传递到这些QP的子集。类似地，如果一个HCA每个端口只支持一个原始Ethertype QP，那么在一个端口上接收到的所有原始Ethertype多播消息都将被传递到该端口的原始Ethertype QP；否则，这些消息的分发将还得靠实现定义。

只有原始报QPs可以用于原始数据报多播。因此，所有原始语义也适用于原始数据报多播。

## **10.5.2 多播工作请求**

### **10.5.2.1  IBA不可靠多播工作请求**

IBA不可靠多播**工作请求**必须通过Post Send Request Verb提交到单个目的地多播地址。此目标多播地址，作为工作请求的一部分，是用地址句柄指定的。任何不可靠的数据报QP都可以用来发起IBA不可靠的多播工作请求。为了发起IBA不可靠的多播请求，QP不需要附加到多播组。

Send是不可靠数据报发送工作队列上唯一允许的操作。不允许进行原子和RDMA操作。不可靠数据报消息不应大于请求者和响应者之间的PMTU。UD限制适用于IBA不可靠多播。

### **10.5.2.2 原始数据报多播工作请求**

原始数据报多播工作请求必须通过Post Send Request Verb提交到单个目的地多播地址。此目标多播地址被指定为Post Send Request Verb的修饰符。任何原始数据报QP都可以用来发起原始数据报多播工作请求。

Send是原始数据报发送工作队列上唯一允许的操作。

不允许进行原子和RDMA操作。原始数据报消息不应大于请求者和响应者之间的PMTU。原始限制（raw restrictions ）适用于原始数据包多播。

## **10.5.3 多播目的地建立**

多播组由MGID定义。

o10-35：如果CI支持IBA不可靠组播，那么如果目的QP号不是0xFFFFFF，则CI应丢弃所有IBA不可靠组播包。

虽然目的QP号0xFFFFFF用于地址句柄和组播报文中不可靠的组播组，但是任何有效的QP号正确地附着在正确的组播组上，就可以使用其来接收该组播。

创建和销毁多播组是fabric管理问题。允许节点加入和离开多播组是一个fabric管理问题。多播组的MTU是创建多播组时指定的MTU，是多播MAD中的一个参数。

o10-36：如果CI支持IBA不可靠多播，则向发送节点内QP连接的多播组发送IBA不可靠多播消息的多播环回必须得到CI的支持。

与多播接收一样，原始数据包多播的环回取决于HCA支持的每个端口的原始数据包队列对的数量。如果HCA每个端口只支持每种类型的一个原始队列对，则不执行环回；在这样的QP上发送的多播消息不会在同一个QP上接收。如果一个HCA支持每个端口每种类型的多个原始QP，那么在一个端口上发送的多播消息可能会在另一个端口上接收，也可能不会在另一个端口上接收；详细信息是IBA范围之外的实现定义的策略。

# **10.6 内存管理**

## **10.6.1 概述**

InfiniBand体系结构提供复杂的高性能操作，如远程DMA和用户模式IO。为了实现这个目标，InfiniBand体系结构必须指定适当的内存管理机制。最重要的目标是性能、鲁棒性和简单性。

## **10.6.2 内存注册**

HCA，如典型的I/O总线主机桥接，使用本规范所指的物理内存地址访问主机系统内存。主机系统内存的物理地址空间通常被组织成大小固定或变化的页，而跨越页边界的给定逻辑数据缓冲区通常具有非连续的物理地址范围。

内存注册提供了一些机制，允许使用者向通道接口描述一组虚拟连续的内存位置或一组物理上连续的内存位置，以便允许HCA使用虚拟地址作为虚拟连续的缓冲区来访问它们。

**所有使用者必须显式地注册包含数据缓冲区的内存位置，然后HCA才能访问它们。**

C10-44：本合规声明已作废。

C10-44.2.1：如果CI不支持本规范中定义的基本内存管理扩展，并且CI处理试图访问尚未注册的内存位置的WR或传入RDMA或原子请求，则CI不得执行访问，并且CI必须返回适当的错误。

o10-36.2.1：如果CI支持本规范和CI中定义的基本内存管理扩展：

◼ 处理一个WR，该WR试图访问使用保留L_Key的内存位置，但QP禁止使用保留L_Key，则CI不能执行访问，并且CI必须返回适当的错误

◼ 处理Post Send Queue WR，该队列试图通过快速注册物理MR(Fast Register Physical MR)注册内存位置，但QP禁止使用快速注册物理MR，则CI不能执行访问，并且CI必须返回适当的错误

◼ 处理一个传入的Send、RDMA或原子请求，该请求试图访问没有有效注册的内存位置（即处于无效或空闲状态），则CI不能执行访问，并且CI必须返回适当的错误。

由于必要的信道接口资源不可用，注册可能会失败。在这种情况下没有注册内存。

C10-45：注册必须以原子方式完全成功或失败/Registration must either fully succeed or fail in an atomic fashion。

### **10.6.2.1 内存区域/Memory Regions**

已注册的内存位置的集合称为内存区域。

**内存注册操作的结果是：**

◼ MemoryRegionHandle/内存区域句柄

内存注册Verbs生成一个MemoryRegionHandle，用于为Memory Management Verbs标识特定的内存区域。

◼ L_Key

Memory Registration Verbs产生一个L_Key。在工作请求的数据段中，使用L_Key和位于该区域边界内的虚拟地址，以标识CI在特定内存区域内的内存位置。

◼ R_Key

Memory Registration Verbs在请求时生成R_Key。在RDMA和原子操作中，R_Key和位于该区域边界内的虚拟地址一起用于将特定内存区域内的内存位置标识给CI。

◼ 虚拟地址（VA）和基于零的虚拟地址（ZBVA，Zero Based Virtual Address）

Memory Registration Verbs提供（或在某些情况下生成）虚拟地址或基于零的虚拟地址。两者都对应于提供给Memory Registration Verbs的内存位置集中的第一个内存位置。但是，对于虚拟地址，内存区域的第一个内存位置必须具有虚拟地址模第一个物理缓冲区的缓冲区大小等于第一个字节偏移量。对于零开始的虚拟地址，MR的第一个内存位置的虚拟地址为零。

当注册一个内存区域时，消费者指定在内存注册或快速注册物理MRs中要保留以供将来使用的最大内存位置数，以便更详细地描述与内存注册相关联的属性，请参阅**第11.2.10章“内存管理”**中的各种内存注册verbs。

C10-45.2.1：CI必须允许内存注册和内存窗口使用虚拟地址。

o10-36.2.2：如果CI支持基于零的虚拟地址（Zero Based VAs），则CI必须：

◼ 允许基于VA的内存窗口绑定到基于VA的内存区域

◼ 允许基于零的虚拟地址内存窗口绑定到基于VA的内存区域，并且

◼ 如果使用者尝试将内存窗口绑定到基于零的虚拟地址内存区域，则返回错误。

### **10.6.2.2 内存注册资源分配**

L_Key的分配允许特权使用者与CI一起保留内存注册资源，以便将来的内存区域注册使用。L_Key分配是通过Allocate L_Key Verb进行的。

分配L_Key的结果为：

◼ MemoryRegionHandle

MemoryRegionHandle，用于标识内存管理Verbs的特定L_Key。

◼ L_Key

Allocate L_Key Verb产生一个L_Key。在通过以下方式注册之前，L_Key不会与内存区域相关联：Reregister Memory Region、Reregister Physical Memory Region或Fast Register Physical MR。

◼ R_Key

Allocate L_KeyVerbs在请求时生成一个R_Key。R_Key在通过以下方式注册之前不会与内存区域关联：Reregister Memory Region、Reregister Physical Memory Region或Fast Register Physical MR。

分配内存注册资源时，使用者指定要保留以供将来在内存中注册使用的**物理缓冲区列表项**的最大数量（请参阅**第10.6.4.4.1节“物理缓冲区列表”**）。如需有关Allocate L_Key Verbs相关属性的更详细说明，请参阅**第11.2.10.1节 “分配L_Key”**。

### **10.6.2.3 内存区域类型**

内存区域有两种类型：非共享内存区域和共享内存区域。

◼ 非共享内存区域

n 非共享内存区域具有与一组不共享的物理内存位置关联的有效内存注册。非共享内存区域是通过以下Verbs创建的：Register Memory Region、Register Physical Memory Region和Fast Register Physical MR。如果转换发生更改，也可以通过Reregister Memory Region或Reregister Physical Memory Region创建非共享内存区域。

◼ 共享内存区域

n 共享内存区域具有与共享的一组物理内存位置关联的有效内存注册。从注册共享内存区域Verb成功返回时：输出内存区域是共享内存区域，输入内存区域成为共享内存区域。如果转换发生更改，则通过重新注册内存区域和重新注册物理内存区域，将共享内存区域转换为非共享内存区域。将共享MR更改为非共享MR不会影响共享PBL的其他MR的状态。

内存区域用于引用非共享内存区域和共享内存区域。

每个存储区域的L_Key或R_Key都有三种可能的状态：

◼ 无效状态——没有为L_Key或R_Key分配任何资源。无法使用处于无效状态的L_Key或R_Key访问主机内存。处于无效状态的L_Key或R_Key无法通过使用Send with Invalidate使其无效。

◼ 空闲状态——**物理缓冲区列表**和PD已与L_Key或R_Key关联，但L_Key或R_Key与内存区域不关联。处于空闲状态的L_Key或R_Key不能用于访问主机内存。在Free State中的L_Key或R_Key可以通过Send with Invalidate使其无效。

◼ 有效状态——L_Key或R_Key与内存区域关联。处于有效状态的L_Key或R_Key可用于访问主机内存。处于有效状态的L_Key或R_Key可以通过使用Send with Invalidate而失效。

下表总结了内存区域L_Key和R_Key的状态以及每个状态允许的操作：

下表总结了通过Verbs和远程操作（非Verbs操作用斜体标出）的内存区域L_Keys和R_Keys状态转换：

a注意：作为重新注册MR或Reregister PMR的输出返回的MR可能是现有MR或新MR。如果返回现有MR，则将其置于有效状态。如果返回新MR，则现有MR将处于无效状态，而新MR处于有效状态。上表是指在重新注册MR或重新注册PMR上重用MR时现有的MR状态转换。

注意，当通过本地失效WR或传入的Send with Invalidate操作（Remove Invalidate）成功使一个内存区域失效时，与该存储区域相关联的L_Key和R_Key（如果有）都处于空闲状态。有关无效L_Key的说明，请参见**第10.6.5节**。

o10-36.2.3：如果CI支持基本内存管理扩展，则CI必须允许将非共享内存区域用作以下Verbs的输入修饰符：重新注册内存区域、查询内存区域、重新注册物理内存区域、注册共享内存区域、绑定内存窗口、发送后队列绑定工作请求，快速注册物理MR，注销MR。

o10-36.2.4：如果CI支持基本内存管理扩展，则CI必须允许将共享内存区域用作以下Verbs的输入修饰符：重新注册内存区域、查询内存区域、重新注册物理内存区域、注册共享内存区域、绑定内存窗口、发送后队列绑定WR（Post Send Queue Bind Work Request）和取消注册。

o10-36.2.5：如果CI支持基本内存管理扩展，则如果共享内存区域用作快速注册物理MR或本地失效的输入修饰符，则CI必须返回错误。

## **10.6.3 访问注册内存**

C10-46：CI应支持以下访问权限：本地读取、本地写入、远程读取和远程写入。

o10-37：如果CI支持原子操作，则CI应支持远程原子访问权。

### **10.6.3.1 注册内存的本地访问**

内存区域始终可由注册的本地HCA访问（即，本地HCA是与使用者位于同一主机系统中的HCA），允许的访问类型取决于分配给该内存区域的访问权限。

C10-47：CI应自动在每个Memory Region的访问权限中包含本地读取。

使用者可以请求将本地写入权分配给**存储区域的访问权限**。如果需要，与防止将本地写入分配给内存区域有关的策略可以由使用者实现。

### **10.6.3.2 注册内存的远程访问**

除了本地访问权限外，用户还可以向内存区域分配远程访问权限。远程访问权限包括远程读取、远程写入和远程原子。远程访问权限可单独选择，选中后，允许一个或多个特定操作类型访问内存区域。不允许使用者将远程写入或远程原子操作分配给尚未分配本地写入的内存区域。

C10-48：如果内存注册指定远程写入或远程原子而不指定本地写入，则CI必须返回一个Immediate Error。

### **10.6.3.3 本地访问密钥**

当资源被分配以保存一组内存位置时，CI会为其创建一个名为L_ Key的对象并将其返回给使用者。L_ Key与将与用于保存一组内存位置的保留资源相关联。它被认为是一个可用的L_ Key，因为它不与任何内存区域相关联。从Allocate L_ Key返回的L_Key可用作快速注册PRM的输入修饰符，以将L_Key与内存区域相关联。

还可以通过以下内存注册Verbs创建L_ Key：Register Memory Region、Reregister Memory Region、Register Physical Memory Region、Register shared Memory Region。

当一组内存位置被注册时，在注册中使用的L_ Key与所注册的内存位置集相关联。与一组特定的内存位置相关联的L_ Key被认为处于有效状态。快速注册物理MR不创建L_ Key，它只是将现有的空闲L_ Key与一组内存位置相关联。

从内存注册返回的L_ Key可以用作重新注册内存区域、重新注册物理内存区域、Post Send Local Invalidate WR、绑定内存窗口、Post Send Queue Bind Work Request、共享内存区域和快速注册物理MR的输入修饰符。

o10-37.2.1：如果CI支持本规范中定义的基本内存管理扩展，则L_ Key格式必须包括：

◼ L_ Key最高24位索引，以及

◼ 8位密钥在L_ Key的最低有效位。

o10-37.2.2：如果CI支持此规范中定义的基本内存管理扩展，则当创建L_ Key时：

◼ 通过成功的Allocate L_ Key Verbs调用，CI必须让使用者拥有返回的L_Key的密钥部分(key portion)

◼ 通过成功的Register Memory Region、Reregister Memory Region或Register Shared Memory Region Verbs调用，CI不得让使用者拥有返回的L_key的密钥部分(key portion)

◼ 通过成功的Register Physical Memory Region或Reregister Physical Memory Region Verbs调用，CI必须让使用者在拥有L_ Key的密钥部分(key portion)由使用者拥有或由CI拥有之间进行选择。

注意，L_ Key的索引部分始终由CI拥有。

通过以下方式向CI描述内存区域以进行本地访问：

◼ 该内存区域内的虚拟地址与注册该区域时返回给消费者的L_ Key的组合；或者

◼ 如果CI支持本规范中定义的ZBVA扩展，则为该内存区域内的偏移量和注册该区域时返回给使用者的L_ Key的组合。

### **10.6.3.4 远程访问密钥**

当分配资源以保存一组内存位置和用户选择的远程访问启用时，CI将创建一个名为R_Key的对象并将其返回给使用者。R_ Key与将用于与保存一组内存位置的保留资源相关联。它被认为是一个可用的R_ Key，因为它与任何内存区域都没有关联。从Allocate L_ Key返回的R_ Key可用作快速注册PMR的输入修饰符，以将R_ Key与内存区域关联起来。

还可以通过以下内存注册Verbs创建内存区域R_ Key：注册内存区域、重新注册内存区域、注册物理内存区域、重新注册物理内存区域和注册共享内存区域。

当使用远程访问权限注册一组内存位置时，在注册中使用的R_ Key与已注册的内存位置集相关联。与一组特定的内存位置关联的R_ Key被视为处于有效状态。快速注册物理MR不创建R_ Key，它只是将现有的空闲R_ Key与一组内存位置相关联。

从本地内存注册返回的R_ Key可用作重新注册物理内存区域、Post Send Local
Invalidate WR和快速注册物理MR的输入修饰符。本地使用者可以使用以前由远程使用者公开的R_ Key作为具有本地无效WR的Post Send的输入修饰符。

o10-37.2.3：如果CI支持本规范中定义的基本内存管理扩展，则R_ Key格式必须包括：

◼ R_ Key最高24位索引，以及

◼ 8位密钥R_ Key的最低有效位。

o10-37.2.4：如果CI支持此规范中定义的基本内存管理扩展，则当创建用于内存注册Verbs的R_ Key时：

◼ 通过成功的Allocate L_ Key Verbs调用，CI必须让使用者拥有返回R_Key的密钥部分

◼ 通过成功的Register Memory Region、Reregister Memory Region或Register Shared Memory Region verbs词调用，CI不得让使用者拥有返回R_Key的密钥部分

◼ 通过成功的Register Physical Memory Region或Reregister Physical Memory Region verbs调用，CI必须让使用者在R_ Key的密钥部分由使用者拥有或由CI拥有之间进行选择。

请注意，R_ Key的索引部分始终由CI拥有。

注意：对于具有关联R_Key的L_Key，如果R_Key是消费者拥有的，则R_Key的密钥部分必须等于L_Key的密钥部分。此外，R_Key和L_Key都由使用者拥有；或者两者都由CI拥有。所有权不能混为一谈。

通过以下方式向CI描述内存区域以进行远程访问：

◼ 内存区域中的虚拟地址与注册区域时返回给消费者的R_Key的组合；或者

◼ 如果CI支持本规范中定义的ZBVA扩展，则内存区域中的偏移量和注册区域时返回给消费者的R_Key的组合。

### **10.6.3.5 保护域**

**保护域（PD）关联内存区域和队列对**。保护域特定于每个HCA。每个内存区域必须与单个保护域相关联。多个存储区域可以与同一PD相关联。HCA中的每个队列对必须与单个保护域相关联。多个队列对可以与同一PD关联。只有当内存区域的保护域和正在处理请求的队列对的保护域相同时，才允许访问工作请求和远程操作请求中描述的内存区域。保护域的设置预期由特权使用者控制。

### **10.6.3.6 访问范围**

内存被注册用于特定的HCA。L_Key和R_Key特定于HCA，不允许其他本地HCA访问内存区域。CI不需要强制要求与一个HCA关联的L_Key或R_Key在与不同的HCA一起使用时总是会导致错误。

### **10.6.3.7 快速注册**

创建QP时，特权消费者可以请求在QP上启用快速注册。如果启用了快速注册，则CI必须允许消费者执行快速注册（即快速注册物理MRs）。如果QP未启用快速注册，并且消费者尝试执行快速注册，则CI必须返回内存管理操作错误。

快速注册将一个可用的L_Key与一组内存位置相关联（参见**第10.6.4.4.1节 “物理缓冲区列表”**，了解如何使用物理缓冲区列表来引用主机内存位置）。如果free L_Key有一个附带的free R_Key，并且消费者请求远程访问权限，则快速注册将R_Key与一组内存位置相关联。

o10-37.2.5：对于支持基本内存管理扩展的HCA，CI必须在以下情况下返回错误：

◼ 通过快速注册传入的内存位置集不小于或等于创建快速注册中使用的L_Key的Verb为内存位置保留的资源

◼ 与通过快速注册传入的L_Key相关联的PD与执行快速注册的QP相关联的PD不同

◼ 执行快速注册的QP没有启用快速注册

◼ 通过快速注册传入的L_Key处于无效或有效状态；或

◼ 使用者请求远程访问，但R_Key未启用。

o10-37.2.6：如果HCA支持基本内存管理扩展，则必须在启动同一发送队列上的任何后续工作请求之前进行快速注册。

注意，在HCA开始处理任何后续的WQE之前，消费者可能依赖于快速注册完成。发布成功后，如果快速注册失败，则QP进入Error state并刷新所有后续WQE。

当成功完成快速注册时：

◼ 由于内存注册已成功应用于空闲状态的L_Key，因此认为该L_Key处于有效状态；并且

◼ 如果快速注册：

✸ 请求了一个R_Key，而空闲状态L_Key有一个附带的空闲状态R_Key，则R_Key被视为处于有效状态，因为内存注册已成功应用于空闲状态R_Key。

✸ 没有请求R_Key，但R_Key与L_Key相关联（例如，分配L_Key Verb返回了一个R_Key），则远程节点将不允许通过R_Key访问内存区域。

当快速注册未成功完成时，L_Key及其关联R_Key的状态不受影响。

### **10.6.3.8 内存区域的多次注册**

同一组内存位置可能会被多次注册，从而产生多个Memory Region Handles、L_Key和R_Key。每个注册被认为是一个独立的和不同的内存区域，并且可以独立地与保护域相关联。

C10-49：CI应支持部分或完全重叠的内存位置集的独立注册。

对于需要对一组特定的内存位置进行多个注册的情况，提供了用于优化信道接口资源的使用的规定。请参阅**第11.2.10.8节“注册共享内存区域”**。

## **10.6.4 内存寻址/Addressing Memory**

### **10.6.4.1 虚拟地址（“指针”）**

某些处理器体系结构支持80位或更多的全局虚拟地址空间。然而，大多数应用程序可以很容易地操作和提供虚拟地址（“指针”），因为参数通常是32位或64位，并且该位数实际上用作与进程相关联的少数处理器内存“段”的偏移量。因此，在Verbs层由使用者传入的虚拟地址参数必须在其关联进程的适当上下文中进行解释。每个虚拟地址参数及随附的L_Key或R_Key有助于CI识别适当的上下文。

在本规范中，消费者操作和作为参数传入的虚拟地址（“指针”）被简单地称为虚拟地址。用于指定要注册的内存区域和工作请求中的本地内存位置的虚拟地址的大小取决于实现。用于在工作请求中指定远程内存位置的虚拟地址的大小为64位。

### **10.6.4.2 虚拟到物理的转换**

### **10.6.4.3 虚拟地址区域的注册**

一组几乎相邻的内存位置由一个虚拟地址指定，该虚拟地址指向该集合的第一个字节和以字节为单位的集合长度。图128显示了一个由三个物理页支持的几乎连续的内存位置集的示例。返回区域的页面大小取决于主机系统硬件和主机操作系统。

图中的页数为4096字节。实际页面大小取决于主机硬件和主机操作系统。

在上面的例子中，可以允许访问**虚拟地址**0x141000到0x1411FF（比0x141200少1字节）的内存位置，即使它们接收到请求的是注册区域的第一个地址。

#### **10.6.4.3.1 从零开始的虚拟地址（ZBVA）存储区域的注册**

ZBVA内存区域的第一个字节被分配一个**零虚拟地址**。ZBVA内存位置集由从零开始的偏移量指定，该偏移量表示ZBVA的开始位置，以及以字节为单位的集合长度。ZBVA内存区域中使用的虚拟地址没有任何相关的处理器上下文。

#### **10.6.4.3.2 保留的L_Key**

如果CI支持基本内存管理扩展，则使用者可以使用保留的L_Key来标识Post Send和Post Receive的工作请求数据段(Post Send and Post Receive Work Request Data Segments)。通过L_Key引用的数据段由指向数据段开始和数据段长度的物理地址引用。

保留的L_Key用于特权模式使用者的本地使用。创建QP时，使用者必须通过快速注册物理MRs和**Reserved L_Key**启用或禁用内存访问。

o10-37.2.7：对于支持基本内存管理扩展的CI，如果使用者通过Create QP启用快速注册物理MR和**保留L_Key**访问，则在该QP上，CI必须允许使用者：

◼ 在WRs中使用保留的L_Key，以及

◼ 使用快速注册物理MRs。

请注意，**保留L_Key**是本地密钥，无法通过保留的L_Key执行远程访问。

o10-37.2.8：对于支持基本内存管理扩展的CI，如果使用者试图：将内存窗口绑定到保留的L_Key、使保留的L_Key无效、销毁保留的L_Key或使用Reserved L_Key的任何类型的注册，则CI必须返回错误。

#### **10.6.4.3.3 字节对齐和内存区域长度**

C10-50：CI应支持正在注册的虚拟连续缓冲区的任意字节对齐。

C10-51：CI应支持正在注册的虚拟连续缓冲区的任意长度不超过HCA属性指定的限制。

该区域的地址转换和访问权限适用于该内存区域内的每个完整物理缓冲区。

◼ 如果HCA不支持基本内存管理扩展，则不需要CI为具有字节级粒度的本地或远程访问强制执行访问检查和权限。

◼ 如果HCA支持基本内存管理扩展，则需要CI以字节级粒度强制执行本地和远程访问的访问检查和权限。

#### **10.6.4.3.4 注册内存驻留/Residency**

c10-52：本合规声明已作废。

C10-52.2.1：使用本规范中定义的Verbs，当通过注册内存区域和重新注册内存区域注册内存区域时，CI必须在物理内存中锁定内存区域内的每个物理缓冲区。

在调用Register Physical Memory Region或Reregister Physical Memory Region Verbs之前，使用者应该在物理内存中锁定内存区域内的每个物理缓冲区。

如果HCA支持基本内存管理扩展，当通过快速注册PMR注册一个内存区域时，使用者应该在物理内存中锁定内存区域中的每个物理缓冲区。

在物理内存中锁定内存区域内的每个物理缓冲区向HCA保证该内存区域在物理上驻留（而不是交换出去），并且在该区域被注册时，虚拟到物理地址的转换保持不变。

注册内存区域和重新注册内存区域Verbs负责请求操作系统锁定相关物理缓冲区，并请求操作系统为每个物理缓冲区提供任何所需的虚拟到物理地址转换信息。不需要通道接口来跟踪多个注册共用的物理缓冲区。通道接口必须能够假定接受固定和解除固定物理缓冲区请求的操作系统服务将维持这些物理缓冲区上的适当引用计数，这样在解除固定请求的数量等于该数量之前，固定的物理缓冲区不会被实际解除固定任何特定物理缓冲区的锁定(pin)请求。

注册内存区域和重新注册内存区域 Verbs每次注册一个区域时，都要求操作系统锁定与该区域关联的物理缓冲区，而不管与以前注册的区域有任何关联。不禁止通道接口执行优化，以减少它为固定和取消固定内存而产生的操作系统服务请求的数量。

### **10.6.4.4  物理地址区域的注册**

作为通过处理器映射的用户在虚拟地址空间中指定连续范围区域的替代方法，特权用户可以通过物理地址缓冲区列表来指定区域，这些缓冲区与HCA可映射的物理缓冲区相对应。使用者还提供第一个字节偏移量，该偏移量指定区域在第一个物理缓冲区内的起始位置。

物理寻址区域有两种类型：基于VA的“I/O虚拟地址”和基于零的“I/O虚拟地址”。

◼ 对于基于VA的IOVA，使用者提供一个请求的“I/O虚拟地址”以与区域的第一个字节相关联，该字节可以在第一个物理缓冲区内的任何地方开始。通道接口返回实际分配给区域的I/O虚拟地址。不支持基本内存管理扩展的通道接口不需要分配由使用者请求的I/O虚拟地址，但鼓励尽可能这样做。支持基本内存管理扩展的通道接口必须分配使用者传入的IOVA。如果缓冲区大小与缓冲区管理模式相匹配，则必须首先检查缓冲区的基字节和缓冲区大小。

◼ 对于支持基本内存管理扩展的通道接口上基于零的IOVA，允许在第一个物理缓冲区内的任何地方开始的区域的第一个字节被分配给零地址。

消费者还提供该区域的字节长度。区域的最后一个字节（由区域长度指定）必须位于最后一个物理缓冲区内，但允许位于最后一个物理缓冲区内的任何位置。

此上下文中的虚拟地址称为“I/O虚拟地址”，因为根据CI支持的内存管理扩展，它可能不会映射到处理器的虚拟地址空间中，并且可能仅用于HCA执行的本地或远程访问。

I/O虚拟地址的最大大小为64位。

#### **10.6.4.4.1物理缓冲区列表**

C10-53：本合规性声明已作废。

支持两个物理缓冲区列表：页列表和块列表。

用于注册的页列表由一个或多个物理上连续的内存位置集组成，这些内存位置必须以CI支持的页边界开始和结束。

C10-53.2.1：如果物理内存注册中的页列表包含的元素不以CI支持的页边界开始和结束，则CI将返回错误。

o10-37.2.9：用于注册的块列表由一个或多个物理上连续的内存位置集组成，这些内存位置可能具有任意的byte alignment（字节对齐方式），但必须全部具有相同的大小

Allocate L_ Key Verb保留物理缓冲区列表项，以便在将来的内存区域注册中使用。

o10-37.2.10：如果CI支持基本内存管理扩展，则CI必须从以下Verbs中返回为物理缓冲区保留的大小列表：Allocate L_ Key、Query Memory Region、Register Physical Memory Region和Reregister physical Memory Region。

物理缓冲区列表中的所有物理缓冲区都必须保持可供CI访问的状态，直到区域无效或注销。

对于物理缓冲区列表中的物理缓冲区实际上是虚拟寻址缓冲区的固定物理缓冲区的情况，使用者应该在注册区域的同时保持这些物理缓冲区的固定。

使用者有责任在注销后确定是否以及何时取消固定物理缓冲区。如果物理寻址区域中的物理缓冲区也在已注册的虚拟寻址区域中使用，则使用者有责任确保正确操作。

### **10.6.4.5 内存区域错误检查**

使用者使用内存区域中注册位置之外的虚拟地址是一种错误。

#### **10.6.4.5.1 本地访问内存区域的错误检查**

C10-54：此符合性声明已被废弃。

o10-37.2.11：对于Reserved L_Key，CI必须确保QP上启用Reserved L_Key访问。

C10-54.2.1：如果CI不支持SRQ，则需要CI确保使用虚拟地址和L_Key引用的内存位置位于内存区域的物理缓冲区内，其PD与正在处理WR的QP具有相同的PD。

o10-37.2.12：如果CI支持SRQ

◼ 对于不与SRQ相关联的QP或与SRQ相关联的QP的发送队列，需要CI来确保使用虚拟地址和L_Key引用的内存位置位于与正在处理WR的QP具有相同PD的内存区域的物理缓冲区内，以及

◼ 对于与SRQ相关联的QP的接收队列，需要CI来确保使用虚拟地址和L_Key引用的内存位置位于具有与SRQ相同PD的内存区域的物理缓冲区内。

允许CI支持更精细的本地访问控制粒度。

一般来说，CI将对工作请求中指定的每个数据段执行虚拟地址和适当的内存键（L_Key或R_key）的有效性检查。此规则的例外情况如下：

C10-54.1.1：CI不应对零长度数据段执行任何保护检查。

C10-54.1.2：对于不包含GRH、UC消息、RC消息和RD消息的UD消息，CI在收到零长度消息时，不应对工作请求中指定的任何数据段执行任何本地保护检查。对于包含GRH的UD消息，CI应执行数据段检查，如果检查通过，则显示GRH。如果检查不通过，就会出现一个完成错误。

C10-55：需要CI来确保该内存区域的本地访问权限允许请求的访问类型。

强烈建议通道接口检查并确保虚拟地址在与L_Key相关联的内存区域内，并在访问时报告任何边界冲突。通道接口不强制执行这种检查。

#### **10.6.4.5.2 对内存区域远程访问的错误检查**

C10-56：需要CI来确保使用虚拟地址和R_Key引用的内存位置位于与处理远程操作的QP相同PD的内存区域内。CI应以不超过4096字节的粒度执行此操作。

C10-57：需要CI来确保该内存区域的远程访问权限允许请求的访问类型。

强烈建议通道接口检查并确保虚拟地址位于R_Key关联的内存区域内，并在访问时报告任何边界冲突。通道接口不强制执行这种检查。

## **10.6.5 内存区域失效**

当消费者不再需要访问物理内存区域，而是希望保留L_Key和R_Key（如果R_Key随L_Key一起使用），以供将来的内存注册使用时，消费者可以通过以下方式使内存区域失效：

◼ 本地Post Send Local Invalidate WR，或

◼ 远程发送无效操作/remote Send with Invalidate Operation。

**本地或远程失效操作成功完成后，L_Key将处于空闲状态**。在这种状态下，L_Key不能再用于访问本地内存，但它仍然分配了物理缓冲区列表资源。

同样，在本地或远程失效操作成功完成后，R_Key将处于空闲状态。在这种状态下，R_Key不能再用于访问本地内存，但它仍然分配了物理缓存列表资源。

对于本地失效，使用者必须为要失效的内存区域提供L_Key、R_Key和内存区域句柄。CI可以使用这三种方法中的任何一种来执行失效操作。CI不应在这三个输入修饰符之间执行一致性检查。对于带Invalidate的出站发送，使用者必须为要失效的远程内存区域提供远程R_Key。

已注册多次的内存位置将由多个内存区域表示。单个内存区域的失效阻止HCA通过与该内存区域相关联的L_Key（以及伴随的R_Key，如果有的话）访问这些内存位置。通过与其他内存区域相关联的L_Key和R_Key访问内存位置不受影响。

o10-37.2.13：如果支持基本内存管理扩展，则CI必须：

◼ 支持本地Local Invalidate WRs和传入Send with Invalidate

◼ 如果尝试对通过以下方式创建的内存区域执行无效操作，则返回错误：注册内存区域、重新注册内存区域，以及注册共享内存区域Verbs

◼ 如果试图对用作成功注册共享内存区域的输入修饰符的内存区域执行无效操作，则返回错误

◼ 支持部分或完全重叠的注册内存区域的独立失效。

o10-37.2.14：如果支持基本内存管理扩展，则正在处理并主动引用无效内存区域中内存位置的工作请求或远程操作请求必须失败并保护违例(protection violation)。

o10-37.2.15：如果支持基本内存管理扩展，则尝试使共享内存区域无效的工作请求必须失败，并出现内存管理操作错误。

o10-37.2.16：如果支持基本内存管理扩展，则尝试使共享内存区域无效的传入Send with Invalidate操作必须失败。

o10-37.2.17：如果支持基本内存管理扩展，如果内存区域仍有内存窗口绑定，则本地和远程无效内存区域必须失败。

o10-37.2.18：如果支持基本内存管理扩展，则尝试访问已失效的内存区域中的内存位置的工作请求或远程操作请求必须因保护违例(protection violation)而失败。

注意，失效操作只允许在非共享物理内存区域上进行。因此，消费者应该协商与MR相关联的密钥是否可以无效。

下表总结了快速注册和内存区域无效（Invalidation of Memory Regions）的基本规则：

### **10.6.5.1 失效排序/Invalidation Ordering**

允许两个层次的局部失效排序：松弛排序和强排序（Relaxed ordered and Strongly ordered）.

o10-37.2.19：**松弛排序**——失效操作可以在它被发布到发送队列之后的任何时候发生，但是必须在生成完成之前和任何后续WQE开始执行之前进行。

o10-37.2.20：如果CI支持**本地失效防护（Local Invalidate Fencing）：**强排序**——失效操作必须在同一发送队列上的所有之前的WQE完成之后，并且在同一发送队列上的下一个WQE（在失效之后立即）开始执行之前进行。

o10-37.2.21：对于传入的Send with Invalidate——操作可以在接收消息和完成消息之间的任何时间进行。必须在所有以前的非RDMA读取消息完成处理后执行invalidate操作。Invalidate操作对针对同一连接的后续消息没有任何排序。注意，针对同一连接的后续消息可能会在失效发生之前部分或完全执行。

注意，当本地CA上出站的Send with Invalidate操作完成时，无法保证远程CA成功完成远程Invalidate。但是，当通过工作完成返回Send Data Received，并且发送操作是Send with Invalidate时，（传入）失效保证已完成。

o10-37.2.22：如果CI支持基本内存管理扩展，那么对于非共享PMR，CI必须支持放松的失效排序，并且不必支持本地失效防护。

o10-37.2.23：如果CI支持**本地失效**防护**，那么对于非共享PMR，CI必须支持：

◼ 当使用者在本地失效WR上设置本地失效界限时，**强失效排序**；以及

◼ 当使用者没有在本地失效WR上指定本地失效界限时，**松弛失效排序**。

o10-37.2.24：对于非共享PMR，如果响应程序CI支持基本内存管理扩展，并且在传入的带有Send with Invalidate的R_Key检查失败，则在响应程序：

◼ R_Key不能失效

◼ 传入的Send with Invalidate必须生成一个完成错误，并且

◼ 相关联的QP必须处于错误状态。

## **10.6.6 区域注销**

当不再需要CI访问内存区域时，消费者可以撤销该区域的注册过程。**注销内存区域**的过程将撤消对该内存区域的所有HCA访问权限。

已注册多次的内存位置将由多个内存区域表示。取消注册单个存储区域阻止HCA通过与该存储区域相关联的L_Key（和R_Key，如果有的话）访问这些内存位置。通过与其他内存区域相关联的L_Key和R_Key访问内存位置不受影响。

C10-58：CI应支持部分或完全重叠的内存注册区域的独立注销。

C10-59：处理中的工作请求或远程操作请求，以及主动引用已取消注册的内存区域中的内存位置的请求必须失败，并出现保护冲突(protection violation)。

C10-60：试图访问已取消注册的内存区域中的内存位置的工作请求或远程操作请求必须因保护冲突而失败。

如果在注册内存区域时执行了锁定这些物理缓冲区的请求，则导致取消注册内存区域的Verbs将请求操作系统取消与该区域关联的页的固定，而不管与先前注册的区域有何关联。不禁止通道接口实现优化，以减少它对内存进行限制和取消锁定的操作系统服务请求的数量。

## **10.6.7 内存访问控制**

操作系统中每个内存注册相关Verbs的直接使用者是特权代码。一般来说，操作系统负责为它代表用户级用户进行的内存注册确定并强制执行访问控制策略。例如，预计操作系统会执行类似于以下的策略，但不是必须的：

◼ 用户级使用者可以控制HCA数据传输操作访问内存区域。

◼ 用户级使用者可以启用它可以访问的任何本地内存区域，以供HCA数据传输操作访问。

◼ 用户级使用者无法对使用者本身没有读取权限的内存区域启用HCA读取存取权。

◼ 用户级使用者无法启用对使用者本身没有写访问权限的内存区域的HCA写访问权限。

当使用者（通过适当的Verbs）创建QPs或CQs时，HCA驱动程序自动分配并锁定相关控制结构所需的任何本地内存。HCA对这些控制结构的访问是隐式启用的。使用者只能通过Verbs间接地支持使用者对这些控制结构的存取，而且控制结构的任何区域控制项或L_Key（如果存在的话）都不会公开给使用者。

消费者通过使用保护域（PDs）控制哪些QPs可以访问哪些内存区域和哪些内存窗口。在创建任何QP、注册任何内存区域或分配任何内存窗口之前，使用者将分配一个或多个PDs。然后，当创建QP、注册内存区域或分配内存窗口时，使用者指定与它们相关联的PD。QPs只能访问位于同一PD中的内存区域或内存窗口。

### **10.6.7.1 本地访问控制**

通过发送和接收，使用者明确指定通过其在相关工作请求中传递的本地数据段访问的缓冲区。每个本地数据段都包含一个地址、它的相关联的L_Key和一个长度参数。如果需要**分散/聚集操作(scatter/gather)**，则可以为每个发送或接收提供多个本地数据段。

本地数据段还用于RDMA写入聚集列表、RDMA读取分散列表和AtomicOp返回值。同样，每个本地数据段都包含一个L_Key，该密钥控制对相应本地内存区域的本地访问。但是，与RDMA Write、RDMA Read或AtomicOp关联的远程数据段将包含一个R_Key而不是一个L_Key。这将在下面进一步讨论。

两种类型的本地访问，读和写，与内存区域相关联。发送缓冲区和RDMA写入收集缓冲区需要本地读取访问权限。接收缓冲区、RDMA读分散缓冲区和AtomicOp返回缓存区需要本地写访问权限。

虽然只需要内存注册来强制对页级粒度的本地访问，但send、receive、RDMA Writes、RDMA Reads和AtomicOps使用的本地数据段指定字节起始地址和字节计数长度。因此，使用者对这些本地启动的操作访问的本地缓冲区仍然具有字节级的访问控制粒度。使用者可以确定使用查询内存区域Verbs执行的访问控制的实际范围。

### **10.6.7.2 远程访问控制**

当使用者希望允许远程代理使用RDMA写入、RDMA读取或AtomicOps访问其本地内存时，使用者必须明确启用远程访问，并向远程代理传递适当的R_Key，以便其在启动针对消费者（本地）内存的操作时使用。

使用者可以使用两种机制中的任何一种来启用对其内存的远程访问。第一种机制涉及在注册内存区域时启用远程访问。第二种机制首先分配内存窗口，然后将其绑定到现有内存区域。任何一种机制都会产生一个R_Key，该密钥具有指定内存区域的相关远程访问权限。

支持三种类型的远程访问——读、写和原子访问。RDMA Write需要远程目标上的写访问权限，RDMA Read需要远程目标上的读访问权限，AtomicOps需要远程目标上的原子访问权限。虽然可能不明显，但对于使用者来说，允许原子访问而不允许写访问可能是有意义的，因为体系结构并不要求原子操作相对于RDMA写入是原子的。

#### **10.6.7.2.1 远程访问直接使用内存区域**

注册内存区域时，特权用户通常可以为该区域指定任何远程访问权限组合，包括全部或None。但是，如果注册请求未指定对内存区域的本地写入访问权限，则如果指定了远程写入或远程原子访问，则CI将返回错误。

如果指定了任何远程访问权限，则Verbs将返回R_Key。此R_Key授予整个内存区域的指定远程访问权限，该权限由字节起始地址和字节长度限定，但通道接口实际实施的访问控制粒度允许高达4096字节。使用者可以确定使用查询内存区域Verb强制执行的访问控制的实际范围。强烈建议通道接口使用字节级粒度来实施访问控制。

#### **10.6.7.2.2 通过内存窗口进行远程访问**

**当用户需要更灵活地控制对其内存的远程访问时，用户可以使用内存窗口**。内存窗口适用于消费者：

◼ 希望以动态的方式授予和撤消对已注册区域的远程访问权限，与使用**取消注册/注册**或**重新注册**相比，性能损失更小。

◼ 希望向不同的远程代理授予不同的远程访问权限和/或在注册区域的不同范围内授予这些权限。

要使用内存窗口，使用者分配一个内存窗口，然后将其绑定到已启用用于内存窗口的现有内存区域的指定地址范围。该范围可以包括整个内存区域或它的任何几乎相邻的子集。内存窗口只能绑定到属于同一保护域的内存区域。

C10-61：CI对字节级粒度的内存窗口实施远程访问控制。

绑定内存窗口时，使用者可以请求该窗口的任何远程访问权限组合。但是，如果关联区域未启用本地写入访问，并且使用者请求对窗口进行远程写入或远程原子访问，则通道接口必须在绑定时或访问时返回错误。见**第10.6.7.2.7节“窗口绑定时的错误检查”**和**第10.6.7.2.8节“窗口访问时的错误检查”**。

C10-62：如果内存区域没有启用本地写入访问，如果内存窗口绑定请求指定对该区域的远程写入或远程原子访问，则CI应返回错误。CI应允许内存窗口的其他请求访问权限。

如果使用者不违反上述关于本地写入访问的规则，则在绑定窗口时允许并通常期望使用者在注册基础区域时启用远程访问权限。例如，使用者可能注册一个没有远程访问权限的区域，然后将一个或多个窗口绑定到显然会授予远程访问权限的区域。

**分配或取消分配内存窗口需要内核转换，因此会产生相关的软件开销**。绑定内存窗口是通过将工作请求发送到发送队列来执行的，在典型的实现中，这种方法所产生的软件开销要少得多。

C10-63合规性声明已作废。

C10-64：此符合性声明已被废弃。

C10-65：本合规声明已作废。

C10-66：本合规声明已作废。

当通过Allocate Memory Window Verb分配内存窗口时，如果CI支持基本内存管理扩展，则使用者选择**第10.6.7.2.3节“类型1内存窗口”**或**第10.6.7.2.4节“类型2内存窗口”**。

内存窗口不带任何限定符，用于引用类型1和类型2内存窗口。

**类型1内存窗口只能通过虚拟地址寻址**。**类型2内存窗口通过虚拟地址或从零开始的虚拟地址寻址**（有关VA和ZBVA的说明，请参阅**第10.6.2.1节 “内存区域”**）。

每个内存窗口R_Key有三种可能的状态：

◼ **无效状态**—没有为R_Key分配任何资源。处于无效状态的R_Key不能用于访问主机内存。处于无效状态的R_Key不能通过Send with Invalidate置为无效。

◼ **空闲状态**—R_Key与内存区域没有不关联，不能用于访问主机内存。处于空闲状态的R_Key可以通过Send with Invalidate使其失效。注：空闲状态可能不会在类型1内存窗口上实现（见表72）。

◼ **有效状态**—R_Key与内存区域关联。处于有效状态的R_Key可用于访问主机内存。处于有效状态的R_Key可以通过Send with Invalidate使其无效。

下表总结了类型1内存窗口R_Key的状态以及每个状态上允许的操作：

下表总结了类型2内存窗口R_Key的状态以及每个状态上允许的操作：

下表总结了通过Verbs和远程操作（非Verbs操作用斜体标记）的类型2内存Windows R_key状态转换：

#### **10.6.7.2.3 类型1内存窗口**

**类型1内存窗口通过**绑定内存窗口**V**erb**绑定**。CI拥有与类型1内存窗口关联的R_Key。

类型1内存窗口具有与InfiniBand体系结构规范第1卷Release1.1中定义的相同的PD访问控制语义。

C10-66.2.1：HCA必须支持类型1内存窗口。

C10-66.2.2：每次通过绑定内存窗口Verb绑定给定的类型1内存窗口时，CI都将返回一个R_Key，该键的值与前一个值不同。绑定操作完成后，任何使用前一个R_Key的访问尝试都必须失败。

当类型1内存窗口通过绑定内存窗口绑定时，Verbs在发布工作请求后立即返回新的R_Key，即使HCA执行的实际绑定操作尚未发生。

实现说明：R_Key的一个设想实现是让它由两个字段组成一个**索引字段**和一个**Key字段**。索引字段由HCA用于标识关联的类型1内存窗口资源，并保持不变。每次绑定R_Key时，Key字段都会更改，这保证上一个R_Key根据需要无效。在每个绑定中使用足够大小的Key字段和适当的随机数可以提供一定程度的保护，防止无效R_Key的持有者能够在未经授权的情况下访问类型1内存窗口。

准备绑定工作请求的通道接口软件生成新的Key值，并将其放入工作请求中，以便HCA在处理请求时记录在其类型1内存窗口资源中。这样，新的R_Key值将被完全确定，并且可以在HCA处理请求之前返回给消费者。

通道接口不需要使用此实现。

为了正确操作，使用者必须确保在HCA完成关联的绑定之前，远程代理不会尝试使用新的R_Key。实现这一点的一种技术是，使用者将绑定操作提交到它用来向远程代理发送消息的同一个发送队列中，该队列用于将新的R_Key传输给远程代理。

Bind绑定操作有一个唯一的**排序规则**：

C10-66.2.3：在调用Bind Memory Window Verbs之后发布到发送队列的任何工作请求在Bind操作完成之前都不能开始执行。

o10-37.2.25：如果HCA支持基本内存管理扩展，则在Bind操作完成之前，在调用Bind Memory Window Verbs之后发布到发送队列的任何工作请求都不能开始执行。在Bind Memory Window Verbs之后发布的Local Invalidate WR是一个例外（参见**第10.8.3.3节“发送队列排序规则”**）。

如果HCA检测到绑定操作出错，则会将QP置于错误状态。使用前面描述的技术，绑定操作在远程代理可能接收新的R_Key之前就可以完成。

一个设想的通用使用模型是将类型1内存窗口分配一次，然后用于多个绑定。当先前绑定的类型1内存窗口再次绑定时，上一个R_Key及其关联的绑定将自动失效。任何需要使用新类型1内存窗口绑定的远程代理都必须使用新的R_Key。

如果使用者希望在不释放类型1内存窗口或启用对新区域的远程访问的情况下使类型1内存窗口的绑定无效，则使用者可以提交一个指定长度为零的绑定请求。

C10-66.2.4：在零长度的类型1内存窗口绑定完成后，在后续绑定重新启用远程访问之前，CI不允许对该类型1内存窗口执行任何远程访问。

C10-66.2.5：CI应支持绑定到同一内存区域的多个类型1内存窗口，每个内存窗口都具有独立的远程访问权限，并且其相关区域应允许重叠或不相交。

o10-37.2.26：对于支持基本内存管理扩展的HCA，类型1内存窗口上不允许本地失效WRs。

o10-37.2.27：对于支持基本内存管理扩展的HCA，如果带有Invalidate的传入发送的目标是与类型1内存窗口相关联的R_Key，则CI应：

◼ 出现内存管理操作完成错误

◼ 不影响类型1内存窗口的状态；以及

◼ 将QP置于错误状态。

#### **10.6.7.2.4 类型2内存窗口**

o10-37.2.28：如果CI支持本规范中定义的基本内存管理扩展，则CI必须支持类型2内存窗口。

**类型2内存窗口是通过Post Send Bind Memory Window工作请求绑定的。**

为类型2内存窗口定义了两种类型的访问控制：

o10-37.2.29：如果HCA支持**类型2A内存窗口**，则它必须为类型2A内存窗口提供以下语义：

◼ 如果类型2A内存窗口处于自由状态，并且执行绑定WR的QP与绑定WR中引用的R_Key关联的PD关联，则允许Post Send Bind WRs。

◼ 如果类型2A 内存窗口处于有效状态并且执行无效操作的QP的QP编号（QPN）与绑定的2A内存窗口关联的QPN匹配，则允许进行无效操作。如果类型2A MW处于自由状态，并且执行失效操作的QP与绑定WR中与R_Key引用相关联的PD具有相同的PD，则也允许进行失效操作。

◼ MW访问操作（即RDMA Write、RDMA Reads和Atomics）仅允许在2A MW类型处于有效状态且执行MW访问操作的QP的QP编号（QPN）与绑定类型2A MW相关联的QPN才允许。

◼ 只有当QP没有与QP相关联的2A MWs类型时，才可以销毁QP或将其置于复位状态。

o10-37.2.30：如果HCA支持**类型**2B内存窗口**，那么它必须为2B型内存窗口提供以下语义：

◼ 如果2B MW类型处于自由状态，并且执行Bind WR的QP与BindWR中引用的R_Key相关联的PD与相同的PD相关联，则允许Post Send Bind WRs。

◼ 如果2B MW类型处于有效状态，并且执行失效操作的QP的QP编号（QPN）和PD与绑定类型2B MW相关联的QPN和PD匹配，则允许进行无效操作。如果2B型MW处于自由状态，并且执行失效操作的QP与与Bind WR中引用的R_Key相关联的PD具有相同的PD，则也允许进行失效操作。

◼ MW访问操作（即RDMA Write、RDMA Reads和Atomics）仅在2BMW类型处于有效状态且执行MW访问操作的QP的QP编号（QPN）和PD与绑定类型2BMW相关联的QPN和PD匹配时才允许。

◼ QP可以被销毁或置于复位状态，即使它仍然具有与之相关联的2B型MWs。

o10-37.2.31：如果HCA支持基本内存管理扩展，则HCA应支持2A或2B型MWs，但不能同时支持这两者。

在本规范中，术语2 MW用于描述2A型和2B型MWs通用的语义。

处于无效状态的2 MW类型不能用于Bind或Invalidate operation。

o10-37.2.32：如果CI支持本规范中定义的基本内存管理扩展，则类型2内存窗口的R_Key格式必须包括：

◼ 由CI拥有的R_Key的最高有效位中的24位索引，以及

◼ 由消费者拥有的8位密钥，占用R_Key的最低有效位。

o10-37.2.33：如果CI支持基本内存管理扩展，则每次通过发送后绑定内存窗口工作请求绑定给定类型2内存窗口时，CI应使用使用者为绑定操作提供的key值。绑定操作完成后，R_Key必须包括与类型2内存窗口相关联的24位索引和由使用者在发送后绑定内存窗口工作请求中提供的8位key。

o10-37.2.34：如果CI支持基本内存管理扩展，则如果使用者试图在Post Send Bind Memory Window Work Request（即在2 MW类型上）上使用类型1 MW R_Key的密钥，则CI必须返回错误（立即错误或完成错误）。

o10-37.2.35：如果CI支持基本内存管理扩展，则如果使用者尝试在Bind Memory窗口Verbs（即在类型1 MW上）上使用Type 2 MW R_Key，则CI必须返回错误（立即错误或完成错误）。

当通过发送后绑定内存窗口工作请求绑定类型2内存窗口时，CI不会返回R_Key。注：使用者有责任记住由分配内存窗口生成的R_Key索引，并构造R_Key值，以便通过组合24位索引和消费者选择的8位密钥传输到远程使用者。

**Bind MW和Post Send Bind WR有一个唯一的排序规则：**

o10-37.2.36：在Post Send Bind WR完成之前，任何发布到发送队列的工作请求都不能开始执行。在Post Send Bind WR之后发布的Local Invalidate WR是一个例外（参见**第10.8.3.3节“发送队列排序规则”**）。

如果HCA检测到绑定操作出错，它将使QP进入错误状态。使用前面描述的技术，可以保证绑定操作在远程代理可能接收到新的R_Key之前完成。

一个设想的通用使用模型是将类型2内存窗口分配一次，然后用于多个绑定。在再次绑定类型2内存窗口之前，必须通过本地失效或远程失效使其失效。

◼ Local Invalidate WR用于在类型2内存窗口上执行本地失效。

◼ 传入Send with Invalidate操作用于在类型2内存窗口上执行remote invalidate。

类型2内存窗口失效允许的失效排序区域与内存区域的失效排序区域级别相同（失效排序的描述见**第10.6.5.1节 “失效排序”**）。

注意，当本地HCA完成Send with Invalidate 操作的出站发送时，无法保证远程失效在远程CA成功完成。但是，当接收到的发送数据通过接收工作完成返回，并且传入的发送操作是带有Invalidate的发送操作时，（传入）失效保证已完成。

o10-37.2.37：如果CI支持基本内存管理扩展，则该CI必须支持类型2 MWs的松弛失效排序。

o10-37.2.38：如果CI支持强失效排序，那么对于类型2 MWs，CI必须：支持强失效排序，并提供一个本地失效界限位，以供使用者在本地失效时在松弛或强失效排序之间进行选择。

o10-37.2.39：对于2 MW类型，如果CI支持基本内存管理扩展，并且R_Key检查在传入发送时失败，并且无效操作：

◼ R_Key不能失效

◼ 带有Invalidate的传入发送必须生成一个完成错误，并且

◼ QP必须进入错误状态。

o10-37.2.40：对于类型2 MW，如果CI支持基本内存管理扩展，并且使用者试图通过调用绑定内存窗口或发送后绑定WR（长度为零）使类型2内存窗口无效，则CI必须返回错误。

o10-37.2.41：如果CI支持基本内存管理扩展，则CI应支持绑定到同一内存区域的多个类型1、类型2，或类型1和类型2内存窗口，每个窗口都具有独立的远程访问权限，并且它们的相关区域应允许重叠或不相交。

注意，允许在类型2内存窗口上执行失效操作，但不允许在类型1内存窗口上执行失效操作。因此，本地用户应该与远程用户协商与MW相关的R_Key是否可以失效。

下表说明了类型2A型和类型2B MWs之间的区别。与类型2A型和类型2B MWs相关的其他规则也适用。

下表总结了内存窗口失效的基本规则（请注意，在内存窗口上永远不允许快速注册）：

#### **10.6.7.2.5 重新绑定或解除分配活动窗口**

在正常操作下，当远程代理访问内存窗口时，使用者不应解除或更改内存窗口的绑定。但是，如果远程代理行为不当，也可能发生这种情况，或者在错误恢复情况下发生。

C10-67：当内存窗口的绑定被更改时，任何正在处理并积极使用内存窗口的远程操作请求都必须失败，并出现保护违规。

C10-68：一旦完成绑定操作被报告给使用者，通道接口必须保证在上一个绑定下不能执行额外的访问。

C10-69：任何正在处理并在解除分配时使用内存窗口的远程操作请求都必须以保护违规失败。

C10-70：一旦释放内存窗口Verb完成，通道接口必须保证在该内存窗口保持释放状态时，不能通过该内存窗口执行其他访问。

#### **10.6.7.2.6 注销绑定窗口的区域**

当内存区域仍有绑定的内存窗口时，用户注销或重新注册内存区域是一个错误。这种窗户被称为**“**孤立/**orphaned ”**窗口**。通道接口必须按如下方式处理此错误情况。

允许通道接口检测此错误情况并返回错误，而无需执行注销或重新注册操作。

C10-71：如果CI允许内存区域取消注册或重新注册操作来创建**孤立窗口**，则CI必须保证通过孤立窗口尝试的任何远程访问将在接受**第10.6.7.2.8节“窗口访问时的错误检查”**中所述的访问检查和强制执行。

#### **10.6.7.2.7 窗口绑定时的错误检查**

必须在内存窗口“绑定时间”执行以下检查，即通道接口正在执行准备和排队相关工作请求的绑定内存窗口Verbs时，或HCA正在处理该工作请求时。

C10-72：通道接口必须检查并强制Memory Window和QP属于同一PD。

C10-73：通道接口必须检查并强制允许Memory Window绑定到指定的内存区域。

C10-74：通道接口必须检查指定内存区域的写入权限，如**第10.6.7.2.2节“通过内存窗口进行远程访问”**中所述。

C10-75：通道接口必须针对指定的内存区域执行地址边界检查和PD检查。

#### **10.6.7.2.8 窗口访问时的检查错误**

当HCA处理访问的入站RDMA或原子请求时：

C10-76：此符合性语句已被淘汰。

C10-76.2.1：对于类型1内存窗口，CI必须检查并强制内存窗口和QP与同一PD关联。

o10-37.2.42：对于类型2A内存窗口，CI必须检查并强制2A型MW处于有效状态，并且与执行入站远程操作的QP的QPN关联。

o10-37.2.43：对于2B型内存窗口，CI必须检查并强制2B型MW处于有效状态，并且与执行入站远程操作的QP的QPN和PD相关联。

C10-77：通道接口必须检查并强制执行与窗口关联的地址绑定和访问权限。

C10-78：本合规声明已作废。

C10-79：本合规声明已作废。

C10-79.2.1：通道接口必须检查并强制执行与每个访问的物理缓冲区关联的访问权限。

C10-79.2.2：对于任何先前未检测到的错误情况，如**第10.6.7.2.6节“注销绑定窗口的区域”**中所述，通道接口必须检查并强制执行访问的任何物理缓冲区位于与窗口属于同一PD的内存区域中。

不需要通道接口来强制要求这样的物理缓冲区必须位于窗口绑定到的同一区域中。同样，强烈建议通道接口在绑定或释放时（而不是访问时）检查和报告这些错误情况。

#### **10.6.7.2.9 类型2内存窗口失效时间的错误检查**

o10-37.2.44：当HCA处理一个入站的Send with Invalidate请求时，该请求具有引用内存窗口的R_Key，则CI必须检查并强制执行：

◼ 内存窗口是类型2内存窗口

◼ 如果R_Key引用处于空闲状态的类型2 MW，则与类型2 MW相关联的PD与QP相关联的PD相匹配（注意，在这种情况下，invalidate将被视为noop）

◼ 如果R_Key引用处于有效状态的类型2A MW，则与类型2A MW相关联的QPN与接收到Send with Invalidate操作的QP的QPN相匹配

◼ 如果R_Key引用处于有效状态的2B 类型MW，则与2B MW关联的PD和QPN与接收Send with Invalidate操作的QP的QPN和PD相匹配。

# **10.7 工作请求**

工作请求用于向通道接口提交工作单元。支持不同类型的工作请求，并通过Verbs进行抽象。

工作请求如何被路由到其目的地取决于工作请求和QP类型。目标内存位置包含在工作请求的远程节点地址信息（RDMA和Atomics的情况下）或远程接收QP WR的分散/聚集列表中（对于发送/接收）。目标QP取决于QP类型。面向连接的QP在本地QP上下文中包含目的QP。数据报QP包含目标QP作为工作请求的一部分。Raw QP不针对目的地的特定QP。

## **10.7.1 创建工作请求**

工作请求是消费者在工作队列上生成工作的唯一机制。工作请求仅用于将操作从使用者传递到CI。

工作请求由使用者在通道接口上方使用OSV提供的机制创建。

## **10.7.2 工作请求类型**

消费者可能发布到工作队列的操作：

◼ 发送/接收

◼ RDMA写入

◼ RDMA读取

◼ 原子操作

◼ 绑定内存窗口

◼ Local Invalidate——如果支持本地内存管理扩展。

◼ 快速注册物理MR—如果支持基本内存管理扩展。

基本队列管理扩展还为使用者提供了一种将工作请求列表发布到发送队列、接收队列或共享接收队列的机制。

### **10.7.2.1 发送/接收**

C10-80：CI应支持CI所支持的所有传输服务类型的发送和接收操作。

发送必须发布到发送队列。

接收必须发布到到接收队列。

C10-81：应答器的接收QP应在接收到传入发送消息时使用一个工作请求。

C10-82：CI应为RC和UC传输服务类型提供分段和重组。

o10-38：如果CI支持RD服务，则CI应为RD提供分段和重新组装。

o10-38.2.1：如果CI支持基本内存管理扩展，则CI必须在提供RC服务的QPs上支持Send with Invalidate操作。

### **10.7.2.2 RDMA**

有两种RDMA类型：RDMA读和RDMA写。

RDMA读取操作仅支持三种可靠传输服务类型——可靠连接、扩展可靠连接和可靠数据报。RDMA写操作在三种可靠的服务类型和不可靠的连接服务类型上都受支持。

C10-83：CI应支持RC传输服务类型上的RDMA读取操作。

C10-84：CI应支持在RC和UC传输服务类型上执行RDMA写入操作。

o10-39：如果CI支持RD服务，则CI应支持RD传输服务类型上的RDMA Read和Write操作。

RDMA读取和RDMA写入请求被提交到发送队列。

C10-85：响应程序的接收队列不必对传入的RDMA读取操作耗费工作请求。

C10-86：当在成功完成的RDMA写入中指定了立即数据时，响应程序的接收队列将消耗一个**工作请求**/The responder’s Receive Queue shall consume a Work Request when Immediate Data is specified in a successfully completed incoming RDMA Write.

C10-87：当传入RDMA写入中未指定立即数据或传入RDMA写入未成功完成时，响应程序的接收队列不应使用**工作请求/WR**。

RDMA请求的目标地址是远程节点的虚拟地址、有效的R_Key和长度。R_Key必须与内存区域或包含该虚拟地址的内存窗口相关联。

队列对和内存区域或内存窗口具有RDMA读属性和RDMA写入属性。在目的端检查这些属性，在源端不检查这些属性。

C10-88；CI不得将数据从RDMA操作传输到目标内存，除非为目标QP启用RDMA操作。

o10-39.1.1： 如果CI支持XRC服务，则CI应在XRC传输服务类型上支持RDMA读和写操作。

### **10.7.2.3 原子操作**

IB原子操作被架构指定为可选功能，以对运行在IB fabric上的多个主机的分布式应用程序启用高性能同步。

支持两种操作类型：**Compare&Swap和Fetch&Add**。这些操作的操作数大小为64位。本地endnode的通道接口负责执行任何转换以匹配endnode-endian约定。

o10-40：如果CI支持原子操作，则CI应支持两种类型的原子操作：**比较和交换以及获取和添加**。

o10-41：如果CI支持原子操作，则本地endnode的CI应执行与终端节点字节序约定匹配的任何字节顺序转换。

o10-42：如果CI支持原子操作，则CI应使用2的补码算法实现取数和加法，而不保存进位。

o10-43：如果CI支持原子操作，如果原子操作的远程地址未在64位边界上对齐，则CI应返回错误。

只有当工作请求中指定的远程地址位于自然对齐的8字节边界上时，原子操作才是合法的。不支持从零开始的虚拟地址或块列表物理缓冲区列表寻址的HCA必须验证虚拟地址或物理地址对齐。支持零基虚拟地址或块列表物理缓冲区列表寻址的HCA必须验证物理地址对齐。使用者负责确保原子操作的内存范围不跨越页面或块边界，以避免传输错误。

由消费者来解释这些数字是有符号还是无符号。

**原子操作仅支持三种可靠传输服务类型**——**可靠连接、扩展可靠连接和可靠数据报。**

o10-44：如果CI支持原子操作，则CI应支持RC传输服务类型的原子操作。

o10-45：如果CI支持原子操作和RD传输服务类型，则CI应支持RD QP的原子操作。

o10-45.1.1：如果CI支持原子操作和XRC传输服务类型，则CI应支持Initiator XRC QP的原子操作。

o10-46：如果CI支持原子操作，则CI将不支持除XRC、RC和RD以外的任何其他传输服务类型上的原子操作。

**原子操作请求被发布到发送队列。原子操作请求是使用Post Send request Verbs发出的**。结果包含在数据段中。仅当原子操作已成功尝试时，发送到发送队列的请求的完成状态才会指示。消费者必须检查结果以确定是否发生条件操作。

o10-47：如果CI支持原子操作，则CI应返回数据段中的操作结果。

如果一个HCA支持原子操作，那么对该HCA发出的所有原子操作请求（引用同一个物理内存）将**被保证**看起来是相互序列化的。这些操作可以指向一个或多个队列对。

o10-48：如果CI支持原子操作，则CI应提供对同一HCA发出的所有原子操作请求即引用相同的物理内存，看起来应是相互序列化的。

对于向HCA或系统中的其他HCA发出的RDMA操作请求，或者对于由其他系统组件（例如处理器）执行的操作，向HCA发出的原子操作请求**不能保证被序列化**。由于这种行为，如果在内存的特定区域使用原子操作来实现锁，那么对该内存的所有访问都必须使用原子操作来完成。特别是，使用RDMA read或Send/Receive来查看是否持有锁是不安全的，使用RDMA write或Send/Receive来清除锁也是不安全的。

可选地，一些系统可以选择提供更强大的保证：对系统中的所有HCA发出的所有原子操作请求，以及由引用相同物理内存的其他系统组件（例如处理器）在内存上执行的所有原子操作，都保证看起来是彼此序列化的。同样，这些操作可以针对一个或多个单独的队列对。由非HCA的系统组件执行的“原子操作”的定义取决于实现；例如，可能需要处理器执行特定指令来产生原子操作。

o10-49：如果CI支持原子操作，并且系统提供跨系统的原子访问，则CI应提供引用相同物理内存的所有原子操作请求看起来是彼此序列化的。

### **10.7.2.4 绑定内存窗口**

**绑定内存窗口操作将先前分配的内存窗口与现有内存区域内的指定地址范围相关联，以及关联一组指定的远程访问权限**。

仅在可靠连接、不可靠连接和可靠数据报服务类型上支持绑定操作。

C10-89：CI应支持RC和UC传输服务类型的绑定操作。

o10-50：如果CI支持RD服务，则CI应支持RD传输服务类型的绑定操作。

绑定操作必须发布到发送队列。绑定只影响本地HCA内存映射资源，不会导致在链路上发出任何数据包。目标QP上的资源不受影响。

### **10.7.2.5 本地失效**

对于RC、RD、UC和XRC服务类型，允许在非共享物理内存区域或类型2内存窗口上执行本地失效操作。

本地失效操作必须发布到发送队列。本地失效操作只影响本地HCA内存映射资源，不会导致通过链路发出任何数据包。目标QP上的资源不受影响。

### **10.7.2.6快速注册物理MR**

对于RC、RD、UC和XRC服务类型，在使用消费者拥有的L_Key密钥部分以及任何关联的R_Key创建的**非共享物理内存区域**上，允许快速注册物理MR操作。

当创建任何服务类型QP时，使用者选择是否启用快速注册物理MR操作。如果使用者启用快速注册物理MR操作，则必须允许快速注册物理MR操作。

必须将快速注册物理MR操作发送到发送队列。快速注册物理MR操作只影响本地HCA内存映射资源，不会导致在链路上发出任何数据包。目标QP上的资源不受影响。

## **10.7.3工作请求内容**

工作请求包含执行请求的操作所需的所有信息。

**第11.4.1.1节“发布发送请求/Post Send Request”中**描述了发布到发送队列的操作的工作请求的内容。发布到接收队列的工作请求操作的内容在**第11.4.1.2 节 “发布接收请求/Post Receive Request”**中描述。

### **10.7.3.1 工作完成通知**

工作请求总是默认生成一个工作完成。这被称为**有报告完成**(Signaled Completion)。有一种机制，在这种机制中，发布到发送队列的工作请求可能不会在关联的完成队列中生成工作完成。这称为**无报告**完成（Unsignaled Completion）。为了使用无报告完成，QP必须配置为支持无报告完成，并且工作请求必须使用信令指示符来请求无报告完成。请注意，如果发生完成错误，则始终会生成一个工作完成，即使信令指示符请求无报告完成。

C10-90：CI应支持有报告和无报告的完成。

C10-91：CI应在以下任何情况下完成工作请求时**生成CQE**：

◼ 工作请求已错误完成。

◼ 工作请求已提交到接收队列。

◼ 已将工作请求提交到仅为有报告完成配置的发送队列。

◼ 工作请求已提交到为无报告完成配置的发送队列，但该工作请求请求了有报告完成。

C10-92：当提交到发送队列的已完成工作请求满足以下所有条件时，CI**不应生成CQE**：

◼ 发送队列已配置为支持无报告完成。

◼ 提交到该发送队列的工作请求设置信令指示符以请求无报告完成。

◼ 该工作请求已成功完成。

使用无报告完成的工作请求可以根据**第10.8.6节“无报告完成”**的规则确定已完成。

### **10.7.3.2 分散/聚集**

**分散/聚集列表可包含零个或多个数据段**。工作请求分散/聚集列表中指定的缓冲区必须在提交前向通道接口注册。从提交到工作队列的时间直到确认工作请求的完成，这些缓冲区必须被视为在通道接口的范围内。有关确认工作请求完成时间的完整说明，请参阅**第10.8.5节“返回已完成的工作请求”**和**第10.8.6 节 “无报告完成情况”**。

C10-93：如果所有缓冲区长度的总和超过为RC或UC QP指定的最大消息有效负载大小，则CI应报告错误。

C10-93.1.1：如果为一个UD消息指定的所有缓冲区长度的总和超过Query HCA返回的端口的MTU，则CI不应为此消息发出任何数据包。此外，CI不应因这种情况而产生错误。

o10-51：如果CI支持RD服务，并且所有缓冲区长度的总和超过为RD QP指定的最大消息有效负载大小，则CI应报告错误。

**数据段由虚拟地址、L_Key和长度定义。**

C10-94：CI应支持接收和RDMA读取操作的分散列表。

C10-95：CI应支持发送和RDMA写入操作的聚集列表。

Infiniband架构未定义通道接口访问分散/聚集列表所描述内存的顺序。特别是，这意味着在一个分散列表包含重叠数据段的工作请求完成后，重叠内存的内容是未定义的。

# **10.8 工作请求处理模型**

## **10.8.1 概述**

工作请求处理模型描述了HCA如何提交、处理请求以及返回给消费者的结果。

## **10.8.2 向工作队列提交工作请求**

工作请求是通过Verbs抽象提交给HCA的。

工作队列元素是抽象的。这意味着通道接口的使用者无法直接访问它们。

该体系结构的意图是允许实现将工作请求从用户级消费者进程传递到HCA，而无需内核参与。

只有当QP处于允许提交发送工作请求的状态时，QP才能接受这些发送工作请求。规则如下：

C10-96：QP应按照以下规则处理提交到发送队列的工作请求：

◼ 如果QP处于Reset、Init和RTR states中，则返回立即错误。

◼ 在QP处于RTS状态时被处理。

◼ 假设在QP处于SQEr或error状态时处理能够继续，则错误地完成。

◼ 当QP处于SQD状态时，已排队但未处理。

对于与SRQ无关的QP，只有当QP处于允许提交的状态时，QP才可以接受接收工作请求。规则是以下：

C10-97：此符合性声明已作废。

C10-97.2.1：如果QP与SRQ无关，QP应按照以下规则处理提交到接收队列的工作请求：

◼ 如果QP处于复位状态，则返回立即错误。

◼ 接受，但当QP处于Init状态时，不会处理传入消息。

◼ 当传入的消息到达并且QP处于RTR、RTS、SQD或SQEr状态时进行处理。

◼ 假设在QP处于错误状态时处理能够继续，则错误地完成。

**图129显示了将一个工作请求转换为**能被**HCA处理的WQE。**

对于与SRQ相关联的QP，无论SRQ的状态如何，SRQ都可以接受接收工作请求。但是，如果使用者的Post Receive Work Request 超出了SRQ的容量，则会返回立即错误。规则如下：

o10-51.2.1：如果HCA支持共享接收队列，则SRQ应按照以下规则处理提交给它的工作请求：

◼ 当SRQ进入异步状态时，必须返回错误。

◼ 接受，但如果SRQ未与任何QP关联或SRQ处于错误状态，则不会处理传入消息（不会从SRQ检索WQE）。

◼ 当传入消息到达与不处于错误状态且QP处于RTR、RTS、SQD或SQEr状态的SRQ相关联的QP时，对其进行处理。

◼ 接受，但如果QP处于Init、Reset或error状态，则不会处理传入消息（WQE不会从SRQ检索）。

o10-51.2.2：如果HCA支持共享接收队列，并且用户在与SRQ相关联的QP上发布接收WR，则CI应返回立即错误。

工作请求中的修饰符被实例化到指定工作队列中的下一个空闲WQE中，并通知CI已将新WQE添加到队列中。

### **10.8.2.1 提交工作请求列表**

如果CI支持基本队列管理扩展，则CI必须允许：

◼ 提交发送队列工作请求列表到发送队列

◼ 要提交Receive Queue Work Request列表到接收队列，以及

◼ 如果HCA支持SRQ，则要向SRQ提交共享接收队列工作请求的列表。

CI必须为WRs列表中的每个WR使用一个WQE。CI必须维护所用WQE的顺序与WR列表中WR的顺序相同。

如果提交到工作队列的工作请求列表大于工作队列上可用的可用工作队列元素的数量，则CI必须返回立即错误。如果在WRs列表中的任何工作请求中检测到立即错误，则CI必须：

◼ 将立即错误之前的所有WR转换为WQEs，并将WQEs排队到工作队列中

◼ 不将导致立即错误的WR转换为WQE

◼ 不转换为WQEs，即紧跟在WR之后导致立即错误的任何WR

◼ 必须返回遇到的第一个立即错误；以及

◼ 必须返回成功转换为WQEs并放置在工作队列中的WR数的指示。

## **10.8.3 工作请求处理**

提交到工作队列（WQ）的工作请求的处理按照提交的顺序启动。**提交到发送队列（SQ）的**WR**和提交到接收队列（RQ）的**WR**之间没有顺序**。相对于提交到同一发送队列的其他发送WR，发送WR的启动顺序与它们传递到verbs层的顺序相同。同样，接收WR的启动顺序与它们传递给Verbs层的顺序相同，而其他接收WR则提交到同一接收队列。

从工作请求提交到工作队列直到确认该工作请求的完成，与工作请求关联的资源必须被视为在通道接口的范围内。有关何时确认工作请求完成的说明，请参见**第10.8.5节“返回已完成的工作请求”**和**第10.8.6 节 “无报告完成”**。

C10-98：本合规声明已作废。

C10-98.2.1：CI应按照提交到单个发送队列的相同顺序启动发送、RDMA读取、RDMA写入和原子操作工作请求。在绑定工作请求完成之前，发布到发送队列的工作请求不得开始执行。绑定工作请求可以在先前的工作请求完成之前开始执行。

C10-99：本合规声明已作废。

C10-99.2.1：对于除RD和使用SRQ的服务类型以外的所有服务类型，提交到同一接收队列的工作请求应按照提交顺序完成。

根据排序规则，提交到单个发送队列的工作请求与提交请求的顺序相同。

此规则的例外情况是：1）允许可靠的数据报在接收队列上无序完成，2）与SRQ关联的RC、UC和UD QP可能接收到无序的WRs，以及3）XRC SRQ的接收WRs可能已无序完成。

SRQ可以与QP相关联，QP可以也可以不允许使用保留L_Key。当通过保留L_Key从引用的内存位置的SRQ检索WQE并且目标QP没有启用保留L_Key时，QP应进入错误状态。尝试访问保留L_Key的WQE将以错误方式完成，从SRQ拉到同一RQ上的后续WQE将以刷新错误完成，SRQ上的所有其他WQE（包括随后发布的WQE）不受该错误的影响。

### **10.8.3.1 可靠数据报排序规则**

来自特定发送队列的可靠数据报在发送到同一个**接收队列**时按相同的顺序完成。

o10-52：如果CI支持RD服务，提交到同一RD**发送队列**的工作请求应按照提交顺序完成。

o10-53：如果CI支持RD服务，则提交到同一RD**接收队列**的工作请求应按照请求来自同一远程RD **发送队列**时提交的顺序完成。

从多个发送队列发送的可靠数据报的接收完成允许在接收队列上相互交叉（交织）。

### **10.8.3.2 共享接收队列排序规则**

如果HCA支持共享接收队列，则与SRQ相关联的QP必须按顺序从SRQ中取出WQE。

o10-53.2.1：如果HCA支持共享接收队列，当HCA接收到针对与SRQ相关联的QP的消息时，HCA应从SRQ检索下一个可用的WQE，并使用它来接收传入消息。

关联同一个SRQ的多个QP可能将WQE从同一个SRQ中出队。因此，多个QP从单个SRQ中出队WQE会破坏存在的任何Receive WR的发布顺序。

o10-53.2.2：如果HCA支持共享接收队列：

◼ 通过SRQ提交的工作请求应通过与接收到传入消息的QP相关联的CQ作为工作完成返回

◼ 对于通过SRQ提交的接收WR，必须按照在远程发送队列上提交发送WR的顺序返回RC或UC服务QP上的接收工作完成；以及

◼ 成功轮询的WQE（poll of a WQE）必须保证WQE的重新发布是可能的。也就是说，成功地轮询与通过SRQ发布的工作请求相关联的工作完成，可以保证将另一个工作请求发布到同一SRQ。

### **10.8.3.3 发送队列排序规则**

如**表79工作请求操作排序**，提交到发送队列的WR的排序语义因操作类型而异。某些操作可以在CI中开始处理，而其他操作仍处于未完成状态，这可能会导致某些操作序列的无序语义。对于下面列举的情况，可以通过为适当的WR设置**防护指示符**（Fence Indicator）来保证顺序语义。当为给定的WR设置防护指示符时，在同一发送队列上所有先前的RDMA读取和原子操作完成之前，不能开始处理该WR。

C10-100：当在工作请求中设置了防护指示符时，发送队列在该发送队列上的所有前序RDMA读取和原子操作完成之前，不应开始处理该工作请求。

以下是可以使用防护指示符来保证顺序语义的情况：

◼ RDMA读取不一定能在目标处启动并观察到在后续的发送、RDMA写入或原子之前完成。如果目标使用者随后修改了RDMA read将要返回的内存位置，RDMA read可以返回新修改的数据，而不是原始数据。在每种情况下，为后续操作设置防护指示器可以保证在所有先前的RDMA读取完成之前，目标不会观察到该操作。

◼ RDMA读取可以返回已被后续发送、RDMA写入或原子修改的数据，如果它们的目标是RDMA读取返回的内存位置。在每种情况下，在后续操作上设置防护指示符可以保证该操作不会影响先前RDMA读取返回的数据。

◼ RDMA读取或原子操作不一定能在目标启动并观察到后续发送、RDMA写入或原子操作之前完成。如果前面操作中的一个由于其ack未能成功返回而在启动器端错误地完成，则目标用户仍可以观察到后续操作，并且目标使用者可能会采取一些不希望的操作。在每种情况下，在后续操作上设置防护指示符可以确保目标无法观察到它，除非所有先前的RDMA Reads和Atomics在启动器端成功完成。

◼ RDMA读取操作可以在目标上执行后续发送和失效操作之后在目标上执行。这可能导致RDMA读取操作失败。在后续操作中设置防护指示符可以保证RDMA读取在失效执行之前将完全完成。

**绑定操作有一个唯一的排序规则**：在绑定操作完成之前，任何在绑定之后发布到发送队列的工作请求都不能开始执行。但是，请注意，在某些情况下，绑定操作本身可以在先前的操作必须完成之前开始执行。另请注意，在绑定操作之后提交的快速注册PMR或本地松弛有序失效操作可以在绑定操作开始之前执行。

o10-53.2.3：如果HCA支持基本内存管理扩展，则失效操作可以在它被发布到发送队列之后的任何时候发生，但必须在生成完成之前和任何后续的WQE开始执行之前进行。

o10-53.2.4：如果HCA支持本地失效防护（Local Invalidate Fencing），当在本地失效工作请求中设置了本地失效防护指示符时，在该发送队列上的所有先前工作请求完成之前，发送队列不得开始处理该工作请求。此外，在本地失效工作请求完成处理之前，发送队列不应在本地失效工作请求之后立即开始处理工作请求。

本地失效防护指示符（Local Invalidate Fencing Indicator）可以用来保证顺序语义。如果在发布本地失效操作时本地失效引用的内存区域正在使用中，则HCA可以使该内存区域失效。为了防止这种情况发生，如果HCA支持在本地失效时设置防护，可以在本地失效操作上设置本地失效防护指示器。在Local Invalidate上设置本地失效防护指示符将确保在发生失效操作之前，同一发送队列上引用正在失效的内存区域的所有WQE都已完成。

处理和完成通知的排序保证只存在于提交到同一队列的工作请求之间。未定义跨多个工作队列的排序。

C10-101：本合规声明已作废。

C10-101.2.1：CI应根据表79工作请求操作顺序中的排序规则，为提交到同一发送队列的工作请求之间的处理和完成通知提供保证。

**排序规则/Ordering Rules：**

◼ 接收队列是FIFO队列，但上面描述的可靠数据报和SRQ问题除外。

◼ 发送队列是FIFO队列，根据表79工作请求操作顺序中的规则。**防护指示符可用于要求严格排序。**

## **10.8.4 完成处理**

当请求完成时，工作请求操作的结果被放入与工作队列相关联的CQ上的完成队列条目（CQE）。

在将工作完成返回给消费者之前，必须生成CQE。注意，由于**无报告完成**（unsignaled completion），并不是所有的工作请求都会生成一个完成。**第10.8.5节“返回已完成的工作请求”**中概述了何时生成CQE的规则。

C10-102：对于生成工作完成的已完成工作请求，CI应将该工作完成放在与工作队列相关联的CQ上。

CQE是工作完成的内部表示。

## **10.8.5 返回已完成的工作请求**

**所有完成都通过Verbs抽象。检索工作完成的唯一方法是通过Verbs。**

除了RD 接收工作队列和与SRQ关联的接收工作队列之外，对于该工作队列上的其他工作请求，总是按照提交到给定工作队列的顺序返回工作完成。

对于与SRQ相关联的QP，发送工作完成（Send Work Completions）总是按照提交到给定工作队列的顺序返回，该顺序与该工作队列上的其他工作请求有关。接收工作完成 (Receive Work Completions)的返回顺序可能与提交到共享接收队列的顺序不同。

本规范不强制要求与给定完成队列关联的多个工作队列中的完成条目的排序规则。

检索到的工作完成不再在通道接口的范围内。因此，一个工作完成只能检索一次。

C10-103：CI不允许对特定工作完成情况进行多次检索。

**第11.4.2.1 节 “完成轮询/Poll for Completion”**中规定了工作完成的内容。

消费者可以通过轮询或通知来确定何时可以检索工作完成。

C10-104：CI应返回一个工作请求的工作完成情况，该请求已完成并**报告完成**。

C10-105：CI应返回提交到发送队列的错误完成的工作请求的工作完成。

C10-106：本合规声明已作废。

C10-106.2.1：对于与SRQ无关的QP，CI应返回一个工作完成，以完成提交到接收队列的工作请求。

o10-53.2.5：如果CI支持SRQ，对于与SRQ关联的QP，CI应返回一个工作完成，以完成提交到共享接收队列的工作请求。

o10-53.2.6：如果CI支持SRQ，对于与SRQ关联的QP，工作完成应返回到与QP的接收队列相关联的完成队列。

C10-107：CI在检索到相关工作完成后，不得访问与工作请求相关的任何缓冲区。

### **10.8.5.1 已释放资源计数**

完成时返回的修饰符之一是一个计数，用于通知使用者此完成所释放的工作请求资源的数量。这只适用于可靠数据报接收队列。工作请求资源是指代表使用者分配的通道接口资源，例如对于一个给定工作队列的可用WQE，而不是直接的使用者资源，例如缓冲区。

如果此计数为零，则表示生成此工作完成时没有释放任何接收队列工作队列元素。如果此计数大于零，使用者可以假定计数器指示从RD RQ释放的工作请求数。这有助于使用者跟踪可用工作请求的数量，这些请求可以是未完成的。

与此工作完成相关联的未完成工作请求相关联的缓冲区不再被视为在HCA的范围内，而与释放的资源计数无关。

对于大多数实现，这个计数预计是一个完成了所有工作的计数。

o10-54：如果CI支持RD服务，则当检索到与发布到RD RQ的工作请求相关联的工作完成时，CI应返回通过Verbs释放的工作请求资源数的计数。

### **10.8.5.2 完成队列错误**

在某些情况下，完成队列可能会遇到错误。可能会发生两种类型的CQ错误：CQ可能会溢出或无法访问。CQ错误通过关联的异步错误报告给使用者，这些错误在**第10.10.2.3节 “异步错误”**中讨论。

当CQ试图生成CQE并且CQ已经满时，发生CQ溢出。不可访问CQ是一个依赖于实现的错误，其中CQE不能报告给CQ，尽管CQ未满。HCA检测到CQ错误并将其显示在CI上。当消费者检索完成时，CI只报告良好的完成或指示CQ为空。

在CQ错误之后，使用者仍然可以检索在错误发生时CQ上未完成的完成。返回所有未完成的完成后，CI将指示CQ为空。损坏的CQE不会作为工作完成返回给使用者。

在CQ错误之后，QP仍然可以通过Create QP与遇到错误的CQ相关联。它还允许修改、查询和销毁连接到遇到错误的CQ的QP。任何试图查询或调整CQ大小的尝试遇到错误都将报告一个立即错误。在这样的CQ上允许销毁CQ。

当CQ遇到错误时，为了能够再次使用CQ，消费者应该：

◼ 销毁连接到CQ的所有QP

◼ 销毁CQ

◼ 通过Create Completion Queue Verb重新创建CQ

如果消费者在遇到关联异步错误的CQ上请求通知（即，已溢出或变得不可访问的CQ），则CI将不报告完成事件。

### **10.8.6 无报告完成/Unsignaled Completions**

当满足以下所有规则时，无报告工作请求被确认成功完成：

◼ 从与发送队列关联的同一个CQ检索工作完成，而该队列也被提交了无报告的工作请求。

◼ 该工作完成了对应于与无报告工作请求相同发送队列上的后续工作请求。

C10-108：一旦检索到与同一发送队列上的后续工作请求相对应的工作完成后，CI不得访问与无报告工作请求相关联的缓冲区。

## **10.8.7 异步完成通知**

消费者可以注册多个完成通知例程(routines)，每个完成事件一个，当使用设置完成事件处理程序Verbs(Set Completion Event Handler Verb)向CQ添加新条目时调用。

C10-109：本合规声明已作废。

C10-109.2.1：CI应支持为每个HCA注册一个**CQ事件处理程序(Event Handler)**。CI必须确保使用者可以成功设置一个完成事件处理程序。

o10-54.2.1：如果CI支持基本队列管理扩展，则CI必须：

◼ 支持一个或多个完成事件处理程序

◼ 通过查询HCA Verb返回HCA支持的完成事件处理程序数

◼ 通过设置完成事件处理程序Verb，将完成处理程序地址与完成处理程序标识符相关联

◼ 通过设置完成事件处理程序Verb，清除现有的完成事件处理程序；以及

◼ 通过Create CQ Verb，将完成处理程序标识符与CQ相关联

C10-110：此符合性语句已被废弃。

C10-110.2.1：如果HCA不支持基本队列管理扩展，CI应使用新的Set Completion Event Verb通知中指定的处理程序替换与完成事件标识符关联的任何先前处理程序。

o10-54.2.2：如果HCA支持基本队列管理扩展，并且使用者指定了非零的完成事件处理程序地址，则CI应使用新的设置完成事件Verb通知中指定的处理程序替换与完成事件标识符关联的任何先前处理程序。如果使用者指定零完成事件处理程序地址，则CI应清除任何先前的处理程序。

如果使用者引用现有完成事件处理程序标识符并如上所述去清除先前的处理程序，则在从设置完成事件处理程序Verbs返回之前，使用者不能使用相同的完成事件处理程序标识符。

**请求完成通知Verb是根据每个CQ设置的。这是一个一次性通知；最多，每次调用此Verb将生成一个通知。一旦启用了CQ通知，额外的请求完成通知调用将不起作用。当下一个条目被添加到指定为该Verb修饰符的CQ时，处理程序将被调用一次。请求事件的存在可能会影响此行为**。详见**第11.4.2.2节“请求完成通知”**和**第9.2.3节“请求事件（SE）-1位”**。

C10-111：CQ最多应有一个未完成的完成事件通知请求。

C10-112：CI应在满足未完成完成事件请求的CQ条目添加到CQ时生成单个完成事件。

C10-113：CI不应在注册完成通知请求时为指定CQ上的现有CQ条目生成完成事件。

直到下一个entry被添加到CQ，才会生成通知。

当使用请求完成通知时，应使用以下调用序列，以确保指定CQ的新CQ条目不会丢失。

1） 轮询是否完成，以使现有的CQ条目出列。

2） 请求完成通知。

3） 轮询是否完成，以提取在调用第一个完成轮询和启用通知之间添加的任何CQ条目。

如果处理程序尚未注册，则不会生成通知。

当处理程序例程被调用时，将提供指示哪个CQ生成了完成通知。一旦调用了处理程序例程，使用者必须再次调用请求完成通知，以便在向CQ添加新条目时得到通知。

C10-114：对于每个完成事件，CI应指出是哪个CQ导致了该事件的生成。

使用者负责轮询CQ以检索工作完成。此功能不会在通知发生时自动执行。

# **10.9 分区/Partition**

本节讨论InfiniBand对InfiniBand网络分区的支持。对分区Verb的支持包含在执行队列对管理、读取通道接口（CI）内容并进行设置的Verbs中。这些记录在**第11.2节“传输资源管理”**中。

在本讨论中，术语“分区管理器（PM）”指的是子网管理器处理所讨论CI分区的功能；有关SMP如何定向到该管理器，请参阅**第13.5节“MAD处理”** 。

## **10.9.1 简介**

分区在共享InfiniBand fabric的系统之间强制隔离，这是通过要求数据包包含一个16位分区密钥（P_Key）实现的。该密钥必须与存储在接收端中的P_Key相匹配，否则将被丢弃；参见下面的“匹配”定义（**第10.9.3节“分区密钥匹配”**）。在CA中没有直接设置P_Key发送或P_Key匹配的Verbs。而是指定P_Key表中的索引：**P_Key_ix**，指定**P_Key表**中的一个条目。P_Key表的内容由子网的**分区管理器（PM）**控制，PM使用通过子网的子网管理器发送的子网管理包（SMP）来设置它们。

下面的小节描述了P_Key表、匹配过程以及P_Key附加到数据包的方式。参见**第14.2.5节“属性”**，了解设置P_Key表中项目的SMP的说明。

### **10.9.1.1 有限成员和完全成员关系**

在其P_Key表中具有相同P_Key的端节点集合被称为分区或分区中的成员(members of a partition, or in a partition)。P_Key表可以指定两种类型的分区成员身份：有限的或完全的。P_Key的高位用于记录分区表中的成员身份类型：0表示受限，1表示完全。有限成员不能接受来自其他有限成员的信息，但允许在成员类型的其他组合之间进行通信。

### **10.9.1.2  特殊P_Key**

有特殊含义的_Key：**默认分区Key**和**无效分区Key**。

C10-115：P_Key值0xFFFF代表默认分区Key。

默认分区密钥在默认分区中提供完整的成员资格。

C10-116：如果P_Key的低阶15位全部为0，CI应将该P_Key视为无效。CI应通过使用有效的P_Key将表条目标记为无效。

C10-117：PM不得将这两个P_Key值用于任何其他目的。

任何不是无效的P_Key都被称为有效密钥。默认分区密钥有效。包含有效P_Key的P_Key表项被称为有效的P_Key 表项。

### **10.9.1.3 子网间的操作**

C10-118：当包在子网内或子网之间转发/路由时，交换机或路由器不得修改P_Key值。

C10-119：一个包的P_Key必须与存储在目的地CI或CA中的P_Key匹配，否则该包将被丢弃；见下面的“匹配”定义（**第10.9.3节“分区密钥匹配”**）。

在上述情况下，源于一个子网的P_Key必须在另一个子网中有效。由于子网可能有不同的PM，因此必须对其进行处理，例如通过人工管理（类似于静态IP地址的分配）或子网PM之间的程序对话。在这种PM间对话中使用的消息的定义超出了本规范版本的范围。

## **10.9.2 分区密钥表（P_Key表）**

C10-120：每个HCA端口和交换机SMA端口应包含一个分区密钥表（P_Key表）。P_Key表中的有效条目应包含该CI可以与之通信的所有端节点的P_Key。

如果一个交换机或路由器支持可选的P_Key强制功能(P_Key Enforcement feature)，那么它的每个端口都应该包含一个分区密钥表（P_Key Table）。

C10-121：P_Key 表大小（即它可以容纳的最大条目数）必须大于或等于1，小于或等于65535。

通过使用查询HCA Verb或NodeInfo SMP，可以获得P_Key表中可以保存的最大条目数。（参见**第11.2.1.2节 “查询HCA”**和**第14.2.5.3节“NodeInfo”** ）

C10-122：CI不得提供任何接口以允许Verbs上方的软件更改P_Key表内容或更改P_Key表中任何项的有效性，除非使用SMPs。

Verbs允许主机软件读取P_Key表中的条目。如果读取的值是无效的P_Key值，则该项无效。

发送到endnode的SMP用于读写P_Key表中的条目。写表时所涉及的操作将在后面的章节中描述。

C10-123：如果不使用非易失性存储来保存P_Key表内容，那么如果PM（分区管理器）不存在，并且在对P_Key表进行PM初始化之前，P_Key表必须像包含一个有效的条目一样工作，即P_Key_ix=0，包含默认的分区键。P_Key表中的所有其他条目都必须无效。

## **10.9.3 分区密钥匹配**

C10-124：终端节点接收到的传入包的P_Key字段应与本节剩余部分中描述的本地驻留P_Key相匹配。

另见**第9.6.1.1.3节“BTH**:**P_Key”**和**第18.2.1节“属性”**。

在下面，让M_P_Key（消息P_Key）作为传入包中的P_Key，E_P_Key（端节点P_Key）作为它在包的目的地端节点中比较的P_Key。

◼ 如果：

✸ 无论是M_P_Key还是E_P_Key都不是无效的密钥

✸ 并且M_P_Key的低阶15位与E_P_Key的低阶15位匹配

✸ 并且M_P_Key和E_P_Key的高阶位（成员类型）不都是0（即，两者都不是分区的有限成员），则称P_Key匹配。在这种情况下，接收并正常处理传入包。

◼ 在所有其他情况下，P_Key被称为不匹配。必须将传入的数据包视为发送到不存在的设备，这意味着：

✸ 没有返回ACK

✸ （可选）向SM发送（trap）陷阱SMP，并递增计数器；请参阅**第10.9.4节“错误的P_Key Trap和P_Key违规计数器（可选）**”。

✸ 对目标endnode没有其他影响。

## **10.9.4 错误的P_Key Trap和P_Key违规计数器（可选）**

o10-55：本合规声明已作废。

o10-55.1.1：如果交换机和路由器的CA端口和GSI端口支持P_Key冲突的陷阱SMP（trap SMP），那么如果一个包的P_Key不匹配，则目的节点应向SM发送一个陷阱SMP，指定分区类型和坏P_Key通知（Bad P_Key Notification）方法，但有一个例外。此规则的例外情况是如果端口PortInfo:MulticastPKeyTrapSuppressionEnabled设为1，则该数据包是一个多播数据包，而P_Key不匹配的原因是包和端口的P_Key都是同一分区的有限成员，则目的节点不应发送陷阱SMP。如果发送了陷阱SMP，陷阱SMP的主体必须包含有问题的包的头字段，如**表140“陷阱”**和**表148“陷阱257和258的注意数据详细信息”**中所述。与所有陷阱一样，此陷阱的发送频率不得超过子网超时。

o10-56：如果交换机和路由器的CA端口和GSI端口支持针对P_Key违规的陷阱SMP，那么如果在发送陷阱之前发生另一个P_Key不匹配，则新不匹配的数据应替换先前存储的数据。

o10-57：如果交换机和路由器的CA端口和GSI端口支持P_Key违规计数器，则它应具有以下特性：

◼ 它的最小大小是1位；最大大小是16位（无符号）。

◼ 当到达给定端口的消息上的P_Key不匹配时（如**第10.9.3节“分区密钥匹配”**中所述），它将递增。

◼ 当它的值达到全1时，继续递增不会改变它的值：即它已饱和。

◼ 通过上电重置为零进行初始化。

可以使用访问PortInfo属性的P_Key Violations组件的SMP来读取和设置P_Key Violations计数器；请参阅**第14.2.5.1节“注意事项和陷阱”**。

## **10.9.5  CI分区支持**

C10-125：除了子网管理QP (QP0)和提供RD或Raw Datagram服务的QP之外，在使用QP之前，必须为每个QP关联一个P_Key。如果一个CI有多个端口，那么P_Key索引所引用的P_Key表应该是QP当前使用的端口的P_Key表。

这个关联是通过指定要使用的key的P_Key_ix的Verbs来完成的。如果CI支持自动路径迁移，则主密钥和备用密钥应映射到同一个分区密钥；否则，APM可能无法正常工作。

C10-126：CI应为从QP发送队列发送的所有数据包附加QP的P_Key，但SMP、原始数据报数据包和RD QPs发送的数据包除外。

SMP总是使用默认的P_Key发送，原始数据报数据包不包含P_Key，并且来自RD QP的数据包从与RD QP相关联的EE上下文获取它们的P_Key。

C10-127：CI应将QP的P_Key与所有传入数据包中包含的P_Key进行比较，原始数据包和目的地为提供RD服务的QP0、QP1和QPs的数据包除外。请参阅**第10.9.8节 “管理队列对**上**的分区强制”**，了解QP0和QP1上传入数据包中的P_Key验证规则。

**第10.9.3节“分区密钥匹配”**描述了这种比较。**第10.9.8节“管理队列对上的分区强制”**和**第10.9.5.1 节 “EE上下文（可靠数据报）支持”**中描述了例外情况。

### **10.9.5.1 EE上下文（可靠数据报）支持**

o10-58：如果CI支持RD服务，则必须在使用EE上下文之前将P_Key与每个EE上下文关联。如果一个CI有多个端口，则P_Key 索引引用的P_Key表应该是EE Context当前使用的端口的P_Key 表。

o10-59：如果CI支持RD服务，则CI必须将EE上下文的P_Key附加到使用该EE上下文发出的所有传出可靠数据报（RD）数据包。使用给定EE上下文的所有传入数据包应与该EE上下文的P_Key进行比较，如**第10.9.3节“分区密钥匹配”**所述。

如果CI支持自动路径迁移，那么主和备用P_Key_ix都应该映射到同一个P_Key；否则APM可能无法正常工作。

如该节所述 ：如果P_Key匹配，则正常处理该包；否则，它将被静默丢弃，并且可选地，发出一个陷阱，并且错误的P_Key计数器将按该节中的描述递增。

RD服务未用于管理队列对，因此此EE Context支持不适用于它们。

### **10.9.5.2 分区键更改**

C10-128：当PM向CI端口发送消息请求更改P_KEY表元素的值时，CI必须返回一条响应消息，指示该操作已执行成功或由于某种原因未执行。

C10-129：CI应保证，在向PM发送表示成功的响应消息的时间点之后，更新后的P_Key表值将用于处理所有随后穿过相关端口的传入和传出数据包。

这个行为可能在PM收到成功回复之前就已经开始了。

## **10.9.6 TCA分区支持**

C10-130：TCA对分区的支持必须与CI相同，但P_Key与队列的关联应响应启动队列对创建的消息，作为与另一个终端节点通信的一部分。

在所有其他方面，TCA在多个端口、传入数据包、传出数据包以及对P_Key表的更改方面的行为与CI完全相同。

## **10.9.7 Fabric分区支持**

InfiniBand fabric中的交换机还可以选择强制分区。描述交换机的一章（**第18.2.4.2.1节“入站P_Key实施”**和**第18.2.4.4.1 节 “出站**P_Key实施”**）的几个章节描述了如何将P_Key加载到交换机中以及如何使用它们。

## **10.9.8 管理队列对上的分区强制**

两种类型的管理队列以不同的方式处理分区强制。

C10-131：发送到子网管理接口QP的数据包应始终被接受，而不考虑数据包中包含的P_Key。

管理通信的隔离和安全性不是通过分区来提供的，而是通过检查管理密钥来提供的。

从子网管理接口QP发送的数据包可以具有任何P_Key；默认的P_Key按约定使用，如管理部分中所述。

C10-132：如果发送到通用服务接口QP（QP1）的数据包中的P_Key与数据包到达的端口的P_Key表中的任何有效P_Key匹配，则应接受发送到通用服务接口QP（QP1）的数据包。匹配在**第10.9.3节 “分区密钥匹配”**中定义。

如该节所述：如果P_Key匹配，则正常处理该包；否则，它将被静默丢弃，并且可选地，发出一个陷阱，并且错误的P_Key计数器将按该节中的描述递增。

C10-133：从GSI QP的发送队列发送的数据包应附加与该QP相关联的P_Key，就像P_Key与非管理QP相关联一样。

C10-134：每个交换机还应检查其GSI QP上的P_Key。根据上述C10-132中所述的规则，交换机应支持至少有一个条目的P_Key表，目的地为交换机的GSI的分组的P_Key应与之匹配。

## **10.9.9 管理消息检查的相关强制措施**

检查M_Key（见**第14.2.4节“管理密钥”**）可选择性地用于防止除经授权的子网管理器外的任何东西从SMI读取任何SM数据，并且当保护测试失败时，静默地丢弃失败的包。类似地，通过静默丢弃防止SM数据通过SMI写入也是强制性的。

此外，还可以选择存储M_Key、控制M_Key检查的M_KeyProtectBits，以及**表155 PortInfo**的整个电源周期。因此，例如，系统初始化技术不能假定该数据的默认值是恒定的，除非从工厂首次通电。

# **10.10 错误处理语义和机制**

本节描述在通道接口处检测到的错误类型以及当这些错误事件发生时生成的响应。

## **10.10.1 错误类型**

**定义了通过Verbs报告的三类错误：立即错误、完成错误和异步错误**。在**第10.10.2节“错误处理机制”**中，每个错误类都在各自的标题下进行了更详细的描述。下面是对每个错误类的简要描述。

**立即错误**作为状态从Verbs返回。

**完成错误**作为工作完成中的状态返回给Verbs使用者。

**异步错误**通过事件处理机制返回。

## **10.10.2 错误处理机制**

本节描述在请求的操作中，用于通知Verb使用者的错误机制。

### **10.10.2.1 立即错误**

C10-135：CI应在Verbs的控制权返回给使用者时返回立即错误。

这些错误类型的细节包含在Verbs一章中描述的每个Verb中。

C10-136：如果涉及将工作请求发送到队列的Verb返回立即错误，则CI应确保工作请求尚未发布到队列。

### **10.10.2.2 完成错误**

C10-137：“错误地完成/completed in error”的工作请求或WQE应在工作完成状态下返回适当的完成错误。

完成队列操作（**第11.4.2.1节“完成轮询”**）下的Verbs一章描述了在工作完成状态下可以返回的错误的完整列表。

完成错误分为两类：接口检查和处理错误。接口检查是在数据被放入链路之前检测到的提供给信道接口的信息中的错误。处理错误是在通道接口处理工作请求期间遇到的错误。

### **10.10.2.3 异步错误**

异步错误通过异步通知机制通知消费者。为了在发生异步错误时得到通知，使用者必须使用Set Asynchronous Event Processor Verb注册一个处理程序。

C10-138：在注册异步事件处理程序之后，所有后续的异步错误都将导致对错误处理程序的调用。注册错误处理程序之前发生的异步错误将被丢弃。

这些错误的详细信息在**第11.6.3.2节“关联异步错误”**和**第11.6.3.4节“非关联异步错误”**中讨论。

C10-139：每个HCA只能注册一个错误处理程序。对Set Asynchronous Error Handler Verb的后续调用将导致上一个处理程序地址被新的处理程序地址覆盖。

有两种异步错误类型：

◼ 非关联异步错误。与任何特定的WQ或CQ无关。

C10-140：此符合性声明已删除。

◼ 关联异步错误。与特定的WQ、CQ或EE上下文相关，并且无法在完成时报告错误。QP或 EE上下文被转换为错误状态。

## **10.10.3 错误对QP服务类型的影响**

根据QP的服务类型，定义的不同类型的IB错误对队列处理有不同的影响。

需要注意的是，本地QP上的灾难性错误对远程QP没有直接影响。不会因为QP遇到错误而尝试在Verbs下面发送消息来断开连接。

### **10.10.3.1 可靠连接QPs**

C10-141：立即错误不应影响QP处理，因为工作请求从未发布到QP。

C10-142：对于发送队列完成错误，CI应错误地完成发送队列的工作请求。QP应处于错误状态。所有后续工作请求应错误完成

如果出现本地发送队列错误，则发送队列中发生错误的任一和所有工作请求都将由通道接口错误完成。如果本地错误是接口检查，则远程对应的接收队列不会消耗工作请求，因此不会出现完成错误。如果本地错误是处理错误，则相应的远程接收队列可能完成错误的工作请求，也可能没有完成错误的工作请求。RDMA和原子操作发送队列出现完成错误时，本地和远程内存的条件在**第10.3.1.7 节 “错误”** 中指定。

C10-143：对于本地接收队列完成错误，发生错误的接收队列上的工作请求应由CI错误地完成。QP应处于错误状态。所有后续工作请求均应错误完成。

C10-144：关联的异步错误应导致QP处理停止，从而使通道接口无法成功完成未完成的工作请求。QP应转换为错误状态。在相应的工作队列上进行中的任何请求都应停止并返回完成错误，除非CQ已溢出或无法访问。如果CQ已溢出或无法访问，则不应通过CQ返回正在进行的请求。

C10-145：**表81 RC发送队列的完成错误处理**和**表82 RC接收队列的完成错误处理**是根据错误和工作队列类型，CI必须支持的RC错误处理操作的更详细描述。

表中使用的错误类型的描述包含在**第11.6.2节“完成返回状态”**中。

### **10.10.3.2 可靠数据报QP**

o10-60：如果CI支持RD服务，立即错误不会影响QP/EE处理，因为工作请求从未发布到QP/EE。

o10-61：如果CI支持RD服务，则发送队列上的完成错误将导致发送队列处理暂停，并且发送队列状态应转换为发送队列错误状态，如状态图所示。发生错误的工作请求应在错误中完成。

在本地发送队列错误的情况下，发生错误的发送队列上的所有工作请求都由通道接口错误地完成。如果本地错误是接口检查，则相应的远程接收队列将不使用工作请求，因此不会显示完成错误。如果本地错误是处理错误，则相应的远程接收队列可能会完成错误的工作请求，也可能不会完成。RDMA和原子操作的发送队列上发生完成错误时本地和远程内存的状态在**第10.3.1.6节“发送队列错误（SQEr）”**中指定。

o10-62：如果CI支持RD服务，对于本地接收队列完成错误，则发生错误的接收队列上的工作请求应由CI错误地完成。所有后续的工作请求不应受到该错误的影响。

o10-63：如果CI支持RD服务，则完成错误对EE上下文状态没有影响。

o10-64：如果CI支持RD服务，关联的异步错误将导致QP处理停止，从而导致通道接口无法成功完成未完成的工作请求。QP应转换到错误状态。在相应的工作队列上进行中的任何请求都应停止并返回完成错误，除非CQ已溢出或无法访问。如果CQ已溢出或无法访问，则不应通过CQ返回进行中的请求。

o10-65：如果CI支持RD服务，当关联异步错误只与QP关联时，该错误对EE上下文没有影响。如果关联错误与EE上下文关联，则EE context应转换为错误状态。

o10-66：如果CI支持RD服务，则表83 RD发送队列的完成错误处理和表84 RD接收队列的完成错误处理更详细地描述了CI必须支持的RD错误处理操作。

**错误处理操作：**

不相关的SQ和RQ不受影响，除非它们尝试使用处于错误状态的EE上下文或QP。

1） 错误发生时，EE上下文上的SQ活动状态变为SQEr状态。

◼ 接收与处于SQEr状态的本地SQ相关联的RQ正常继续（即，除非它们也遇到单独的错误，否则不会错误地完成）。

◼ SQ中经历错误的其余WQE通过Work Completions（WCs）返回错误。

2）发生错误时，在EE context上活动的RQ已通过WC以错误方式返回发生错误的WQE。与RQ关联的QP的状态不受影响。

◼ 该RQ中的所有其他WQE继续正常工作（即，除非它们也遇到错误，否则不会在错误中完成）。

◼ 发送与本地RQ相关联的SQ正常继续（即，除非它们也遇到单独的错误，否则不会错误地完成）。

3） 本地EE上下文处于错误状态。远程EE上下文状态是不确定的（例如，可能不处于错误状态，例如源超时）。

◼ 无法恢复EE上下文。

◼ 必须重新建立EE上下文。

4） 当RD QP发生本地保护或操作SQ错误时，本地侧的CI应在Verbs下方发出InfiniBand no-op （RDMA Write，长度为0且没有立即数据）给与本地错误相关的RD RQ，假设RD通道仍可操作。这将导致远程端正在进行的RQ Work Request错误完成。接收端不能依赖于接收该消息。

### **10.10.3.3 不可靠连接的QPs**

C10-146：立即错误不会影响QP处理，因为工作请求从未发布到QP。

C10-147：发送队列上的完成错误将导致发送队列处理暂停，并且发送队列状态应转换为发送队列错误状态，如状态图所示。发生错误的工作请求应错误地完成。

在本地发送队列错误的情况下，发生错误的发送队列上的所有工作请求都由通道接口错误地完成。相应的远程接收队列不会使用工作请求，因此不会出现完成错误。RDMA写入操作的发送队列上发生完成错误时远程内存的状态在**第10.3.1.6节“发送队列错误（SQEr）”**中指定。

C10-148：对于本地接收队列完成错误，CI应错误地完成发生错误的接收队列上的工作请求。QP被置于错误状态。所有后续工作请求都应错误地完成。

C10-149：表85 UC发送队列的完成错误处理和表86 UC接收队列的完成错误处理是根据错误和工作队列类型，CI必须支持的UC错误处理操作的更详细说明。

表格中使用的错误类型说明见**第11.6.2节“完成返回状态”**。

C10-150：关联的异步错误应导致QP处理停止，从而使通道接口无法成功完成未完成的工作请求。QP应转换到错误状态。在相应的工作队列上进行中的任何请求都应停止并返回完成错误，除非CQ已溢出或无法访问。如果CQ已溢出或无法访问，则不应通过CQ返回正在进行的请求。

### **10.10.3.4 不可靠数据报QPs**

C10-151：立即错误不会影响QP处理，因为工作请求从未发布到QP。

C10-152：发送队列上的完成错误应导致发送队列处理暂停，并且发送队列状态应转换为发送队列错误状态，如状态图所示。发生错误的工作请求应错误地完成。

在本地发送队列错误的情况下，发生错误的发送队列上的所有工作请求都由通道接口错误地完成。相应的远程接收队列将不使用工作请求，因此不会出现完成错误。

C10-153：对于本地接收队列完成错误，CI应错误地完成发生错误的接收队列上的工作请求。QP被置于错误状态。所有后续工作请求都应错误地完成。

C10-154：表87 UD发送队列的完成错误处理和表88 UD接收队列的完成错误处理提供了根据错误和工作队列类型，CI必须支持的UD错误处理操作的更详细描述。

表中使用的错误类型的描述包含在**第11.6.2节“完成返回状态”**中。

C10-155：关联的异步错误应导致QP处理停止，从而使通道接口无法成功完成未完成的工作请求。QP应转换到错误状态。在相应的工作队列上进行中的任何请求都应停止并返回完成错误，除非CQ已溢出或无法访问。如果CQ已溢出或无法访问，则不应通过CQ返回正在进行的请求。

### **10.10.3.5 原始QPs**

C10-156：立即错误不会影响QP处理，因为工作请求从未发布到QP。

C10-157：发送队列上的完成错误将导致发送队列处理暂停，并且发送队列状态应转换为发送队列错误状态，如状态图所示。发生错误的工作请求应错误地完成。

C10-158：对于本地接收队列完成错误，发生错误的接收队列上的工作请求应由CI错误地完成。QP被置于错误状态。所有后续工作请求都应错误地完成。

C10-159：表89原始数据报发送队列的完成错误处理和表90原始数据报接收队列的完成错误处理提供了根据错误和工作队列类型，CI必须支持的UC错误处理操作的更详细描述。

表中使用的错误类型的描述包含在**第11.6.2节“完成返回状态”**中。

C10-160：关联的异步错误应导致QP处理停止，从而使通道接口无法成功完成未完成的工作请求。QP应转换到错误状态。在相应的工作队列上进行中的任何请求都应停止并返回完成错误，除非CQ已溢出或无法访问。如果CQ已溢出或无法访问，则不应通过CQ返回正在进行的请求。

### **10.10.3.6 扩展可靠连接**

o10-66.1.1：如果CI支持XRC服务，立即错误不应影响XRC启动器QP或XRC SRQ处理，因为工作请求从未发布到QP。

o10-66.1.2：如果CI支持XRC服务，则发生错误的XRC启动器QP上的工作请求应由CI错误地完成。QP应处于错误状态。所有后续工作请求都将错误地完成。

在本地XRC启动器QP错误的情况下，发生错误的XRC INI QP上的任何和所有工作请求都由通道接口错误地完成。如果本地错误是接口检查，则远程对应的XRC SRQ将不会使用工作请求，因此不会显示完成错误。如果本地错误是处理错误，则远程对应的XRC SRQ可能会或可能不会完成错误的工作请求。RDMA和原子操作的发送队列上发生完成错误时，本地和远程内存的状态在**第10.3.1.7节“错误”**中指定。

o10-66.1.3：如果CI支持XRC服务，则发生错误的XRC SRQ上的工作请求应由CI错误地完成。

o10-66.1.4：如果CI支持XRC服务，则完成错误不会对XRC TGT QP状态产生影响。

o10-66.1.5：如果CI支持XRC服务，关联的异步错误将导致在有问题的XRC对象（XRC INI QP、XRC TGT QP或XRC SRQ）上的处理暂停，从而导致通道接口无法成功完成未完成的工作请求。

XRC对象应转换为错误状态。在相应的工作队列（如果有的话）上正在进行的任何请求都应被停止并返回一个完成错误，除非CQ已经溢出或变得不可访问。如果CQ已溢出或无法访问，则不应通过CQ返回正在进行的请求。

o10-66.1.6：如果CI支持XRC服务，当关联异步错误仅与XRC SRQ关联时，该错误对XRC TGT QP没有影响。如果关联的异步错误与XRC TGT QP相关，XRC TGT QP应转换到错误状态。

o10-66.1.7：如果CI支持XRC服务，则表91 XRC Initiator QP的完成错误处理和表92 XRC SRQ的完成错误处理是根据错误和工作队列类型，CIA必须支持的XRC错误处理操作的更详细描述。

表中使用的错误类型的描述包含在**第11.6.2节“完成返回状态”**中。

## **10.10.4 传输层错误的影响**

在**第9.9节“错误检测和处理”**中定义的不同类型的错误对软件传输接口有不同的影响。某些传输层错误在CI中不可见。其他传输层错误导致通过Verbs报告相应的错误。一般来说，单个传输层错误仅生成一个相应的错误完成（尽管其他工作请求可能被刷新），或者为每个涉及错误的资源（QP、EEC或CQ）生成一个单独的异步错误。

C10-160.2.1：请求方CI应符合表93请求方端错误的Verbs级行为，适用于表59“请求方端错误行为”中规定的所有传输层错误。

C10-160.2.2：响应器CI应符合表61“响应器错误行为摘要”中表94“响应器端错误的Verbs级行为”中规定的行为。

> 参考资料：”IB Specification Vol 1-Release-1.3-2015-03-03.pdf”

> 声明：本文禁止转载！素材来源于网络，仅供学习使用，如有侵权请联系网站删除(ngdcn_admin@163.com)。

Infiniband手册