本文参考 Understanding Tag Matching for Developers。

简介

消息传递接口（MPI）标准定义了一组规则，称为标签匹配，用于将源发送操作与目标接收操作进行匹配。

以下参数必须与发送方及其对应的接收函数匹配。

  • 通信器（communicator）
  • 用户标签（tag），包括由接收方指定的通配符
  • 源进程，包括由接收方指定的通配符
  • 目标进程

排序规则规定，当有多对发送和接收消息信封匹配时，包含最早发布的发送和最早发布的接收的这对信封必须用于满足匹配操作。然而，这并不意味着标签会按照创建的顺序被消耗，例如，如果较早的标签无法用于满足匹配规则，则较晚生成的标签也可能被消耗。

当消息从发送方发送到接收方时，通信库可能会尝试在对应的匹配接收消息发布之前或之后处理该操作。如果发布了匹配的接收消息，则将其定义为“预期消息”。如果不匹配，则称为“意外消息”。实现通常会为这两种不同的匹配情况使用不同的匹配方案。

为了减小MPI库的内存占用，MPI实现通常仅使用两种不同的协议来实现这一目的：

  1. Eager 协议。当发送方处理发送消息时，会立即发送完整消息。发送方在send_cq中收到完成发送通知，表明缓冲区已释放并可重新使用。
  2. rendezvous 协议。发送方在首次通知接收方有消息即将到达时，会发送与标签匹配的头部，有时还会发送部分数据。当对应的缓冲区被发布时，接收方会利用头部信息直接对匹配的缓冲区发起 RDMA 读取操作。必须收到最终（final）消息后，缓冲区才能被清空并重新使用。

以下是两种协议的工作原理：

fig1

Tag 匹配实现

在标签匹配实现中，有两种类型的匹配对象：已发布接收列表和意外消息列表。应用程序通过调用MPI接收例程将接收缓冲区发布到已发布接收列表中，并使用MPI发送例程发布发送消息。已发布接收列表的头部可由硬件维护，软件则需同步该列表。当发送消息被发起并到达接收端时，如果没有预先发布的接收消息与该到达消息匹配，则发送消息会被传递给软件并放入意外消息列表。如果存在一组匹配的消息，则进行匹配处理，包括适当的会合处理。会合处理将数据交付到指定的接收缓冲区，这允许接收端MPI标签匹配与计算重叠。

当接收消息被发布时，通信库首先检查软件的意外消息列表，以查找与接收消息匹配的条目。如果找到匹配项，数据将通过软件控制的协议传输到用户缓冲区。UCX 实现根据数据大小使用 Eager 或 Rendezvous 协议。如果未找到匹配项，整个预发布接收列表由硬件维护，这释放了空间以向该列表添加另一个预发布接收。此接收消息传递给硬件。软件应同步此列表，以协助处理 MPI 取消操作。由于硬件和软件在标签匹配操作方面不期望紧密同步，此同步列表用于检测预发布接收消息何时被传递给硬件，因为匹配的意外消息正从硬件传递到软件。

fig2

所有标签匹配操作均在接收端进行，因为源排名中使用通配符会导致发送端标签匹配过程的开销非常高。

标签匹配操作会在以下两种情况之一触发：当应用程序发布新的接收消息时，或当网络上收到新消息时。

该匹配过程通过以下三种方式之一进行：

  • 仅在软件中进行
  • 仅在硬件中进行
  • 在多个地址之间进行分割。

如果过程被拆分，对两个列表的访问必须在临界区中处理。

下图展示了一个错误的错误流示例，当标签匹配过程被拆分到两个地址空间时，且没有用于更新两个列表的临界区，标签会被匹配两次。

Verbs API 简介

本节介绍了在多个地址空间中分布匹配列表的支持。接口设计保持通用性，以便任何实现均可使用提供的功能。因此，通信库（用户）的接口将负责处理所有内存注册和临时缓冲区的分配，以及实现特定的标签匹配算法。动词接口将提供用于地址空间之间通信和同步的功能。

从用户界面角度来看，这些动词提供了以下界面功能。它们：

  • 将已发布的接收操作传递给外部上下文
  • 从外部上下文接收已发布的接收操作
  • 将意外消息传递回外部上下文
  • 从外部上下文接收意外消息
  • 撤销外部上下文中的已发布接收操作
  • 撤销外部上下文中的意外消息
  • 同步上下文
  • 从外部上下文接收匹配通知
  • 配置并补充外部资源

工作流

下图展示了基于上述动词接口功能的硬件/软件标签匹配架构的工作流程。

该图展示了标签匹配工作流程，从远程进程发送包含标签、通信器、源、目标以及指向数据缓冲区指针的发送消息开始。通信库负责创建QPs、为临时缓冲区分配空间并注册内存。随后，通信库使用动词函数创建标签匹配头（TMH）。将其与有效负载合并后，通过网络将数据发送至接收端。

通信库处理所有意外的标签匹配。预期的接收标签匹配逻辑可以分为通信库和标签匹配硬件两部分。如果通信库使用外部上下文（硬件）标签匹配，则该发布-接收列表的头部必须由外部上下文“拥有”。此外，通信库必须跟踪外部上下文，以便正确处理操作（如MPI接收取消）。

在接收端，应用程序发布一个接收操作，指定标签、通信器、源排名以及用于存储数据的缓冲区。如果消息未与意外消息匹配，通信库将使用verb函数将操作移交至

如果发送方在应用程序调用接收操作之前将消息发送至接收方，硬件无法在已发布接收列表的头部找到匹配项，因此消息将被转交至软件处理。软件会确保在此期间对应的接收操作未被发布至硬件，随后与已发布接收列表的尾部进行匹配，若必要则将其添加至意外消息列表。

在使用会合协议时，发送侧的通信库将注册用户缓冲区内存而非分配新缓冲区。如果硬件匹配到传入消息，则负责完成会合协议。如果通信库完成匹配，则负责完成会合协议。

动词接口仅负责通信库与硬件之间的通信，其余部分均由通信库负责，并与外部上下文协调。

标签匹配工作流图说明：

  • 蓝色 – 应用程序
  • 绿色 – 通信库
  • 橙色 – 动词
  • 灰色 – 硬件