RDMA

接上篇(RDMA - IB规范卷1 - 传输层2(可靠服务)):

9.7.8 可靠数据报

可靠数据报提供可靠的通信，即与可靠连接相同级别的可靠性和错误恢复，采用一对多范式。请求者的发送队列可以按顺序向不同的响应者发送消息，这些响应者位于不同的 QP 上。相同或不同的节点。响应者 QP 可能从相同或不同端节点上的多个请求者接收消息。与不可靠数据报传输服务一样，源端节点和源 QP 会提供给响应者。使用可靠数据报的目的是为进行“全对全(all to all)”通信的应用程序节省 QP 名称空间。假设有 N 个处理器节点，每个节点有 M 个进程。如果所有 M 个进程都希望与所有节点上的所有进程通信，则可靠连接服务需要在每个节点上建立 M的2*(N-1)次幂 个 QP。相比之下，可靠数据报服务只需要在每个节点上建立 M 个 QP + N 个“端到端”(EE) 连接即可进行完全相同的通信。可靠性是通过为每个远程端节点使用至少一个“类似 QP(QP-like)”的上下文来实现的——这称为端到端上下文（EE 上下文或 EEC）。此上下文提供定位远程节点、序列化和交换确认以及维护可靠性所需的信息。该服务仍然使用 QP 来提供队列、工作队列单元 (WQE) 指针、保护检查参数等。QP 和 EEC 共同包含将消息可靠地移动到目标所需的信息。但是，许多 QP 可能使用单个 EEC 进行发送或接收，并且 QP 可以通过多个不同的 EEC 进行通信，每个消息选择一个。当应用程序确定要与之通信的目标时，它必须首先建立（或使用已建立的）EE 上下文。与可靠连接一样，用于此服务的本地 QP 由应用程序在使用前在 RD 服务模式下建立。远程 QP 的选择方式取决于应用程序。创建 EE 上下文后，客户端可以通过此 EE 上下文向响应者 QP 发送消息。客户端必须指定本地 EE 上下文编号、响应者 QP、Q_Key 以及任何其他消息参数。然后，实现将来自每个源 QP 的消息“复用”到相应的 EEC，并发送消息。当消息到达目的地时，实现会使用 EE 上下文验证数据包，并将消息“解复用”到相应的 QP。可靠数据报服务使用的方法（PSN、ACK/NAK 协议等）如前文 9.7 可靠服务（第 312 页）中所述。9.7.8.1 可靠数据报特性

表 53 可靠数据报 QP 特性

