UCX: An Open Source Framework for HPC Network APIs and Beyond

文章标题：UCX: 一个用于HPC网络API及更高层次的开源框架
作者/机构：
Pavel Shamis, Manjunath Gorentla Venkata, M. Graham Lopez, Matthew B. Baker, Oscar Hernandez (橡树岭国家实验室)
Yossi Itigin, Mike Dubman, Gilad Shainer, Richard L. Graham, Liran Liss, Yiftah Shahar (Mellanox Technologies)
Sreeram Potluri, Davide Rossetti, Donald Becker, Duncan Poole, Christopher Lamb (NVIDIA Corporation)
Sameer Kumar, Craig Stunkel (IBM)
George Bosilca, Aurelien Bouteiller (田纳西大学诺克斯维尔分校)

---

A1 主要贡献

本文针对高性能计算（HPC）领域中网络编程模型的可移植性与性能挑战，提出了一个名为统一通信X（Unified Communication X, UCX）的开源网络API框架。

• 核心问题：在HPC领域，系统供应商通常提供定制化的网络硬件和底层接口（如Cray的uGNI, IBM的PAMI, InfiniBand的Verbs）。这导致上层编程模型（如MPI, OpenSHMEM）的开发需要为每一种硬件进行定制和优化，产生了大量的重复工作，使得跨越多代硬件的软件栈维护变得极其困难。现有的通用接口（如GASNet, ARMCI）要么针对单一编程模型，要么局限于特定网络硬件。

• 研究目标：

  1. 解决可移植性挑战：设计一个统一的API、协议和实现框架，使上层通信库能够轻松地跨越不同的底层网络硬件。
  2. 支持下一代架构：为新兴的计算架构提供高效的网络栈，包括大规模多线程节点、异构层级内存、计算加速器（GPU）以及混合编程模型。
  3. 提升协同工作能力：通过统一的底层通信接口，使得在同一应用中使用的多种编程模型（如MPI与OpenACC）能够更好地协同通信和调度资源。
  4. 构建生产级平台：创建一个既能满足生产环境需求的稳定软件，又能为研究人员提供创新平台的框架。

• 主要创新点：

  1. 统一框架设计：UCX将API、协议和实现统一到一个框架中，同时允许根据特定编程模型的需求进行功能定制而不牺牲效率。
  2. 产学研联合设计：该框架由国家实验室（ORNL）、工业界（Mellanox, NVIDIA, IBM）和学术界（UTK, UH）共同设计，融合了Mellanox的MXM、IBM的PAMI和UCCS项目的思想与经验。
  3. 面向未来的架构：UCX特别关注对GPU等加速器和异构内存的支持，通过提供专门的传输层实现，优化了GPU内存之间/之间以及与主机之间的通信，为在GPU核心内部发起通信等前沿技术提供了基础。
  4. 分层与模块化设计：UCX架构分为UC-Services (UCS)、UC-Transports (UCT) 和 UC-Protocols (UCP) 三个可独立使用的组件，提供了从底层硬件抽象到高层通信协议的灵活性，便于未来扩展和创新。

A2 方法细节

UCX是一个为现代互连网络设计的API框架，其目标是为实现可移植、可扩展且高效的多种编程模型库和语言建立一套接口。

为新兴Exascale技术设计。该框架在设计时审慎考虑了新兴的Exascale技术，如大规模并行计算节点、加速器和层级化内存。UCX架构为多线程驱动的高性能通信、异构内存层级内的通信以及包括I/O和数据中心库在内的混合编程模型提供了软件构造。我们没有构建一个“一刀切”的单一接口，而是设计了一个框架，该框架提供了使用不同抽象层次构建各种通信协议所需的组件。这样的设计提供了高度的灵活性，使得为新兴和未来的编程模型实现新的网络协议成为可能。

对加速器的支持。例如，加速器被期望成为Exascale系统设计的关键组成部分。像GPUDirect RDMA 【索引10，NVIDIA GPUDirect RDMA】和GPUDirect Async 【索引11，GPUDIRECT: Integrating the GPU with a Network Interface，2015，GPU Technology Conference】这样的新功能允许基于GPU的工作流以最少的CPU干预来运行，从而让CPU可以处理其他更通用的任务。在通过PCIe和NVLink将GPU连接到节点时产生的层级结构及其带来的性能特性，在设计用于GPU内存通信的运行时需要特别考虑。更具体地说，为了实现在GPU核心内部支持通信的愿景【索引12，TOC-centric Communication: A Case Study with NVSHMEM，2014，OpenSHMEM User Group Meeting】，高性能在高度线程化的环境中至关重要。UCX为加速器内存提供了一个独立的传输层，这使得实现可以根据GPU间通信的设计需求进行定制。

