RoCE协议下基于在网计算的MPI通信优化

引用本文

李嘉群, 蔡文杰, 沈瑜, 齐法制, 曾珊, 李京. RoCE协议下基于在网计算的MPI通信优化. 计算机系统应用, 2022, 31(11): 320-329.http://www.c-s-a.org.cn/1003-3254/8809.html

Li JQ, Cai WJ, Shen Y, Qi FZ, Zeng S, Li J. MPI Communication Optimization Based on In-network Computing under RoCE Protocol. Computer Systems and Applications, 2022, 31(11): 320-329(in Chinese).http://www.c-s-a.org.cn/1003-3254/8809.html

RoCE协议下基于在网计算的MPI通信优化

李嘉群¹, 蔡文杰¹, 沈瑜², 齐法制³, 曾珊³, 李京^1,2

1. 中国科学技术大学计算机科学与技术学院, 合肥 230027;
2. 中国科学技术大学超级计算中心, 合肥 230027;
3. 中国科学院高能物理研究所计算中心, 北京 100049

收稿日期：2022-02-28; 修改日期：2022-03-28; 采用时间：2022-04-21; csa 在线出版时间：2022-07-14

基金项目：中科院先导专项(XDA19020102)

通讯作者：李京, E-mail: lj@ustc.edu.cn.

摘要：高性能计算中, 通信上的巨大开销已成为其算力提升的主要瓶颈之一, 通信性能的优化一直是一个重要挑战. 针对通信优化任务, 提出一种基于在网计算技术降低通信开销的方法. 该方法在基于以太网的超算环境下, 利用RoCEv2协议、可编程交换机以及OpenMPI, 实现将归约计算卸载到可编程交换机, 支持Node和Socket两种通信模式. 在真实超算环境下开展了集合通信基准测试和OpenFOAM应用测试实验, 结果表明, 当服务器节点数达到一定规模时, 该方法在Node和Socket两种模式下相较于传统的主机通信, 均呈现出较好的性能提升, 其中集合通信基准测试有10%–30%左右性能提升, 在应用级测试中应用整体性能有1%–5%左右提升.

关键词: 在网计算 RoCE协议 MPI 通信优化高性能计算

MPI Communication Optimization Based on In-network Computing under RoCE Protocol

LI Jia-Qun¹, CAI Wen-Jie¹, SHEN Yu², QI Fa-Zhi³, ZENG Shan³, LI Jing^1,2

1. School of Computer Science and Technology, University of Science and Technology of China, Hefei 230027, China;
2. Supercomputing Center, University of Science and Technology of China, Hefei 230027, China;
3. Computing Center, Institute of High Energy Physics, Chinese Academy of Sciences, Beijing 100049, China

Abstract: In high-performance computing, the huge communication overhead has become one of the main bottlenecks in the improvement of its computing power, and the optimization of communication performance has always been an important challenge. For the communication optimization task, this study proposes a method based on in-network computing technology to reduce the communication overhead. In the Ethernet-based supercomputing environment, this method utilizes the RoCEv2 protocol, programmable switches, and OpenMPI to offload reduction computation to programmable switches, and it supports the two communication modes of Node and Socket. The collective communication benchmark test and the OpenFOAM application test are carried out in a real supercomputing environment. The experimental results indicate that when the number of server nodes reaches a certain scale, compared with the traditional host communication, this method shows better performance improvement in both Node and Socket modes, with the performance in the collective communication benchmark test improved by about 10%–30% and the overall application performance in the application-level test improved by about 1%–5%.

Key words: in-network computing RoCE protocol message passing interface (MPI) communication optimization high performance computing

1 引言

随着网络带宽增加、延迟降低以及诸如远程直接内存访问(RDMA)等技术的出现, 研究人员开始尝试将科学计算任务中的部分计算操作从CPU卸载到特定网络通信设备上(如可编程交换机), 在高效率利用网络设备高转发能力的同时进一步降低通信开销和CPU负载. 因此, 如何充分利用网络设备的计算能力来实现通信优化, 降低通信成本就成为当前高性能计算领域的研究热点之一.