o9-100：声称支持 RD 模式的 CA 应提供能够支持 RD 的 QP。在 RD 模式下运行时，这些 QP 允许将连续的 RD 消息发送到位于相同或不同节点上的不同目标 QP 的不同响应者。在 RD 模式下运行时，这些 QP 应能够接收来自相同或不同端节点上的多个请求者的 RD 消息。o9-101：声称支持 RD 模式的 CA 应提供 EEC，以允许在多个 QP 之间“复用”多数据包 RD 消息流量，同时保持可靠性（消息最多从请求者传递到响应者一次，按顺序且无损坏，或通知上层。）o9-102：声称支持 RD 模式的 CA 应确保在同一 EEC 上发送另一条消息之前，发送者已完成一条 RD 消息（完全确认或错误完成）。 o9-103：声称支持 RD 模式的 CA 应确保在同一 QP 上发送另一条消息之前，发送方已完成 RD 消息（完全确认或错误完成）。o9-104：声称支持 RD 模式的 CA 应满足第 260 页上的 9.2.1 操作码 (OpCode) 中规定的 RD OpCode 编码要求、第 267 页上的 9.3.1 可靠数据报扩展传输头 (RDETH) - 4 字节中规定的该报头创建要求，以及第 301 页上的 9.6 数据包传输头验证和第 312 页上的 9.7 可靠服务至 9.7.6 中规定的用于处理 RD 消息的可靠传输要求。o9-105：声称支持 RD 模式的 CA 在处理 RD 消息时应满足第 431 页上的 9.9 错误检测和处理中规定的要求。 o9-106：声称支持 RD 模式的 CA 应支持在 EEC 之间建立连接，定义见第 12 章：通信管理（第 716 页），使用第 13 章：管理模型（第 781 页）中定义的管理设施。o9-107：声称支持 RD 模式的 CA 应确保与底层 EE 上下文无关的 RD 消息错误或事件（例如 Q_Key 或 R_Key 违规或 RNR-NAK）不会导致该 EE 上下文关闭或阻止 EE 上下文处理发往其他 QP 的其他 RD 消息。 o9-108：声称支持 RD 模式的 HCA 应提供对 RD 模式下的发送、RDMA 写入、RDMA 读取和原子操作的支持，其范围在 11.2 传输资源管理 (第 596 页) 中定义和报告。o9-109：声称支持 RD 模式的 HCA 应提供对 EEC 管理的支持，如 10.2.7 端到端上下文 (第 481 页) 和 11.2.9 EE 上下文 (第 645 页) 中定义。o9-110：声称支持 RD 模式的 HCA 应提供对 RDD 域的支持，如 10.2.8 可靠数据报域 (第 483 页)、11.2.1.7 分配可靠数据报域 (第 605 页) 和 11.2.1.8 解除分配可靠数据报域 (第 606 页) 中定义。实现说明：对于许多实现， EEC 实际上是通用 QP 或 EE 上下文的一种特殊“模式”。对于这些实现，指定为目标 EEC 的上下文编号必须设置为可靠数据报“EEC”模式。到达未设置为“EE 上下文”模式的上下文（由报头中的 EE 上下文字段标识）的可靠数据报数据包将被静默丢弃。响应方 QP 上下文必须设置为支持可靠数据报传输服务。如果可靠数据报数据包到达未配置为 RD 操作的 QP 上下文，响应方应以“NAK 无效 RD 请求”进行响应。此服务的一个重要区别在于，与底层 EE 上下文无关的错误不会导致该 EE 上下文关闭。例如，Q_Key 或 R_Key 违规。类似地，由与接收方 QP 相关的资源引起的接收方未就绪 (RNR NAK) 不会阻止 EE 上下文处理发往其他 QP 的消息。在消息传输或接收期间检测到的与 EE 上下文相关的错误（超过重试限制等）应在 WR 完成中报告。与请求方或响应方 QP 相关的错误应在 WR 完成中以通常的错误语义报告。有关错误的更完整讨论，请参见第 431 页的 9.9 错误检测和处理。由于端到端信用机制在“无连接”类型的服务中不实用，如果请求方的 SEND 到达而响应方的接收队列为空，则响应方应发送 NAK 接收器未就绪响应。有关更多详细信息，请参见第 361 页的 9.7.5.2.8 RNR NAK。为了保持此服务所需的排序规则，并降低设计复杂性，此服务上的消息每次从源 QP 发送一条，要求在下一条消息开始之前，请求 QP 必须收到每条消息的确认

9.7.8.2 RD 操作示例

以下内容并非规范性材料，仅用于阐明此主题。这些示例基于 HCA 实现；其他实现也是可能的。例如，TCA 可能不使用虚拟内存，并且可能会修改此示例的其他细节。此实现示例维护一个用于 WR 的标准发送队列。它还维护一个发送 QP 的链表，该链表锚定在每个 EEC 上。该链表包含 QP，每个 QP 的发送队列头部都有一个 WR，该 WR 的目的地是 EEC。为了管理数据包和消息的有序传输，此实现使用了一个调度程序。该调度程序维护一个包含待发送数据包的 EEC 列表。当每个 EEC 到达调度程序列表头部时，将发送一个或多个数据包（取决于 QoS 和其他此处不重要的因素）。在响应方，此实现示例维护一组标准的接收队列。该实现还在每个 EEC 中维护空间，用于复制处理单个传入消息所需的参数。这些参数从 QP（PD、CQ、Q_Key 等）和接收 WQE（数据段 L_Key、虚拟地址、大小等）复制。这样，即使消息包含许多数据包，EEC 也拥有足够的信息来处理整个消息，而无需进一步引用 WQE 或 QP。 “无连接”可靠数据报服务的两种视图。右图显示了 3 个处理器上 4 个进程之间的可靠数据报通信的软件视图。在此示例中，进程 E 与进程 C 和 D 之间没有通信，否则，进程 A 可以向所有其他进程发送消息和从其他进程接收消息。图的下半部分显示了 CA 用于合成可靠数据报服务的多个 EE 上下文。每个上下文都显示了它用来“连接”其他上下文的一些状态。SendQ 4 状态显示了三条消息的目的地； ReceiveQ 状态显示成功传输这些消息后的队列