UCX框架的三大组件。UCX框架由三个主要组件构成：UC-Services (UCS)、UC-Transports (UCT)和UC-Protocols (UCP)。这些组件中的每一个都暴露了一个公共API，并且可以作为独立的库使用（如图1所示）。

UCS服务层。UCS是一个服务层，为实现可移植和高效的实用工具提供了必要的功能。该层暴露了以下服务：
* 一个用于访问平台特定功能的抽象（原子操作、线程安全等）。
* 用于高效内存管理的工具（内存池、内存分配器和内存分配器钩子）。
* 常用的数据结构（哈希表、树、列表）。

UCT传输层。UCT是一个传输层，它抽象了各种硬件架构之间的差异，并提供了一个底层API，使得通信协议的实现成为可能。该层的主要目标是以最小的软件开销提供对硬件网络资源的直接和高效访问。为此，UCT依赖于供应商提供的底层驱动程序，如InfiniBand Verbs、Cray的uGNI、libfabrics等。此外，该层还为通信上下文管理（基于线程和应用级别）以及设备特定内存（包括加速器中的内存）的分配和管理提供了构造。在通信API方面，UCT为立即（short）、缓冲复制发送（bcopy）和零拷贝（zcopy）通信操作定义了接口。short操作针对可以原地发布和完成的小消息进行了优化。bcopy操作针对通常通过所谓的“反弹缓冲区”（bouncing-buffer）发送的中等大小消息进行了优化。最后，zcopy操作暴露了零拷贝的内存到内存通信语义。

UCP协议层。UCP通过使用UCT层暴露的底层能力，实现了消息传递（MPI）和PGAS编程模型通常使用的高级协议。UCP负责以下功能：库的初始化、通信传输方式的选择、消息分片和多路通信。目前，该API具有以下几类接口：初始化、远程内存访问（RMA）、原子内存操作（AMO）、主动消息、标签匹配和集合操作。

初始化接口。这个接口子集定义了通信上下文的设置、查询网络能力以及初始化本地通信端点。由UCX上下文表示的上下文是网络传输资源的抽象。通信端点设置接口初始化UCP端点，这是与特定连接相关联的所有必要资源的抽象。通信端点在所有通信操作中作为输入，用以描述通信的源和目的地。

远程内存访问 (RMA) 接口。这个接口子集定义了单边通信操作，如PUT和GET，这对于实现分布式和共享内存编程模型所需的低开销、直接内存访问通信构造至关重要。UCP为通信非连续数据包含了一套独立的接口。包含此功能是为了支持各种编程模型的通信需求，并利用现代网络硬件的散播/收集（scatter/gather）能力。

原子内存操作 (AMO) 接口。这个接口子集为在远程内存上原子地执行操作提供了支持，这是PGAS编程模型（特别是OpenSHMEM）的一类重要操作。

标签匹配接口。该接口支持发送-接收语义的标签匹配，这是MPI规范定义的关键通信语义。

主动消息接口。这是一个功能子集，其中传入的数据包会调用一个由发送方指定的回调函数，以便由接收进程进行处理。例如，双边MPI接口可以很容易地基于这一概念实现【索引13，Open MPI: Goals, Concept, and Design of a Next Generation MPI Implementation，2004，European PVM/MPI Users’ Group Meeting】。然而，这些接口更通用，适用于接收进程不预先发布接收（pre-post receives）但期望直接对传入数据包做出反应的其他编程范式。与RMA和标签匹配接口一样，主动消息接口为不同类型的消息和非连续数据提供了独立的API。

集合操作接口。这个接口子集定义了组通信和同步操作。集合操作包括Barrier、All-to-one、All-to-all和归约操作。在可能的情况下，我们将利用硬件对集合操作的加速，例如InfiniBand交换机的集合操作加速。

A4 实验

实验环境

本评估展示了UCX框架内UCT层的初步功能，重点测试了InfiniBand传输层。