MPI (message passing interface)^[1]是并行科学应用程序设计上的一种常用并行编程模型, 也是高性能计算软件中常用的并行计算应用程序接口. MPI标准中定义的集合通信操作为组通信操作实现了非常便捷的抽象, 被广泛应用于高性能计算上各种科学领域应用程序中. 这些集合类通信由于涉及全局通信, 往往对应用程序并行效率产生巨大影响. 尽管已有大量研究基于算法优化来提升集合类通信效率^{[2, 3]}, 如图1所示为集合通信Allreduce的一种实现算法, 需要节点间两两多轮次互发消息完成通信, 基于算法优化后的方法依然需要在网络中进行多次通信才能完成整体聚合操作, 因此仍无法避免网络拥塞的发生, 并且这些方法优化后的集合类通信延迟相较于点对点通信仍高出一个数量级以上^[4]. 在网计算主要通过利用FPGA、SmartNIC等网络硬件设备, 使数据在网络上传输的同时在网络设备上进行计算, 从而将集合通信的部分计算卸载到网络通信设备上, 减少通信中路由跳数和网络中传输的数据量, 降低通信总时延.

图 1 MPI集合通信

　本文工作主要针对使用RoCE协议的超算系统的MPI集合通信进行优化. 在开展优化工作前, 调研了大型超算系统MPI调用情况^{[5, 6]}, 同时参考课题组以往对超算应用程序MPI调用情况的分析工作^[7], 有如下发现:

(1) 由文献[6,7]可知, 许多超算应用程序, 如OpenFOAM、VASP等, 在MPI通信上花费了一半以上的时间;

(2)与点对点通信相比, MPI集合通信(MPI_Allreduce、MPI_Alltoall等)花费时间更多, 尤其是MPI_Allreduce;

(3) 短消息, 即短报文( $\leqslant $ 256 字节)在超算应用程序MPI通信数据包中占比最大.

针对以上集合通信特征, 本文面向MPI集合通信优化提出一种基于在网计算的MPI通信优化方法, 在RoCE网络协议下, 实现基于在网计算的MPI集合通信优化. 本文主要工作包括以下3个:

(1) 基于RoCE协议设计扩充支持在网计算的通信协议, 将MPI_Allreduce集合通信的计算操作卸载到可编程交换机进行;

(2) 基于OpenMPI-4.0.5扩展实现MPI_Allreduce集合通信的在网计算Node与Socket模式功能;

(3) 在中科大超级计算平台对在网计算功能进行基准测试验证和对OpenFOAM进行应用级性能验证.

2 相关研究

针对MPI集合通信优化的研究, 研究人员们已开展大量工作来提升通信性能, 并取得了不错的成果. MPI集合通信优化的研究工作主要可分为3类.

(1) 通过改进算法来优化MPI集合通信

Vadhiyar^[3]提出使用顺序、链、二叉树和Raben-seifner算法实现Reduce、Gather和Bcast操作; Hoefler等人^[8]研究无阻塞Allreduce操作的几种实现, 展示使用大型通信器和大型消息时的性能提升; 百度为优化深度学习提出Ring Allreduce; NCCL贴合硬件实现Allreduce^[9], 其实现算法和Ring Allreduce算法相似; 腾讯提出分层的Ring Allreduce^[10], 对节点进行分组, 通过组内Reduce, 组间Allreduce, 然后组内Bcast的步骤, 完成Allreduce操作. 索尼提出2D-Torus Allreduce算法^[11], 主要思想也是分层, 通过组内Scatter-Reduce, 组间Allreduce, 组内Allgather完成Allreduce操作. Google提出2D-Mesh Allreduce算法^[12], 通过两步水平和垂直的环来完成Allreduce操作. 该类优化算法虽然可以降低集合通信的时间复杂度, 但通信时间仍随服务器数目增加而递增, 当服务器数量较多时, 需在网络中进行多次通信, 导致网络中传输的数据量较多.

(2) 针对特定网络拓扑来优化集合通信

该类方法比较典型的是Barnett等人^[13]和Liu等人^[14]的研究, 他们分别针对网格拓扑和超立方拓扑进行优化. 该类优化主要针对特定网络拓扑的特点, 改进算法以优化MPI通信, 但该方法通用性较差, 不适用于普通网络拓扑结构的集合通信优化.

(3) 基于硬件优化集合通信