9.7.8.2.1 出站请求示例

1. 可靠数据报的客户端将一条发送消息（由 WQE 描述）发布到其 QP 的发送队列。该消息包含： • 描述发送消息的数据段列表（虚拟地址、L_Key 和长度） • 本地 EE 上下文编号 • 目标 QP 编号 • 目标 Q_Key
2. 当 WQE 到达发送队列的头部（通过 QP 上下文中的指针找到）时，通过 WQE 定位 EE 上下文，并将 QP“链接”到 EEC 的“QP 列表”进行处理（EEC 包含入队和出队指针，每个 QP 包含指向下一个要运行的 QP 的链接指针。取出入队指针处的 QP，更新其“下一个”链接以指向新的 QP，并将入队指针调整到新链接的 QP）。如果 EEC 当前没有发送消息，EEC 也会被放入调度程序。
3. 当 EEC 被安排发送消息时，HCA 通过访问 EEC“QP 列表”头部的 QP（从出队指针处获取 QP）并使用 QP 的工作队列指针来定位 WQE 参数。
4. 硬件使用入队进程的内存保护参数（与 QP 上下文一起存储）以及来自 WQE 的虚拟地址等。这使得发送队列硬件可以直接访问每个发送消息缓冲区的进程的虚拟地址空间。
5. HCA 硬件读取数据缓冲区，构建传输头（包括与 EE 上下文关联的“数据包序列”号），并将数据包放到线路上。
6. 此过程从步骤 3 开始重复，直到整个消息发送完毕。 “EE 上下文”的服务调度算法与可靠连接 QP 的调度算法相同。
7. 消息发送完成后，CA 会等待该消息的所有确认消息都已收到。
8. 由于 EEC 必须等待消息确认消息才能继续（一次只能发送一条消息），因此会为 EEC 设置一个适当的超时时间，并更新 EE 上下文。
9. 当最后一个 ACK 消息到达且 WQE 完成后，HCA 会确定是否有其他 WQE 已发布到当前 QP（位于 EEC QP 列表头部的 QP）。如果是，则会检查下一个 WQE，以找到 QP 下一条消息的 EEC（该 EEC 可能与当前 EEC 不同）。然后，CA 会将该 QP 从当前 EEC 的 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 上下文编号”。序列号信息与连接到请求主机的 EE 上下文一起存储。
3. 将传入请求的序列号与连接到请求节点的 EE 上下文的状态进行比较。
4. 如果序列号和其他数据包内容正确，则目标 QP 的内存保护和 WQE 条目信息将临时复制到 EE 上下文。此实现非常有用，因为其他 EEC 可能以同一 QP 为目标，并且其他消息最终会发送到同一 QP。通过将 WQE 和内存相关信息复制到 EEC，QP 可以自由地指向后续 WQE 以接收其他消息。这也是接收 WQE 可能无序完成的原因。
5. 完成内存保护检查，如果接收缓冲区有效，则将传入请求写入内存（或者，如果是 RDMA READ，则存储以供后续处理）。
6. CA 将 EEC 置于调度程序上，以发送 ACK 响应。
7. 如果数据包是“only”，则 CA 使用 EEC 的 WQE 和 QP 值副本完成消息，而无需额外引用 QP 或 WQE。

中间或最后一个数据包

1. 对于来自同一消息的后续数据包，仅根据报头 EEC 编号访问 EE 上下文。这允许其他 EEC 独立使用 QP 接收队列中的其他 WQE。
2. 如果序列号和其他报头检查正确，则完成内存保护检查，并且如果接收缓冲区
3. 如果 ffer 有效，传入的请求数据将写入内存。
4. CA 将 EEC 放入调度器以发送 ACK 响应。
5. 如果该数据包是“最后一个”，则 CA 使用 EEC 的 WQE 和 QP 值副本完成消息，而无需额外引用 QP 或 WQE。