• 硬件配置：
  • 服务器：2台HP ProLiant DL380p Gen8服务器。
  • CPU：每台服务器配备2颗Intel Xeon E5-2697 2.7GHz CPU，总计24个CPU核心。
  • 网络：服务器通过Mellanox SX6036交换机连接，每台服务器使用一块单端口的Mellanox Connect-IB FDR主机通道适配器（HCA）。
• 软件配置：
  • 固件与驱动：HCA固件版本为10.10.5056，Mellanox OFED版本为2.4-1.0.4。
  • 底层接口：实验使用了一个在开放结构联盟（OFA）Verbs工作组背景下开发的加速Verbs驱动程序（Accelerated Verbs driver）原型实现，并与标准的Verbs驱动进行对比。
• 测试基准：实现了一套UCT微基准测试程序，用于测量不同操作的延迟、带宽和消息率。

实验结果

实验结果表明，UCX原型实现的性能非常接近底层驱动的性能。

• 延迟测试（Latency）：

  • 实验内容：使用ping-pong模式测量PUT操作（short和bcopy类型）的延迟；使用单边读操作测量GET操作的延迟。
  • 实验结果：
    • 对于1字节消息的PUT操作，使用加速Verbs的UCT short延迟为0.89µs，使用常规Verbs为0.91µs。
    • UCT bcopy延迟更高，因为它包含了memcpy到反弹缓冲区的开销。
    • 对于1字节的GET操作，使用加速Verbs和常规Verbs的延迟分别为1.79µs和1.83µs。
  • 结论：UCT short操作的延迟开销极低，几乎与底层驱动持平。

• 带宽测试（Bandwidth）：

  • 实验内容：使用为带宽优化设计的UCT zcopy（零拷贝）操作来测量PUT和GET的带宽。
  • 实验结果：UCT zcopy操作（PUT和GET）均达到了6138.5 MB/s的带宽。
  • 结论：该带宽是单端口FDR InfiniBand硬件所能支持的实际峰值带宽，表明UCX可以充分利用硬件的带宽能力。

• 消息率测试（Message Rate）：

  • 实验内容：通过从一个节点向另一个节点发起多个short或bcopy PUT请求来测量消息率。
  • 实验结果：
    • 使用加速Verbs驱动时，UCT short和bcopy操作的消息率达到了每秒1400万次操作（单核）。
    • 该性能是使用常规Verbs驱动的两倍以上。
  • 结论：UCX能够实现极高的消息率，并且能从优化的底层驱动中获得显著的性能提升。

A5 结论

本文介绍了UCX框架的设计、架构、接口和协议，该框架旨在为并行编程模型的实现提供统一、高效的网络API。通过原型实现和性能评估，我们验证了设计决策的有效性，证明了UCX在实现MPI和OpenSHMEM等模型所需的基本通信原语上具有出色的性能特征，其延迟、带宽和消息率均接近底层硬件的极限。

未来的工作将首先集中于使用UCX提出的接口和协议来实现MPI和OpenSHMEM。之后，将扩展UCX以适应混合编程模型，并为I/O应用提供支持。

方法细节中引用的参考文献

• 【10】NVIDIA Corp. NVIDIA GPUDirect RDMA. https://developer.nvidia.com.

  • 引用段落：A2 方法细节，第3段
  • 引用描述：在讨论对加速器的支持时，引用GPUDirect RDMA作为一项允许GPU工作流以最小CPU干预运行的新功能。

• 【11】D. Rossetti, “GPUDIRECT: Integrating the GPU with a Network Interface,” in GPU Technology Conference, 2015.

  • 引用段落：A2 方法细节，第3段
  • 引用描述：与GPUDirect RDMA一同被引用，作为支持GPU高效通信的新技术之一。

• 【12】Sreeram Potluri, “TOC-centric Communication: A Case Study with NVSHMEM,” in OpenSHMEM User Group Meeting, 2014.

  • 引用段落：A2 方法细节，第3段
  • 引用描述：用于说明在高度线程化的环境中，为了实现从GPU核心内部支持通信的愿景，高性能至关重要。

• 【13】E. Gabriel, G. E. Fagg et al., “Open MPI: Goals, Concept, and Design of a Next Generation MPI Implementation,” in Proceedings, 11th European PVM/MPI Users’ Group Meeting, Budapest, Hungary, September 2004, pp. 97–104.

  • 引用段落：A2 方法细节，倒数第2段（主动消息接口）
  • 引用描述：作为一个例子，说明双边MPI接口可以很容易地在主动消息（Active Message）这一概念之上实现。