通常, 大多数MPI是通过节点的CPU进行集合通信数据的计算, 而网络仅用于数据传输. 基于硬件来优化集合通信相对较少, Quadrics^[15]在网络设备硬件中实现对Bcast和Barrier的支持. IBM的Blue Gene超级计算机实现了对Barrier和Reduce的网络级硬件支持, Blue Gene/L^[16]对于Alltoall集合通信提升高达两倍的吞吐量性能. IBM的PERCS系统^[17]完全将集合归约操作卸载给了硬件. Mai等人提出了NetAgg平台^[18], 它使用网络内盒进行分区聚合操作, 以提供高效的网络链路利用. Cray的Aries网络^[19]在HCA中实现了64字节Reduce支持, 支持基数为32的归约树. NVIDIA Mellanox从EDR InfiniBand交换机开始引入的SHARP技术^[20-22], 旨在将集合通信的计算卸载到网络上, 从而提高计算效率, 降低通信时延.该类从硬件角度出发的优化方法, 其优化效果明显, 其中一些工作是为高性能计算应用程序定制的互连架构开发的, SHARP技术基于InfiniBand^[23]实现在网计算, 其网络设备采购成本过高, 且作为商业产品, 代码闭源, 设计和实现的细节未公开, 难以在其上扩展新功能, 且无法在以太网上使用.

综上所述, 现有MPI集合通信优化方法都有其局限性, 本文提出在RoCE协议下, 采用传统以太网网络, 通过将计算卸载到可编程交换机上以提升集合通信性能, 实现数据边传输边计算, 降低网络中传输的数据量, 且能够充分利用当前丰富的以太网资源和硬件优化的优势, 实现低成本高性能集合通信优化的目的, 同时也为基于算法与拓扑结构的通信优化提供了更大的性能提升空间.

3 基于在网计算的MPI通信优化设计与实现 3.1 在网计算设计简介

本文目标是通过在网计算技术实现MPI_Allreduce集合通信的优化, 在通信过程中将部分计算交于可编程交换机执行, 此时交换机不仅可以转发报文, 同时还承担简单的计算工作. 在网计算的基本原理如图2所示, 以两层交换机组网为例, Server Node层的主机节点发送数据时必经过交换机(节点间无直接通信), 通过算法将某些交换机作为聚合节点参与计算. 如图2中一层交换机(TOR_1与TOR_2)均为聚合节点, 可按照一定规则选取某一个二层交换机(如SPINE_1)为聚合节点, 具有计算功能的交换机接收到数据后, 对需要在网计算的数据进行缓存并进行相应的计算, 计算完成后, 将最终计算结果向下层主机节点传递. 利用可编程交换机参与计算可以减少转发的数据量和主机节点的计算量, 达到节省带宽降低时延的效果, 对提高主机节点的计算能力也有帮助. 基于在网计算的MPI_Allreduce通信有如下优点:

(1) 减少网络中通信路由跳数;

(2) 降低总体通信时延;

(3) 减少网络中传输的数据量及主机节点的计算负载.

图 2 基于在网计算的MPI通信

本文针对MPI集合通信优化, 设计并实现了基于在网计算的MPI通信优化方案, 主要包括: 通信报文设计、控制面和数据面设计.

通信报文是在网计算功能实现的载体, 通信报文基于RoCEv2协议进行扩充, 其处理架构如图3所示. 可编程交换机可看成由输入队列、仲裁器、控制器、输出队列、FPGA几个部分组成. 输入队列和输出队列用于暂存数据包. 仲裁器按照包的优先级从输入队列中获取数据包, 并根据报文标识判断是普通报文还是在网计算报文. 如果是普通报文则直接转发; 如果是在网计算报文则转发给FPGA, FPGA对报文进行解析, 对控制报文和数据报文进行相应处理. FPGA处理完后将结果形成新的报文转发.

图 3 在网计算协议处理架构

控制面主要完成协商控制, 即通过可编程交换机参与节点间控制报文的通信过程, 在交换机上创建相应路由表, 根据路由表建立聚合计算逻辑树用于在网计算, 同时主机节点获得可编程交换机关于在网计算的相关参数, 如交换机支持的计算操作类型、数据类型等; 数据面主要负责数据报文的发送与计算. 在网计算的整体流程如图4所示. 在网计算支持Node与Socket两种模式, Node模式仅从节点层面进行考虑, 每个节点选取一个领导者进程用于控制面节点间通信以及数据面节点内进程的聚合和广播. Socket模式是对Node模式的进一步优化, 考虑到一个节点下有多个CPU的情况, 每个CPU下都选取一个领导者进程用于控制面和数据面节点间并行通信以及数据面同一CPU内进程的聚合和广播. Socket模式可以将同一个CPU下的进程划分为同一个通信子域, 降低跨CPU通信的开销, 同时提高节点间通信的并行性.

图 4 在网计算流程

3.2 通信报文设计