9.7.8.2.3 出站确认示例

当 EEC 到达调度器队列的头部时，CA 注意到必须发送 ACK，并发送该 ACK。如果在 EEC 到达调度器头部之前有多个数据包到达，则会创建一个合并的 ACK。EE 上下文的最后一个有效接收序列号将根据 ACK/NAK 规则在 ACK 数据包中发送。如果操作是 RDMA 读取，则可能需要多个响应数据包。在这种情况下，EEC 在每个数据包之后放回调度器，直到响应的 PSN 达到预期的 PSN。

9.7.8.2.4 入站确认示例

返回的 ACK 响应表示请求数据包已成功完成。当 ACK 到达时，将检查 EE 上下文并检查返回的 PSN。如果这是预期的（下一个连续的）ACK，则更新预期的 PSN。如果这是消息的最后一个 ACK，并且所有先前的数据包都已确认，则可以使用 EEC 的 QP 和 WQE 信息副本完成该消息。如果 ACK 不是连续的，则适用通常的合并 ACK 规则。由于一次只有一条消息处于未完成状态，因此一次也只会确认一条消息。对于 RDMA 读取，CA 使用 EEC 复制的 QP 保护信息和 WQE 数据段信息来存储数据。

9.7.8.3 可靠数据报操作

其处理过程与可靠连接服务的定义非常相似。显著的区别在于响应方对重复数据包的处理，以及请求方重复请求的规则。这些区别以斜体突出显示。

9.7.8.3.1 发送和 RDMA 写入（立即数据处理）

发送和 RDMA 写入（立即数据）的处理方式与可靠连接服务相同，但端到端信用不会返回给发送方 QP。o9-111：声明支持可靠数据报服务的 CA 应使用 NAK-RNR 协议来指示接收队列中 RD 消息的溢出。

9.7.8.3.2 RDMA 读取处理

RDMA 读取的处理方式与可靠连接服务相同。传入的请求存储在响应者的“隐藏资源”中，并附加到EE上下文，并从QP上下文访问或复制内存保护信息。与可靠连接服务不同，单个QP或EEC中未完成的RDMA读取请求消息数量应限制为1。

9.7.8.3.3 原子处理

原子处理方式与可靠连接服务相同。传入的请求存储在响应者的“隐藏资源”中，并附加到EE上下文，并从QP上下文访问或复制内存保护信息。与可靠连接服务不同，单个QP或EEC中未完成的原子请求数量应限制为1。

9.7.8.4 排序规则

接收队列是FIFO队列。入队后，WQE应按FIFO顺序开始处理，但可以乱序完成。来自任何单个源 QP 的消息都应始终保持顺序。o9-112：声称支持 RD 模式的 CA 应提供上层支持，以应对 RD 消息的无序接收队列完成。发送队列是 FIFO 队列。入队后，WQE 应按照入队的顺序进行处理以进行发送。o9-113：声称支持 RD 模式的 CA 应确保 RD 模式下发送队列中的 WQE 按顺序完成，无论它们的目标是相同或不同端节点上的不同目标 QP 还是相同的目标 QP。WQE 的完成应始终按照 FIFO 顺序返回给传输消费者。这并不意味着实现必须以任何特定顺序将消息的数据部分放置在内存中。因此，在消息至少一侧标记为完成之前，无法保证到达顺序。应用程序应预期内存缓冲区在消息完成之前处于未定义状态。请注意，在同一 HCA 上，不同 QP 的发送队列中，如果队列指向同一目标端节点，甚至指向同一目标 QP，则队列中的项目彼此之间没有排序。例如，如果发往目标“X”和 QP“75”的 WQE“A”被发送到 QP 1，而发往目标“X”和 QP“75”的 WQE“B”随后被发送到同一 CA 的 QP 2，则无法保证“A”先于“B”到达目标。o9-114：对于声称支持 RD 模式的 CA，上层必须容忍来自不同发送 QP 的 RD 消息之间缺乏排序。也就是说，在同一 HCA 上，发往同一目标端节点，甚至指向同一目标 QP，不同 QP 的发送队列中，如果队列中的项目彼此之间没有排序。

