在高性能计算、分布式存储、AI 训练集群等领域,RDMA(Remote Direct Memory Access,远程直接内存访问)已经成为不可或缺的核心技术。本文将从 RDMA 的基本原理、数据通路模型、协议类型、网络构成等多个维度,带你深入理解这项技术。
一、RDMA 的控制通路与数据通路
1.1 核心设计思想
RDMA 的核心设计理念是将操作分为两类通路:
| 通路类型 | 操作特点 | 处理位置 | 典型操作 |
|---|---|---|---|
| 控制通路 | 低频、耗时、需要高权限 | 需要进入内核态 | 创建 MR、QP、CQ 等资源 |
| 数据通路 | 高频、快速、权限要求低 | 完全在用户态 | 数据收发操作 |
设计哲学:
控制类操作属于低频且耗时的操作类型;而数据收发相关的操作所需的权限较低,直接在用户态处理即可。只有这样才能起到旁路内核 和快速收发数据的效果。在程序运行的大部分时间里,执行的都是高频的数据操作。
1.2 RDMA 通信流程
以 Send 和 Receive 操作为例,一次完整的 RDMA 通信过程如下:
步骤1(控制通路):
发送端和接收端的软件都通过控制通路进入内核态,
创建通信所需的各种资源,包括 MR、QP、CQ 等。
步骤2(数据通路-接收端):
接收端的应用程序通知硬件准备接收数据,
并将存放数据的缓存地址告知硬件。
步骤3(数据通路-发送端):
发送端的应用程序通知硬件发送数据,
并将待发送数据所在的缓存地址和数据长度告知硬件。
步骤4(硬件处理):
发送端硬件使用 DMA 操作从主机内存的缓存中将数据
复制到自己的硬件内部缓存,然后按照协议封装数据包并发送给对端。
步骤5(硬件处理):
接收端硬件收到数据包,按照协议对其进行解析,
并通过 DMA 操作将有效的应用数据写入主机内存。
步骤6(数据通路-接收端):
接收端的应用程序获知收到的数据已被放入本地缓存。
1.3 数据流分析
使用 RDMA 方案时,用户数据在两个应用程序之间传递的过程共进行了 3 次数据复制:
发送端主机内存(用户空间缓存)
↓ ① DMA 操作
发送端网卡硬件缓存(封装:添加协议报头和校验信息)
↓ ② 网线/光纤传输
接收端网卡硬件缓存
↓ ③ DMA 操作(解析:剥离协议报头和校验信息)
接收端主机内存(用户空间缓存)
1.4 RDMA 的三大优势
与传统内核协议栈方案相比,RDMA 方案具有三个核心优势:
| 优势 | 说明 | 效果 |
|---|---|---|
| 本地内存零复制 | 省去了数据在主机内存的用户空间和内核空间之间复制的步骤 | 降低整个数据收发过程的时延 |
| 内核旁路 | 数据通路绕过内核,避免了系统调用和上下文切换的时间开销 | 减少 CPU 负载 |
| 硬件封装 / 解析 | 把数据包的封装和解析工作交由网卡来实现 | 降低 CPU 负载 |
1.5 以太网方案 vs RDMA 方案对比
从数据通路的角度比较两者:
┌─────────────────────────────────────────────────────────────┐
│ 内核协议栈方案 │
├─────────────────────────────────────────────────────────────┤
│ 用户态:APP1 → 使用套接字 API 收发数据 │
│ 内核态:Send/Recv → TCP/IP 协议栈 → 以太网卡驱动 │
│ 硬件:硬件以太网模块 │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ RDMA 方案 │
├─────────────────────────────────────────────────────────────┤
│ 用户态:APP2 → 使用 Verbs API 收发数据 │
│ → 填写 WQEs → Pull CQ → 轮询 CQE │
│ 内核态:(数据通路不经过) │
│ 硬件:硬件 RDMA 模块 │
└─────────────────────────────────────────────────────────────┘
关键结论: RDMA 方案的数据通路已经进行了充分的简化,几乎 "卸掉了所有的包袱"。
二、RDMA 对网卡的新要求
相对于以太网方案,RDMA 方案对网卡提出了两点新要求:
2.1 能够解析页表
背景: 应用程序申请的数据缓存一般都是虚拟地址连续而物理地址不连续的。
要求: 硬件必须有解析页表的能力,能够访问物理地址不连续的缓存。
重要说明: 此处所说的页表是软件专门为 RDMA 网卡建立的,不是 MMU 访问的页表。
2.2 能够封装和解析数据包
要求: 网卡需要按照协议:
- 在发送数据前加上协议报头与校验和
- 在接收数据后将其剥离
三、RDMA 的性能优势:数据流水线模型
3.1 以太网卡的数据流水线
假设前提:
- 应用程序从时刻 0 开始产生数据
- 之后每 1ns 持续产生 1 个数据(100 位)
- 每个操作步骤都花费 1ns
以太网卡的数据流水线模型:
新数据产生 | 1ns | 2ns | 3ns | 4ns | 5ns | 6ns | 7ns | 8ns | 9ns | 10ns
------------|-----|-----|-----|-----|-----|-----|-----|-----|-----|-----
数据0 | ① | ② | ③ | ④ | | | | | |
数据1 | | ① | ② | ③ | ④ | | | | |
数据2 | | | ① | ② | ③ | ④ | | | |
数据3 | | | | ① | ② | ③ | ④ | | |
数据4 | | | | | ① | ② | ③ | ④ | |
数据5 | | | | | | ① | ② | ③ | ④ |
数据6 | | | | | | | ① | ② | ③ | ④
操作步骤说明:
| 步骤 | 操作内容 |
|---|---|
| ① | 应用程序申请用户空间缓存并写入数据 |
| ② | 内核协议栈申请内核空间缓存,并将数据从用户空间缓存复制到内核空间缓存 |
| ③ | 驱动程序操作网卡把数据从内核空间缓存通过 DMA 复制到网卡内部缓存 |
| ④ | 网卡把数据发送到对端网卡 |
性能指标:
- 每个数据需要 4ns 发送到对端网卡
- 对端网卡当前接收到的是 4ns 之前产生的数据
3.2 RDMA 网卡的数据流水线
RDMA 网卡的数据流水线模型:
新数据产生 | 1ns | 2ns | 3ns | 4ns | 5ns | 6ns | 7ns | 8ns | 9ns | 10ns
------------|-----|-----|-----|-----|-----|-----|-----|-----|-----|-----
数据0 | | ① | ② | ③ | | | | | |
数据1 | | | ① | ② | ③ | | | | |
数据2 | | | | ① | ② | ③ | | | |
数据3 | | | | | ① | ② | ③ | | |
数据4 | | | | | | ① | ② | ③ | |
数据5 | | | | | | | ① | ② | ③ |
数据6 | | | | | | | | ① | ② | ③
操作步骤说明:
| 步骤 | 操作内容 |
|---|---|
| ① | 应用程序向用户空间缓存写入数据 |
| ② | 驱动程序操作网卡把数据从用户空间缓存通过 DMA 复制到网卡内部缓存 |
| ③ | 网卡把数据发送到对端网卡 |
性能指标:
- 每个数据只需要 3ns 就可以到达对端网卡
- 相比以太网方案,时延降低 25%
3.3 达到最大带宽的条件
理论上,只要满足以下三个条件就可以实现 100Gbit/s 的发送速率:
| 条件 | 说明 |
|---|---|
| 条件一 | 每一步的操作时长都小于 1ns(实际应该是 0.93ns),即每一步都足够快 |
| 条件二 | 每隔 1ns 就有新的数据产生,即有源源不断的数据 |
| 条件三 | 从第一个数据处理的最后一步之后开始计算带宽,即合适的计算时机 |
关键结论:
RDMA 方案以更少的步骤就能实现更低的时延。通信领域出现率最高的性能指标就是带宽和时延。简单来说,所谓带宽是指单位时间内能够传输的数据量(比如 100Gbit/s),而时延指的是数据从本端发出到被对端接收所消耗的时间。
四、RDMA 协议类型
RDMA 主要有三种协议实现:
4.1 InfiniBand
基本介绍:
| 属性 | 说明 |
|---|---|
| 名称 | InfiniBand(直译为 "无限带宽",缩写为 IB) |
| 定位 | 用于高性能计算的计算机网络通信标准 |
| 特点 | 具有极高的吞吐量和极低的时延 |
| 提出时间 | 2000 年由 IBTA(InfiniBand Trade Association)提出 |
协议分层模型:
┌─────────────────────────────────────────────────────────────────────────┐
│ 应用层 │
│ 终端节点:主机客户端/IB架构操作 ←────────→ 远程客户端/IB架构操作 │
├─────────────────────────────────────────────────────────────────────────┤
│ 传输层 │
│ 终端节点:事务、消息(QP) ←────────→ 终端节点:事务、消息(QP) │
├─────────────────────────────────────────────────────────────────────────┤
│ 网络层 │
│ 终端节点:子网间路由(IPv6) ←─交换机─→ 子网内路由(LID) │
│ 子网内路由(LID) ←─路由器─→ 数据包转发 │
├─────────────────────────────────────────────────────────────────────────┤
│ 链路层 │
│ 终端节点:网络处理、链路编码 ←─交换机─→ 流控、链路、MAC │
│ MAC ←─路由器─→ 链路、MAC │
├─────────────────────────────────────────────────────────────────────────┤
│ 物理层 │
└─────────────────────────────────────────────────────────────────────────┘
核心特点:
- IBTA 是 RDMA 技术最主要的倡导者和先行者
- 规定了一整套完整的链路层到传输层规范
- 无法兼容现有以太网
- 如果企业想部署,除了需要专用网卡之外,还要重新购买配套的网络交换设备
4.2 RoCE
基本介绍:
| 属性 | 说明 |
|---|---|
| 全称 | RDMA over Converged Ethernet(基于融合以太网的 RDMA) |
| 定义方 | IBTA |
| 定位 | InfiniBand 的 "低成本解决方案" |
| 核心 | 将 InfiniBand 传输层的报文封装成以太网数据包进行收发 |
版本对比:
| 版本 | 网络层 | 链路层 | 是否可路由 | 适用场景 |
|---|---|---|---|---|
| RoCE v1 | InfiniBand 规范 | 以太网协议 | ❌ 不可路由 | 同一以太网广播域 |
| RoCE v2 | UDP + IP | 以太网协议 | ✅ 可路由 | 可跨子网通信 |
RoCE 与 InfiniBand 的技术差异:
| 差异点 | InfiniBand | RoCE |
|---|---|---|
| 链路级流量控制 | 基于信用的算法保证无损通信 | 需要无损以太网网络(PFC 配置) |
| 阻塞控制 | 基于 FECN/BECN 标记 | 使用 ECN 标记、CNP 帧反馈 |
| 交换机时延 | 通常更低 | 相对较高 |
| 部署成本 | 需要专用设备 | 可使用以太网交换设备 |
RoCE 网络的注意事项:
1. 网络中不需要子网管理器
- 需要与子网管理器通信的操作,在 RoCE 网络中以不同方式管理
2. LID 对 RoCE 无意义
- 在查询 RoCE 网卡的端口时,LID 显示为零
- 因为 LID 是 InfiniBand 协议栈链路层的属性
3. 无法查询路径
- 因为子网管理器不存在
- 建立连接前,必须将相关值填充进路径记录结构
- 建议使用 RDMA CM 建立连接
4. 流量统计位置不同
- RoCE 设备的流量不显示在以太网设备的计数器中
- 统计位置:/sys/class/infiniband/<device>/ports/<port>/counters/
实际设备示例:
以 Mellanox ConnectX-5 100G 网卡为例:
$ ibv_devinfo
hca_id: mlx5_0
transport: InfiniBand (0) # 传输层为 InfiniBand
fw_ver: 16.32.1010
node_guid: b859:9f03:00b0:cc70
sys_image_guid: b859:9f03:00b0:cc70
vendor_id: 0x02c9
vendor_part_id: 4119
hw_ver: 0x0
board_id: MT_0000000011
phys_port_cnt: 1
port: 1
state: PORT_ACTIVE (4)
max_mtu: 4096 (5)
active_mtu: 1024 (3)
sm_lid: 0
port_lid: 0 # LID 为 0(对 RoCE 无意义)
port_lmc: 0x00
link_layer: Ethernet # 链路层为以太网
从输出可以看出:
transport: InfiniBand→ 传输层为 InfiniBand 传输层link_layer: Ethernet→ 支持以太网链路层port_lid: 0→ LID 为 0(对 RoCE 无意义)
查询 RoCE 版本:
$ sudo cma_roce_mode -d mlx5_0 -p 1
RoCE v2
4.3 iWARP
基本介绍:
| 属性 | 说明 |
|---|---|
| 全称 | Internet Wide Area RDMA Protocol |
| 定义方 | IETF |
| 基础 | 基于 TCP 的 RDMA |
| 特点 | 可以路由(与 RoCE v2 相同) |
与 RoCE/InfiniBand 对比:
| 对比项 | iWARP | RoCE v2 / InfiniBand |
|---|---|---|
| 可靠性 | 面向连接的 TCP,有损网络场景下可靠性更好 | 相对较差 |
| 大规模组网 | 有明显优势 | 可扩展性问题 |
| 内存消耗 | 大量连接时内存需求高 | 相对较低 |
| 时延 | 较高 | 较低 |
| 吞吐量 | 较低 | 较高 |
| CPU 开销 | 较高 | 较低 |
| 多播支持 | 当前规范未定义 | 支持 |
关键结论:
RoCE 在时延、吞吐量和 CPU 开销方面明显优于 iWARP。
4.4 三种协议总结
| 协议 | 网络层 | 可路由 | 成本 | 性能 | 适用场景 |
|---|---|---|---|---|---|
| InfiniBand | 原生 | ✅ | 高 | 最高 | 高性能计算、超算中心 |
| RoCE v2 | UDP + IP | ✅ | 中 | 高 | 数据中心、分布式存储 |
| iWARP | TCP | ✅ | 低 | 中 | 广域网、有损网络 |
注意: 虽然存在软件实现的 RoCE 和 iWARP,但真正商用时上述几种协议都需要专门的硬件(网卡)支持。
五、RDMA 网络构成
InfiniBand 体系结构定义了组网通信所需的多种设备:
5.1 网络拓扑示例
┌─────────────────────────────────────────────────────────────────────┐
│ 子网 A │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 主机 HCA │─────│ 交换机 │─────│ 主机 HCA │ │
│ └──────────┘ └────┬─────┘ └──────────┘ │
│ │ │
│ ┌────┴─────┐ │
│ │ 交换机 │ │
│ └────┬─────┘ │
│ │ │
│ ┌──────────┐ ┌────┴─────┐ ┌──────────┐ │
│ │I/O设备TCA│─────│ 主机 HCA │─────│ 主机 HCA │ │
│ └──────────┘ └──────────┘ └──────────┘ │
└─────────────────────────────────────────────────────────────────────┘
│
┌─────┴─────┐
│ 路由器 │
└─────┬─────┘
│
┌─────────────────────────────────────────────────────────────────────┐
│ 子网 B │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 主机 HCA │─────│ 交换机 │─────│ 主机 HCA │ │
│ └──────────┘ └────┬─────┘ └──────────┘ │
│ │ │
│ ┌──────────┐ │ ┌──────────┐ │
│ │I/O设备TCA│──────────┴──────────│ 主机 HCA │ │
│ └──────────┘ └──────────┘ │
└─────────────────────────────────────────────────────────────────────┘
5.2 核心组件详解
主机通道适配器
| 属性 | 说明 |
|---|---|
| 全称 | Host Channel Adapter |
| 定义 | 安装在主机上的 RDMA 网卡 |
| 功能 | 将一个主机设备连接到一个 RDMA 网络上 |
关键特性:
多端口支持:
- 一个 HCA 可以有多个物理端口
- 每个端口有自己的 LID 或 LID 范围
- 每个端口有独立的发送和接收缓存
- 所有端口可以并行发送和接收
地址分配:
- 子网管理器为每个物理端口配置子网内的本地地址(LID)
- 子网管理代理和子网管理器通信,共同实现子网管理功能
永久标识符:
- 厂商为每个 HCA 分配独一无二的 GUID
- LID 不是永久的(断电重启后可能会变)
- GUID 是永久识别某一个 HCA 的主要标识符
- 每个端口还有一个端口 GUID
软件接口:
- HCA 支持 InfiniBand 定义的所有软件 Verbs
- Verbs 定义了客户端软件和 HCA 功能之间所需的接口
- Verbs 不直接指定操作系统的接口,而是定义了一系列操作
- 操作系统供应商根据 Verbs 开发相应的 API
目标通道适配器
| 属性 | 说明 |
|---|---|
| 全称 | Target Channel Adapter |
| 功能 | 为 I/O 设备(比如硬盘控制器)提供其到 RDMA 网络的连接 |
| 支持 | 每个设备的特定操作所需的 HCA 功能子集 |
子网管理器
| 属性 | 说明 |
|---|---|
| 定位 | 虚拟设备,可以在其他任何一台设备上实现 |
| 功能 | 为连接到 InfiniBand 网络的每个端口分配 LID |
| 路由 | 基于分配的 LID 建立路由表 |
核心特点:
软件定义网络(SDN)概念:
- 消除了互连的复杂性
- 支持创建非常大规模的计算和存储基础设施
配置职责:
- 配置本地子网并确保其持续运行
- 管理所有交换机和路由器的配置
- 链路断开或出现新链路时重新配置子网
高可用设计:
- 一个子网中可以有多个子网管理器
- 但只能有一个处于活动状态
- 备用子网管理器同步保存活动状态子网管理器的信息
- 活动状态子网管理器停机时,备用自动接管
重要说明:
在 RoCE 类型的网络中,不存在子网管理器。
交换机
| 属性 | 说明 |
|---|---|
| 定位 | 类似于标准以太网交换机 |
| 功能 | 根据第二层本地路由报头中的 LID 转发数据包 |
| 特点 | 只管理和转发数据包,不消耗或产生数据包 |
核心特性:
流量控制:
- 实现 InfiniBand 链路层的流量控制
- 防止丢包
- 有避免阻塞和自适应路由的功能
- 支持高级服务质量
子网管理代理:
- 与通道适配器一样,交换机必须包含 SMA 功能
- 用于处理子网管理报文
多播支持:
- 可配置为转发单播数据包(到单个设备)
- 或多播数据包(到多个设备)
附加功能:
- 许多交换机包含了子网管理器的功能
重要说明:
RoCE 类型的网络中使用的是以太网交换机。
路由器
| 属性 | 说明 |
|---|---|
| 功能 | 将数据包从一个子网转发到另一个子网 |
| 特点 | 不消耗或产生数据包 |
工作机制:
路由方式:
- 根据全局路由报头(GRH)中包含的 IPv6 网络层来转发数据包
- 将数据包发送到下一个子网时,按照目标子网中合适的 LID
修改数据包中的本地路由报头(LRH)
对终端的透明性:
- 路由对终端来说不是透明的
- 终端发包时必须指定路由器的 LID 和最终目标 GID
子网前缀:
- 每一个子网都有独一无二的子网 ID(子网前缀)
- 子网前缀配给子网中所有的端口
- 子网前缀和端口的 GUID 结合,就成了端口的 GID
重要说明:
RoCE 类型的网络中使用的是以太网路由器。
六、总结
6.1 RDMA 核心价值
| 维度 | 传统以太网 | RDMA |
|---|---|---|
| 数据复制 | 4 次(用户↔内核↔网卡) | 1 次(用户↔网卡) |
| CPU 参与 | 每包中断、拷贝 | 数据通路零参与 |
| 时延 | 微秒级 | 亚微秒级 |
| 吞吐 | 受限于 CPU | 接近线速 |
6.2 协议选型建议
| 场景 | 推荐协议 | 理由 |
|---|---|---|
| 高性能计算 | InfiniBand | 最高性能,专用网络 |
| 数据中心 | RoCE v2 | 性能与成本平衡 |
| 广域网 | iWARP | 有损网络下更可靠 |
6.3 部署要点
1. RoCE 网络需要无损以太网支持(PFC 配置)
2. LID 在 RoCE 网络中无意义,查询显示为 0
3. RoCE 无子网管理器,建议使用 RDMA CM 建立连接
4. 流量统计在 /sys/class/infiniband/ 目录下