为使可编程交换机识别控制报文和数据报文, 实现在网计算功能, 需要设计新的通信协议. 通信协议的设计是对当前以太网RoCE协议的扩充, RoCE (RDMA over converged Ethernet)是RDMA技术在以太网上的一种实现方法. RoCE是一种机制, 其提供在无损以太网上实现极低延迟的高效通信方法. RoCE协议有RoCEv1和RoCEv2两个版本, 其差别取决于系统所采用的网络适配器或网卡.

本文通信协议基于以太网的RoCEv2协议进行设计. 协议设计报文字段如图5所示, 基于RoCEv2协议增加MPI头和payload字段, 协议支持RC和UD两种模式.

图 5 通信报文格式

图5中MPI头和payload主要用于定义一些字段以表示在网计算报文的相关信息, 其中MPI头定义在网计算报文的通用字段, payload在控制报文和数据报文情况下有所不同, 控制报文的payload定义了需要协商的参数, 而数据报文的payload仅用于保存将要进行计算的真实数据. 图5中圆括号内为报文各字段大小. MPI头的关键字段及其相应含义如表1所示, 控制报文payload的关键字段及其含义如表2所示.

表 1 MPI头关键字段及含义

表 2 控制报文payload关键字段及含义

表2中, 控制报文payload字段除了上述关键字段以外, 还有几个非核心字段未详细列出, 包括: sup_mpi_type表示支持的MPI版本; fail_cause表示协商是否成功; dst_rank表示目的地的Rank号(Rank表示进程号, 由MPI分配, 用于区分一个通信域内的进程); tor1_ip表示经过第一个TOR交换机的IP地址; spine_ip表示经过SPINE交换机的IP地址; tor2_ip表示经过第2个TOR交换机的IP地址; job_id表示调度器传入的MPI作业的编号, 以区分不同的任务; c_id表示子通信域的ID; world_rank表示在整个通信域中的Rank号.

3.3 控制面设计

在网计算实现流程中, 控制面的作用主要是让主机节点与网络中的可编程交换机进行交互, 交互过程中主机节点获得交换机上关于在网计算的相关配置参数等信息, 而交换机则根据节点消息, 掌握系统中网络节点分布与节点状态等信息, 建立通信路由表, 生成聚合计算逻辑树, 为后续数据面流程提供通信基础信息.

在网计算控制面和数据面通信流程中存在多个进程间交互, 为便于描述, 对本节和下节中涉及到的相关进程, 统一规定如表3所示.

表 3 Node和Socket模式下进程描述

本节和下一节详细介绍Node模式下控制面和数据面的设计, Socket模式下控制面和数据面与Node模式原理大体相似, 相关差异部分在第3.5节中单独介绍. Node模式下在网计算需满足节点进程Rank全局均匀且连续的约束(该约束可通过OpenMPI实现), 即:

(1) 在参与在网计算的主机节点中, 同一节点下运行的进程数相同且进程Rank号连续;

(2) 不同主机节点上进程Rank号连续;

(3) 同一TOR交换机下不同主机节点进程Rank号连续.

对图6中在网计算控制面核心流程进行详细介绍.

图 6 在网计算控制面流程

(0) Step 0, 控制面初始化阶段. 该阶段会初始化参与在网计算主机节点下的进程, 构建通信域, 将进程划分为SRR (对应前文领导者进程, 包括MRR和NMRR两种)和SR进程, 然后MRR进程会随机生成通信群组的唯一标识ID, 用于标识在网计算群组, 并经由MPI底层点对点通信发送至其他所有进程;

(1) Step 1, query阶段. 所有NMRR进程均经交换机发送在网计算请求报文至MRR进程. 请求报文途经TOR和SPINE交换机, 交换机会对请求报文进行解析处理, 填入其支持的计算类型、数据类型等信息后形成新报文转发. MRR收集请求报文并进行SPINE节点选择(选择通信负载最小的SPINE), 保存SPINE节点信息用于notify阶段, 此时query阶段完成;

(2) Step 2, notify阶段. 当MRR进程收集完所有NMRR进程的请求报文后, 会根据请求报文判定SPINE交换机的选取, 及确定所有交换机共同支持的在网计算数据类型、计算类型等信息, 写入在网计算响应报文并经交换机向NMRR进程发送. 当NMRR进程收到响应报文后, 对报文信息进行保存, 并根据响应报文信息确定是否可以进行在网计算. 若节点所连交换机不具有计算能力, 则转入传统MPI通信模式; 若交换机具有计算能力, 则MRR及NMRR进行其各自节点内进程的广播, 将获取的在网计算参数通过广播方式发送给同节点下其他SR进程. 本文中广播阶段通信采用OpenMPI的二叉树广播方式实现. 此时, notify阶段完成;