9.7.8.5 HANDLING QP 错误 - 重新同步

由于 RD 服务允许多个 QP 共享单个 EEC，因此希望错误发生在的 QP 不会影响共享同一 EEC 的其余 QP。为此，RD 服务允许 EEC 在某些错误条件下“放弃”或“暂停” QP 上的操作。如果消息在源 QP 上错误完成，并且 QPn 转换为错误状态，则该消息将被“放弃”。如果消息未在源 QP 上完成，但另一条消息在同一 EEC 上启动，则该消息将被“暂停”。稍后恢复时，如果是发送操作或立即执行的 RDMA 写入操作，则必须从头开始执行暂停的消息。如果是 RDMA 读取或不立即执行的 RDMA 写入操作，则可以（实现选择）从中断处重新启动，但对于响应者来说，必须看起来像是一条新消息。 “暂停(Suspend)”和“重启(Restart)”仅适用于 RNR NAK 情况，即响应方暂时无法执行与特定 QP 相关的请求，请求方可以在等待 RNR NAK 超时的同时，通过从同一 EEC 上的其他 QP 发送消息来提高性能。请求方不允许暂停原子操作。为了方便起见，我们有时会将“放弃”或“暂停”的含义说成是“中止(aborted)”。“放弃(abandoned)”或“暂停”的概念确实需要 RD 服务处理与消息相关的数据包延迟、重复或两者兼而有之时可能发生的一类错误。为了解决这个问题，每当消息被“放弃”或“暂停”时，都需要执行 RESYNC 操作。下图 111 显示了此问题的一个示例，其中响应方实际执行了一个 RNR 请求。

如果请求方只是在原始 PSN 上发起一条新消息，则可能会发生数据损坏。此外，当请求方稍后重新启动 RNR NAK 消息时，响应方将收到两份副本。为了解决这个问题，在发生任何影响 QP 的错误后，都会使用 RESYNC 机制，但 EEC 仍能继续运行。RESYNC 机制有多种用途：它使 EEC 两端的 PSN 保持同步；它让响应方知道如果上一条消息不完整，则应将其丢弃；它还允许请求方确定响应方当前消息的状态。以下流程图展示了请求方的重新同步过程。

下面的梯形图说明了 RESYNC 操作如何解决图 111 中描述的问题。RESYNC 过程允许两端就适当的 PSN 达成一致，确定响应方中止消息的状态，并通知响应方中止正在进行的消息（如果是这种情况）

RESYNC 解决的另一个问题是处理“幽灵”数据包。例如，一条多数据包消息的早期数据包出现错误，请求者将发送队列放入 SQEr，最终上层将发送队列设置为RTS。与此同时，一个fabric“事件”导致数据包严重延迟。

在上图中，“r3”由于极度延迟，在相同QP的消息数据包处理过程中到达响应方。在这种情况下，响应方必须将“r3”视为重试数据包。因此，除非安排确认，否则它将被忽略，至少对于发送和RDMA写入操作而言是如此。对于RDMA读取，响应方必须创建显式响应。如果正确的RDMA读取已在进行中，则必须中断该读取并生成不同的响应。这将在请求方处创建幽灵响应，并导致其RDMA读取请求超时，并重试以进行恢复。对于原子操作，响应在请求方处也会出现幽灵或意外响应。无论哪种情况，它都会被丢弃，操作将恢复。如果没有执行RESYNC，消息2将以PSN = 2开始。在 PSN=3 处接收 'r3' 可能会造成数据损坏问题。o9-114.a1：对于声称支持 RD 模式的 CA，当 RD 模式下的消息发生 QP 相关错误时，请求者可以：

1. 将 QP 和 EEC 转换为错误状态，并以错误方式完成消息；或
2. 按照第 401 页 9.7.8.5 处理 QP 错误 - RESYNC 中的说明执行 RESYNC 流程。

