libfabric

定义

libfabric是一个通信库框架,旨在满足高性能计算(HPC)应用对性能与可扩展性的要求,它定义了一组通信接口,使应用与底层网络服务之间能形成紧密的语义映射^[1]。在OFI体系中,libfabric是核心组件,负责定义并导出用户态应用程序接口,通常是应用直接面对的唯一的软件层,它通过与厂商提供者(provider)库配合来完成实际的网络通信^[2]。

这些接口是与网络硬件厂商及应用开发者共同设计出来的,重点考虑HPC用户的需求;libfabric支持多种通信语义,不依赖特定体系架构或硬件实现,并利用和扩展了既有的RDMA开源社区^[3]。其设计目标是减少应用、中间件与通信硬件之间的语义不匹配,接口面向高带宽、低延迟网卡,并期望可扩展到数万个节点的规模^[4]。

原理

libfabric采用分层结构,上层是MPI、SHMEM、PGAS、数据存储等中间件,中间是libfabric对外导出的应用程序接口,下层是各个provider提供的实现^[5]。核心框架负责管理provider的选择与调度,provider则把libfabric的操作翻译成具体网卡的驱动调用,例如verbs provider使用Linux Verbs接口,shm provider在本机节点内通过共享内存通信^[6]。

其对象模型包含fabric、domain、端点(endpoint)、完成队列、事件队列、计数器、内存区域和地址向量等。内存区域用于授予provider访问应用缓冲区的权限,是RMA等操作的先决条件;地址向量把IP这类高层地址映射为fabric内部地址,以减少地址查找开销^[7]。数据传输接口分为消息队列、带标签消息队列、远程内存访问(RMA)和原子操作几类:RMA是单边操作,数据直接读写远端内存区域,完成后无需目标端参与;原子操作可对远端内存执行原子加、比较并交换等运算^[8]。

provider可通过环境变量在运行时选择,例如把FI_PROVIDER设为由逗号分隔的provider列表,即可只启用其中的若干实现;日志则通过FI_LOG_LEVEL、FI_LOG_PROV、FI_LOG_SUBSYS控制^[9]。部分provider依赖应用主动调用fi_cq_read一类函数推进通信进度,也可使用自动进度模式,但后者在某些provider上会明显影响性能^[10]。

发展历程

OFI工作组于2013年8月成立,由英特尔(Intel)的Sean Hefty与Cray公司的Paul Grun共同担任主席,其章程是开发一套可扩展的开源框架与接口,使其与上层协议和应用需求对齐^[11]。这一工作的背景是中间件通常每隔3至5年就要被移植到新的底层网络接口,而硬件专用接口往往需要被支持十年以上^[11]。

2015年5月,OFI工作组发布了libfabric 1.0,并同时发布了配套的示例应用集合fabtests,首批provider包括sockets、verbs、PSM和usNIC^[12]。1.x系列随后持续演进,发行版中以1.10、1.14、1.22等版本号出现,新增了EFA、SHM、rxm、rxd等provider^[2]。

2024年12月,libfabric 2.0.0发布,被视为重要里程碑:该版本精简并调整了应用程序接口,为超以太网联盟(Ultra Ethernet Consortium)做准备,弃用了不再受支持的特性,并新增标准化标签格式与面向人工智能的原子类型等能力,超以太网传输软件即基于libfabric 2.0的接口构建^[4]。此后的2.x版本持续迭代,2.4.0加入了Rust语言绑定,2.5.0引入了新的shm provider架构并更新了psm3 provider^[13][14]。自2025年起,libfabric改为按季度发布,主要版本在3月、6月、9月和12月推出,此前为每年3月、7月和11月各发布一次^[3]。

应用

多个开源HPC中间件都通过libfabric获得通信能力,包括MPICH、Open MPI、Sandia SHMEM、Open SHMEM、Charm++、GASNet、Clang、UPC和DAOS等^[13]。英特尔MPI库已从OpenFabrics Alliance框架转向OFI框架并支持libfabric,可用的provider包括psm3、efa、tcp、shm、psm2、mlx和verbs等^[15]。

在具体实现层面,洛斯阿拉莫斯国家实验室曾与Cray合作开发面向Trinity/TN8系统的GNI provider,用于在Cray XC的Aries网络上支撑Open MPI的线程与异步进度等需求^[16]。存储与数据访问方向也以OFI为基础发展接口,以适应字节可寻址内存等新型存储器件^[17]。libfabric支持的平台包括Linux、FreeBSD、Windows和macOS,但针对具体发行版的验证限于较新的Red Hat Enterprise Linux与SUSE Linux Enterprise Server版本,仅基于TCP与UDP套接字的provider在所有平台上可用^[3]。

provider的功能覆盖并不一致。按官方维护的特性矩阵,部分feature仅得到有限支持,或需要借助utility provider实现;bgq、psm和sockets等provider虽仍被维护,功能已被冻结^[18]。sockets provider本身并不追求相对普通TCP/UDP套接字的性能提升,其定位是让开发者在没有高速网络的平台上编写、测试和调试代码^[19]。

局限

libfabric提供的是低层通信抽象,而不是开箱即用的性能保证,应用的实际表现取决于所选provider与底层硬件。sockets provider明确不以超越普通套接字性能为目标,verbs provider的性能则与原生Linux Verbs接口大体相当,二者更多承担开发与调试用途^[6]。

接口本身规模庞大、可选配置繁多。官方材料在介绍其架构时即指出这是一个选项众多的庞大接口,且处于持续演进之中^[11]。有研究在评测后指出,使用这类库需要较高的专业经验,而文档相对不足,复杂性与可维护性成为不少应用未采用它的现实原因^[10]。

不同provider的能力边界也存在差异。以面向Amazon EC2弹性体系适配器(EFA)的provider为例,相关评测指出EFA不提供单边操作支持,也不保证按序投递,依赖顺序语义的系统需要在软件栈中自行处理重排序,同时其使用范围受限于该云平台的实例^[20]。多个provider同时使用时,对象数量会成倍增加,需要在多个provider之间协调内存注册、接收缓冲与完成事件,这带来了额外的开发成本^[5]。

参见

• MPI —— 最常通过libfabric获得网络通信能力的高性能计算消息传递接口。

• RDMA —— libfabric的RMA与原子操作语义所依赖的远程内存直接访问技术。

• OpenFabrics Alliance —— libfabric所属OFI工作组的上级开源组织。

• InfiniBand —— 由verbs provider等实现所支持的一类高速互连网络。

• 共享内存 —— shm provider在单机节点内部实现进程间通信所依托的机制。

• Ultra Ethernet Consortium —— libfabric 2.0为其传输软件提供接口基础的行业联盟。