上述所有阶段完成后, 控制面流程结束, 可编程交换机路由表建立完毕, 聚合计算逻辑树生成, 为后续数据面流程开展建立了通信基础. 此时, 可转入数据面流程进行在网计算数据报文的发送与计算工作.

需要注意的是, 控制面还需在数据面计算流程全部结束后, 对交换机上路由表及申请的资源进行释放. 该资源释放操作由MRR进程经由交换机向NMRR进程发送释放资源的kill报文, 报文在传输到交换机处时, 交换机解析报文识别到kill信息后, 自动对其资源进行释放.

3.4 数据面设计

在网计算数据面流程主要进行实际业务数据发送及相关计算工作. 当控制面完成后, 可正式通过数据面发送数据, 数据将在可编程交换机处进行聚合计算, 计算结果再发送至主机节点.

对图7中在网计算数据面流程进行详细介绍.

(0) 在节点间发送数据报文之前, 每个主机节点的SRR进程会先进行一次Reduce操作, 对同一个主机节点下其他进程的数据进行聚合计算;

图 7 在网计算数据面流程

(1) 主机节点间经由交换机发送数据报文, 同一TOR下的SRR进程, 按照Rank号从小到大的顺序首尾相连闭环发送数据报文, 报文发送过程中会经过TOR, 主机节点间无直接通信;

(2) TOR缓存报文, 并进行Allreduce计算操作;

(3) TOR判断与其直连节点的同一轮报文收集并计算完成后, 向SPINE节点发送初步计算完的数据报文;

(4) SPINE缓存报文, 进行Allreduce计算操作, 判断与其直连TOR的同一轮报文收集并计算完成后, 发送最终的计算结果给TOR;

(5) TOR将收到的最终计算结果, 填入缓存的原始报文中, 发送给主机节点SRR进程. 最后SRR进程将结果广播至位于同一主机节点下其它进程, 此时一轮Allreduce完成.

3.5 Socket模式设计

上述描述为Node模式下控制面和数据面, 为进一步提升通信性能, 本文提出在网计算Socket模式, 但其使用的通信环境需满足以下约束条件:

(1) 参与在网计算的每个主机节点有两个及以上物理CPU, 且每个主机节点的CPU数目相同;

(2) 每个CPU下运行相同数目的进程且进程Rank连续, 每个主机节点下多个CPU运行的进程Rank连续;

(3) 不同主机节点下进程的Rank连续;

(4) 同一TOR下不同主机节点进程的Rank连续.

Socket模式下控制面和数据面通信与Node模式有所不同, Socket模式下将SRR进程按照节点下CPU的顺序分成多个组, 按组进行控制面和数据面的通信.

下面将通过Socket模式实现流程对上述分组的通信方法进行详细介绍. 设一个主机节点下的CPU数目为N, 主机节点的总数量为S, 每个CPU下运行P个进程. 则MRR的大小为 $MR{R_{\rm size}} = N$ , NMRR的大小为 ${\textit{NMRR}}_{\rm size} = S \times N - N$ . 其中MRR和NMRR按照Rank从小到大排序 (此处MRR和NMRR为进程集合), 则MRR和NMRR可以如下表示:

$ MRR = \{ i \times P|i \in \{ 0, 1,\cdots, N - 1\} \} $

(1)

$ {\textit{NMRR}} = \{ i \times P|i \in \{ N, N + 1,\cdots, S \times N - 1\} \} $

(2)

其中, $ i \times P $ 表示各进程Rank号.

Socket模式下控制面query阶段和notify阶段MRR进程和NMRR进程报文交互分别按照下述对应关系进行:

$ {\textit{NMRR}}_i \to MR{R_j}\left\{ \begin{gathered} j = (i - 1){\text{%}} N + 1 \\ i \in \{ 1, 2, \cdots, S \times N - N\} \\ \end{gathered} \right\} $

(3)

$ MR{R_i} \to {\textit{NMRR}}_j\left\{ \begin{gathered} j = k \times N + i \\ k \in \{ 0, 1,\cdots, S - 2\} , i \in \{ 1, 2,\cdots, N\} \\ \end{gathered} \right\} $

(4)