RESYNC 请求的生成方法在第 324 页 9.7.3.2.2 RESYNC 生成中进行了描述。o9-114.a2：对于支持 RD 传输服务的 CA，在发送 RESYNC 后，请求者应在 RESYNC PSN 处等待 Ack。其他响应均无效。通常，应设置 AckReq 位以确保响应者安排响应。如果没有收到正确的响应，则 RESYNC 应该超时，并以通常的重试次数重试，如第 371 页 9.7.6.1.3 节“检测丢失的确认消息和超时”中所述。通常，请求者在从 EEC 发送另一条消息之前，会将请求 PSN 更新 1。RESYNC 响应实际上可能完成两条消息：前一条消息和“RESYNC”消息。

9.7.8.6 响应者生成 MSN

对于可靠数据报服务，消息序列号 (MSN) 是由响应者返回给请求者的数字，指示响应者在 EE 上下文中完成的消息数量。MSN 包含在 AETH 的三个最低有效字节中。MSN 通过通知请求者响应者已完成的消息来协助请求者完成 WQE。 o9-114.a3：在实现可靠数据报服务的 CA 中，响应方应在每个响应数据包的 AETH 中返回 MSN。o9-114.a4：使用可靠数据报服务的 CA 响应方应将其 MSN 值初始化为零。响应方应在成功处理新的有效请求消息后递增其 MSN。重复请求的 MSN 不应递增。递增后的 MSN 应在 RDMA READ 或原子响应的最后一个或唯一一个数据包中返回。

9.7.8.6.1 请求方接收新 MSN 时的行为

响应数据包中存在新的 MSN 值，请求方可将其用作消息完成的信号。“RESYNC”消息响应中的 MSN 也可用于确定上一条消息的完成状态： • 如果由于之前的重试，上一条消息实际上已完成，则 MSN 将比 NAK 响应中返回的最后一个值高 2。 • 如果上一条消息是发送消息或 RDMA 写入消息，则该消息应正常完成（这意味着它最终没有被放弃或暂停）。 • 如果上一条消息是 RDMA 读取消息，请求方未收到返回数据，因此仍必须根据错误类型暂停或放弃该消息。 • 如果上一条消息是原子消息，则必须以错误方式完成，并可能向上层返回附加信息“响应方已知完成”。 • 如果 MSN 与预期一致（比上一个值大 1），则应正确处理上一条消息： • 如果该消息被放弃，则表示已错误完成，并附加信息表明该消息“响应方已知不完整”。 • 如果该消息是发送消息或立即执行的 RDMA 写入消息，则表示未启动，稍后将重试。 • 如果该消息是非立即执行的 RDMA 读取消息或 RDMA 写入消息，则表示未完成，稍后将作为一条新消息重新启动。

如果 MSN 为其他值，则表示响应已损坏，EEC 应置于错误状态。

9.7.9 XRC

9.7.9.1 简介

XRC 可以显著节省在大型集群中建立全进程连接所需的 QP 数量。多核处理器的既定趋势直接导致在典型的 IB 连接集群的每个终端节点上运行的进程数量增加。多核节点系统如今非常普遍，并且路线图显示，在不久的将来，每个节点将拥有更多核心。

