问题
FPGA在云部署中越来越普遍[16,81]，如智能NIC[29,35,64,67103]、流处理器[31,32,55,68]和分布式加速器[15,41,61,65,86,93115]。可以使用FPGA到FPGA的直接通信来构建高效的分布式系统。然而，使用FPGA设计分布式应用程序是困难的，它需要FPGA上与数据中心基础设施兼容的网络栈，以及更高层次的抽象，例如集体通信，以实现更复杂的交互模式。集体通信是并行计算和分布式系统中的一种通信模式，涉及多个进程之间的数据交换和同步操作。集体通信操作通常由消息传递接口（MPI）等库提供，允许多个进程进行协同工作，而不需要每个进程独立地进行点对点通信。
最近的方法[10,18,60,70,72100]侧重于虚拟化FPGA资源以抽象数据移动，缺乏对网络的支持。这迫使利用FPGA的分布式应用程序依赖CPU进行通信[22,92116]，从而增加了FPGA之间数据传输的延迟。直到最近，FPGA才有了本机网络支持[14,45,56,87,95]。但这些系统缺乏集体通信，限制了它们在更大的分布式用例中的适用性。
挑战
为FPGA实现高性能和多功能的集体抽象面临几个挑战：
-
支持多种传输协议。这源于对特定应用解决方案的需求，并确保FPGA、CPU和加速器共存的混合环境中的互操作性。适应各种通信协议对于将基于FPGA的组件与系统的其他部分无缝集成至关重要。现有的工作[25,26,36,44,73,84,85,101,104,112]通常是针对FPGA直接相互连接而不通过数据中心分组交换网络连接的场景。在这些方法中，通信是通过低级链路层协议进行的，这导致了数据中心规模的可扩展性和集成挑战。
-
集体实施的灵活性。一个关键的挑战是在硬件中提供灵活的设计，允许在运行时选择不同的集合和算法。当前的解决方案[26,45]通常将所有可能的集合模块直接集成到FPGA硬件中，导致对静态原语的更高需要数小时的重新编译。替代方法，例如在FPGA上使用嵌入式微控制器（uC）[89]的集体，以牺牲性能为代价提供了更大的灵活性。
-
跨应用程序和平台的可移植性。可移植性是一个关键挑战，因为FPGA用于各种配置。图1a显示了FPGA集体通信库（CCL）作为FPGA加速器之间直联网络，还演示了以FPGA为中心的应用程序的分区内存模型[54,59,60]，如果数据来自CPU内存（虚线），则需要显式内存副本。图1b说明了CCL作为具有共享虚拟内存的CPU应用程序的集体卸载引擎[62,70,75106]。这引发了应该向应用程序提供哪些通信模型的问题。接口应该支持消息传递，即MPI，在内存缓冲区之间进行通信；还是流式传输，在流式传输中通过连续的数据流进行通信。
本文方法
本文提出了FPGA上的自适应集体通信库ACCL+。
-
可跨不同平台，支持UDP、TCP以及RDMA，使FPGA应用程序能够启动FPGA到FPGA的直接集体通信。可以作为CPU应用程序的集体卸载引擎，将CPU从网络任务中解放。
-
提供了具有显式缓冲区分配的类MPI集体API和具有直接通道到通信层的流式集体API。
-
为了实现可移植性，采用了模块化的系统架构，将特定于平台的IO管理和运行时与集体实现解耦，并结合了特定于平台和网络协议的适配器和驱动程序。
-
为了灵活性，开发了独立于平台和协议的集体卸载引擎，支持在不重新编译硬件的情况下修改集体实现。
在具有100 Gb/s网络的FPGA集群上评估了ACCL+，并将其性能与RDMA上的软件MPI进行了比较。结果表明，ACCL+在基于FPGA的分布式应用中具有显著优势，在CPU应用中具有竞争力。
通过两个用例展示了ACCL+的双重作用：作为分布式基于CPU的向量矩阵乘法的集体卸载引擎，以及作为设计完全基于FPGA的分布式深度学习推荐推理的组件。
总结
针对基于FPGA的通信库，现有方法不能支持多种传输协议、灵活性不足、可移植性不足。本文提出FPGA上的自适应集体通信库ACCL+。包括四个技术：（1）可跨不同平台，支持UDP、TCP以及RDMA，使FPGA应用程序能够启动FPGA到FPGA的直接集体通信。可以作为CPU应用程序的集体卸载引擎，将CPU从网络任务中解放。（2）提供了具有显式缓冲区分配的类MPI集体API和具有直接通道到通信层的流式集体API。（3）为了可移植性，采用了模块化的系统架构，将特定于平台的IO管理和运行时与集体实现解耦，并结合了特定于平台和网络协议的适配器和驱动程序。（4）为了灵活性，开发了独立于平台和协议的集体卸载引擎，支持在不重新编译硬件的情况下修改集体实现。