query阶段时, NMRR中进程按照式(3)中对应关系发送请求报文给MRR中进程, 式中NMRR的第i个进程和MRR中第j个进程均属于第j组, NMRR进程将请求报文发送给同组的MRR进程. 由于Socket模式中 $ N \geqslant 2 $ , 即存在多个MRR进程, 因而MRR进程间还需将保存的通信信息进行同步后再进行notify阶段. notify阶段, MRR进程按照式(4)中对应关系发送响应报文给NMRR进程, 式中MRR中第i个进程及NMRR的第j个进程属于第i组, MRR进程发送响应报文给同一组内的所有NMRR进程.

Socket模式下进行数据面交互时, 通信方式与Node模式类似, 差别在于Socket模式同一TOR下呈多个组闭环发送形式. 设同一TOR下服务器数量为 $ S' $ , 同一TOR下的SRR进程集合为 ${\textit{SRR}}'$ , ${\textit{SRR}}{'_{\rm size}} = S' \times N$ , 其中 $ SRR' $ 按照进程Rank从小到大排序. 数据面的报文发送按照式(5)、式(6)进行.

$ {\textit{SRR}}_i' \to {\textit{SRR}}_j'\left\{ \begin{gathered} j = i + N \\ i \in \{ 1, 2, 3,\cdots, (S' - 1) \times N\} \\ \end{gathered} \right\} $

(5)

$ {\textit{SRR}}_i' \to {\textit{SRR}}_j'\left\{ \begin{gathered} j = (i - 1){\text{%}} N + 1 \\ i \in \{ (S' - 1) \times N + 1, \cdots, S' \times N\} \\ \end{gathered} \right\} $

(6)

数据面交互时, 首先 ${\textit{SRR}}'$ 进程聚合同一CPU下其他进程的数据, 然后 ${\textit{SRR}}'$ 中进程按照式(5)、式(6)发送数据报文, 式中 ${\textit{SRR}}'$ 进程的第i个进程与第j个进程属于同一组, 进程按照同组内闭环的形式发送数据报文. 当数据报经过交换机时, 交换机对数据进行计算, 并将最终计算结果再发给 ${\textit{SRR}}'$ 中进程, 然后 ${\textit{SRR}}'$ 进程将计算结果广播给同一CPU下的其他进程.

图8以二层交换机Socket模式为例, 对上述流程中各参数进行介绍. 其中N=2, S=9, P=4, MRR={0, 4}, NMRR={8, 12, 16, 20, 24, 28, 32, 36, 40, 44, 48, 52, 56, 60, 64, 68}, ${\textit{SRR}} = MRR \cup {\textit{NMRR}}$ , SR为图8所有72个进程中除SRR以外的其他进程. 以第一个TOR为例, $ S' = 3 $ , 集合 ${\textit{SRR}}' = \{ 0, 4, 8, 12, 16, 20\}$ , 其他TOR下的情况以此类推. 根据图8解释Socket模式的通信流程, 在控制面中NMRR进程分为{8, 16, 24, 32, 40, 48, 56, 64}和{12, 20, 28, 36, 44, 52, 60, 68}两组, MRR进程分为{0}和{4}两组, 第1组NMRR与MRR进程0交互, 第2组NMRR与MRR进程4交互. 数据面中第一个TOR下SRR进程分为{0, 8, 16}和{4, 12, 20}两组分别呈闭环发送数据.

图 8 在网计算Socket模式

4 实验及结果分析

为验证在网计算优化效果, 本文主要针对在网计算MPI集合通信进行基准测试和相应的应用级测试. 主要测试在不同主机节点数量、不同消息大小、以及主机节点运行不同进程数目情况下的时延, 并与非在网计算实验的结果进行比较, 进而分析性能提升效果.

4.1 实验环境

本文实验于中科大超级计算中心的瀚海20系统上进行, 实验主要采用国产ARM CPU计算节点, 节点的型号是华为Taishan 2280V2, 节点的主要参数为2×海思Hi1620 CPU (48核, 2.6 GHz), 256 GB DDR4 2 666 MHz内存, 300 GB SAS硬盘, ARM节点之间通过25 Gb/s的以太网互联. 交换机型号为华为CE8850-64CQ-EI, 提供高密度100GE/40GE/25GE/10GE端口, 软件平台基于VRP8操作系统. FPGA型号为Intel A10系列, 实验采用的MPI版本为OpenMPI-4.0.5.

4.2 集合通信基准测试

本文基准测试实验使用OSU-Micro-Benchmarks基准套件进行Allreduce的基准测试. 表4–表6分别为在迭代10 000次情况时, 测试在4个主机节点、9个主机节点以及16个主机节点不同进程数(PPN)、不同消息大小的集合通信基准测试实验结果. 实验对比了在网计算模式(包括Node模式和Socket模式)及非在网计算模式下osu_allreduce的平均延迟情况. 其中消息大小(数据面数据报文大小)最大为256 字节, 时延以微秒(μs)为单位.

表 4 4节点下非在网计算和在网计算对比实验

表 5 9节点下非在网计算和在网计算对比实验

表 6 16节点下非在网计算和在网计算对比实验

由表4可以看出在4个主机节点的情况下, 在网计算Node模式相较于非在网计算优化效果不明显, 当PPN为64时Node模式有3%–15%左右的性能提升. 而Socket模式相较于非在网计算有2%–25%左右的性能提升.

由表5可以看出, 随着节点数增加, 在9节点情况下, 在网计算Node模式和Socket模式相较于非在网计算, 时延明显有所降低, 其中Node模式相较于非在网计算大约有10%–20%左右的提升, 而Socket模式相较于非在网计算有20%–30%左右的性能提升, 且随着PPN和消息大小的增加, 提升越大.

由表6可以看出, 16节点情况下, Node模式和Socket模式相较于非在网计算, 提升更为明显. 16节点情况下, Node模式相较于非在网计算, 大约有15%–30%的性能提升, Socket模式相较于非在网计算有25%–35%的性能提升, 同样随着消息大小和PPN的增加, 提升越大.

基准测试实验表明, 本文提出的在RoCE协议下基于在网计算的MPI通信优化方法, 在当主机节点数目大于等于9时, 其优化效果明显, 性能提升显著. 图9是PPN为64时不同节点情况下的实验结果图. 横坐标为消息大小, 纵坐标为时延, 可以直观看出在网计算的效果.

4.3 OpenFOAM应用测试

为了进一步验证本文在网计算方法对MPI通信优化提升效果, 进行了相关应用级性能测试. 本文主要针对中科大超算中用户数占比较高的集合通信应用OpenFOAM进行测试. 本文实验测试采用OpenFOAM自带的流体力学算例Lid Driven Cavity Flow, 采用icoFoam求解器进行求解. 选择该算例是因为, 通过统计分析发现MPI_Allreduce通信时间占比较大, 调用次数相对较多, 且消息大小小于256字节的短消息占比较大, 满足本文实验要求. 表7展示了OpenFOAM性能测试结果, 主要测试在9节点和16节点情况下非在网计算和在网计算模式不同PPN的运行总时间, 时间单位为s. 可以看出, 在9节点情况下, 在网计算大约有1%–4%的性能提升, 在16节点情况下, 在网计算大约有3%–5%的性能提升. 该性能提升为在网计算模式下应用总的运行时间相较于非在网计算模式下的提升.

图 9 PPN=64不同节点情况下实验结果图

表 7 OpenFOAM性能测试实验

5 总结与展望

随着智能化、信息化时代的高速发展, 人工智能等新兴技术的发展促使将计算操作卸载到网络设备成为研究热点之一. 本文提出在RoCE网络协议下在网计算优化MPI通信的设计及其实现, 通过集合通信基准测试及OpenFOAM应用测试, 验证本文在网计算通信优化方法的有效性. 实验表明, 本文在网计算方法的Node模式和Socket模式均有一定通信性能提升.

然而, 在网计算也有其自身局限性. 从实验结果可以发现当节点数量较多时, 在网计算有一定的提升. 但当节点数量较少时, 在网计算优势不明显. 当节点数在9以上时, 在网计算相较于主机上进行计算优势较为明显. 但是由于交换机相对于主机的局限性, 当进行复杂计算、计算数据量很大、网络状况较好时, 将计算卸载到交换机上执行可能无法减少总时间, 因此后续可进一步研究实现交换机的自适应卸载. 目前本文仅基于硬件进行通信优化, 后续可以将基于算法和拓扑的优化和在网计算进行结合, 进一步提升优化效果. 此外, 本文设计的在网计算方法受交换机等硬件设备限制, 目前最大只支持256字节的数据计算, 长报文的通信优化功能需进一步扩展.

本文方法的相关代码已开源于Github ( https://github.com/pplab/openmpi-inc).

致谢

感谢中国科学技术大学超级计算中心与华为技术有限公司南京研究所对本文工作的大力支持.

参考文献

[1]	Walker DW, Dongarra JJ. MPI: A standard message passing interface. Supercomputer, 1995, 12(1): 56-68.
[2]	Thakur R, Rabenseifner R, Gropp W. Optimization of collective communication operations in MPICH. The International Journal of High Performance Computing Applications, 2005, 19(1): 49-66. DOI:10.1177/1094342005051521
[3]	Vadhiyar SS, Fagg GE, Dongarra J. Automatically tuned collective communications. Proceedings of the 2000 ACM/IEEE Conference on Supercomputing. Dallas: IEEE, 2000. 3.
[4]	Parker S, Chunduri S, Harms K, et al. Performance evaluation of MPI on Cray XC40 Xeon Phi systems. Cray User Group Proceedings. Stockholm: CUG, 2018. 1–7.
[5]	Laguna I, Marshall R, Mohror K, et al. A large-scale study of MPI usage in open-source HPC applications. Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis. Denver: ACM, 2019. 31.
[6]	Chunduri S, Parker S, Balaji P, et al. Characterization of MPI usage on a production supercomputer. Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis. Dallas: IEEE, 2018. 386–400.
[7]	梁润秋, 沈瑜, Alhusaini N, 等. 超算中心典型科研应用特征统计与分析. 小型微型计算机系统, 2022, 43(6): 1121-1127.
[8]	Hoefler T, Squyres JM, Rehm W, et al. A case for non-blocking collective operations. Proceedings of 2006 International Symposium on Parallel and Distributed Processing and Applications. Sorrento: Springer, 2006. 155–164.
[9]	NVIDIA. NCCL library. https://github.com/NVIDIA/nccl. (2018-06-18)[2022-02-28].
[10]	Jia XY, Song ST, He W, et al. Highly scalable deep learning training system with mixed-precision: Training ImageNet in four minute. arXiv: 1807.11205, 2018.
[11]	Mikami H, Suganuma H, U-chupala P, et al. ImageNet/ResNet-50 training in 224 seconds. arXiv: 1811.05233, 2018.
[12]	Ying C, Kumar S, Chen DH, et al. Image classification at supercomputer scale. arXiv: 1811.06992. 2018.
[13]	Barnett M, Littlefield R, Payne DG, et al. Global combine on mesh architectures with wormhole routing. Proceedings Seventh International Parallel Processing Symposium. Newport: IEEE, 1993. 156–162.
[14]	Liu VW, Chen CY, Chen RB. Optimal all-to-all personalized exchange in d-nary banyan multistage interconnection networks . Journal of Combinatorial Optimization, 2007, 14(2): 131-142.
[15]	Petrini F, Coll S, Frachtenberg E, et al. Hardware- and software-based collective communication on the Quadrics network. Proceedings of IEEE International Symposium on Network Computing and Applications. Cambridge: IEEE, 2001. 24–35.
[16]	Gara A, Blumrich MA, Chen D, et al. Overview of the Blue Gene/L system architecture. IBM Journal of Research and Development, 2005, 49(2–3): 195-212.
[17]	Arimilli B, Arimilli R, Chung V, et al. The PERCS high-performance interconnect. Proceedings of the 18th IEEE Symposium on High Performance Interconnects. Mountain View: IEEE, 2010. 75–82.
[18]	Mai L, Rupprecht L, Alim A, et al. NetAgg: Using middleboxes for application-specific on-path aggregation in data centres. Proceedings of the 10th ACM International on Conference on Emerging Networking Experiments and Technologies. Sydney: ACM, 2014. 249–262.
[19]	Alverson B, Froese E, Kaplan L, et al. Cray^® XC^TM series network. Cray Inc., White Paper WP-Aries01-1112, 2012.
[20]	Graham RL, Bureddy D, Lui P, et al. Scalable hierarchical aggregation protocol (SHArP): A hardware architecture for efficient data reduction. Proceedings of 2016 1st International Workshop on Communication Optimizations in HPC. Salt Lake City: IEEE, 2016. 1–10.
[21]	Graham RL, Levi L, Burredy D, et al. Scalable hierarchical aggregation and reduction protocol (SHARP)^TM streaming-aggregation hardware design and evaluation. Proceedings of the 35th International Conference on High Performance Computing. Frankfurt: Springer, 2020. 41–59.
[22]	Ramesh B, Suresh KK, Sarkauskas N, et al. Scalable MPI collectives using SHARP: Large scale performance evaluation on the TACC frontera system. Proceedings of 2020 Workshop on Exascale MPI (ExaMPI). Atlanta: IEEE, 2020. 11–20.
[23]	InfiniBand Trade Association. http://www.infinibandta.org. (2017-05-24)[2022-02-28].