使用可靠连接 (RC) 传输服务时，每个端节点实现完整进程到进程连接所需的 QP 数量等于 N * p * p（其中 N 是集群中的节点数，p 是每个节点的进程数）, 在某些部署中，进程可能不需要 QP 与同一节点上的其他进程进行通信。在这种情况下，计算所需的 QP 数量时，应使用 N-1 的数值（此处使用 N）。随着进程数和每个系统的核心数一起增长，RC QP 的数量（及其相关的内存资源）开始变得重要。XRC 在几个方面不同于 RD，但首先也是最重要的，它消除了 RD 传输服务的最重要限制，即每个 EE 上下文支持单个未完成消息。使用 XRC，XRC QP 线路上的未完成消息数量没有限制。为了实现这一点，XRC QP 的操作与请求方的常规 RC QP 类似。对于 XRC，SQ 和 EE 上下文之间没有动态关联（与 RD 中一样）。这意味着发起方的 XRC QP（表示为 XRC INI QP）通常是每个进程的，并且静态绑定（通过连接上下文）到单个目标节点。所需 QP 总数的节省是由于 XRC 在响应方的运行方式。响应方连接上下文（表示为 XRC TGT QP）允许请求方进程发送针对多个目标 QP（表示为 XRC SRQ）的消息，这些目标 QP 属于目标节点上的多个进程。因此，使用单个（XRC INI）QP，一个节点中的进程可以与一个远程节点上的所有进程通信，从而将完全连接所需的总 QP 数量减少 p 倍（与使用 RC QP 时相比）。XRC SRQ 是每个进程的目标节点接收队列，可以通过 XRC TGT QP 从多个远程端节点进行定位。它们在某种程度上等同于 RD QP 中的接收队列，因此每个进程只需要一个，即可从集群中任何节点上的任何进程接收消息。这种操作模式要求请求方 (XRC INI QP) 指定每个发布的请求消息的目标 XRC SRQ。此信息通过新的扩展传输头在线路上传输，如第 408 页上的第 9.7.9 节“XRC”中所述。与 RD QP 仅限于与同一可靠数据报域 (RDD) 中的 RD EE 上下文一起使用类似，XRC 传输服务实现了一种等效的 XRC 域机制，用于相同的目的。XRC TGT QP 只能用作访问在同一 XRC 域上设置的 XRC SRQ 的管道。由于 XRC SRQ 的共享特性（接收 WQE 可从多个 XRC TGT QP 获取），端到端信用无法在 ACK 数据包中携带，而是使用无效信用代码（类似于常规 SRQ）。如上所述，可以观察到 XRC 在请求方端的操作类似于 RC，在响应方端的操作类似于 RD。由于这种不对称性，XRC 传输服务中的传输对象具有一些独特的特性，即： • XRC INI QP 与常规 RC QP 类似，但没有响应方端。 • XRC TGT QP 与 RD EEC 类似，但没有请求方端。 • XRC SRQ 与 RD QP 类似，但没有请求方端。

值得注意的是，由于这种不对称性，通过单个 XRC INI/TGT 对进行的 XRC 通信是单向的。 XRC 的另一个特点是，由于响应方 XRC SRQ 没有 SQ，因此无法覆盖诸如窗口绑定、快速注册和本地无效等本地操作，这些操作需要在辅助 RC QP 上执行。此外，XRC 不支持 2 型窗口。根据以上描述，可以轻松计算出在 N 个节点（每个节点有 p 个进程）的集群上实现完全连接需要多少个 XRC 传输对象： • 每个进程需要 N 个 XRC INI QP。每个远程节点上都有一个用于与所有进程通信的 QP。每个节点总共需要 N * p 个 XRC INI QP。 • 每个进程需要一个 XRC SRQ，以便接收来自集群中任何其他进程的消息。每个节点总共需要 p 个 XRC SRQ。 • 假设一个同构集群，其中所有 N 个节点都有 p 个进程，每个节点都有 N*p 个 XRC TGT QP，这些 QP 对应于远程节点上用于定位本地节点进程的 XRC INI QP。

因此，每个节点的队列总数为：N * p 个 XRC INI QP、p 个 XRC SRQ 和 N*p 个 XRC TGT QP。

9.7.9.2 XRC 数据包格式规则

o9-114.a5：单个 XRC 消息的所有数据包都应携带完全相同的 XRCETH。o9-114.a6：响应方应验证第一个/唯一一个入站数据包所标识的 XRCSRQ 的 XRC 域是否与 XRC TGT QP 的 XRC 域相同。响应方可以验证中间/最后一个数据包所标识的 XRCSRQ 是否与消息中所有先前数据包的 XRCSRQ 相同。 o9-114.a7：响应者应使用 XRC 数据包标识的 XRCSRQ 中的 PD（而不是XRC TGT QP）。o9-114.a8：如果消息需要接收 WQE，则响应方应从消息指向的 XRCSRQ 的 RQ 中获取它。o9-114.a9：如果需要为消息生成完成，则响应方应使用 XRC 数据包标识的 XRCSRQ 中的 CQ。o9-114.a10：XRC ACK 数据包中的 E2E 信用（MSN 字段）应设置为“无效”

参考

IB Spec1.6 卷1第9章