第3章 RDMA软件栈

第3章：RDMA软件栈：libibverbs库核心API、rdma-core用户态驱动、内核态与用户态交互、设备打开与上下文创建

好，咱们进入RDMA软件栈的核心部分。这一章我会重点讲libibverbs库、rdma-core用户态驱动，以及内核态和用户态是怎么打交道的。这些东西，说白了就是你写RDMA程序时天天要面对的基础设施。

我记得刚接触RDMA那会儿，最困惑的就是：我调一个ibv_open_device，底层到底发生了什么？为什么需要用户态驱动？内核态又扮演什么角色？今天咱们就把这些掰开揉碎了讲清楚。

3.1 libibverbs库：RDMA编程的入口

libibverbs是RDMA应用编程的基石。它定义了一套标准的API，让你能操作各种RDMA硬件——不管是Mellanox的ConnectX系列，还是其他厂商的适配器。

我个人习惯把libibverbs看作一个「抽象层」。它隐藏了硬件差异，给你统一的接口。你调用的函数，最终会通过rdma-core打到内核，或者直接操作硬件。

3.1.1 核心API概览

libibverbs的核心API可以分为几大类。我列个表，你一看就明白：

类别	关键函数	作用
设备管理	ibv_get_device_list, ibv_open_device	枚举设备、打开设备、获取上下文
资源创建	ibv_create_pd, ibv_create_cq, ibv_create_qp	创建保护域、完成队列、队列对
内存注册	ibv_reg_mr, ibv_dereg_mr	注册内存区域，获取物理地址映射
操作执行	ibv_post_send, ibv_post_recv, ibv_poll_cq	提交发送/接收请求，轮询完成事件
原子操作	ibv_post_send（配合原子WR）	执行CAS、Fetch-and-Add等原子指令

嗯，这里要注意：ibv_post_send是个万能函数。你传给它不同的工作请求（WR），它就能做不同的事——普通发送、RDMA读写、原子操作，全看你怎么构造WR。

3.1.2 一个简单的设备打开示例

咱们直接看代码。这是最基础的设备打开流程：

#include <infiniband/verbs.h>

struct ibv_device **dev_list;
struct ibv_context *ctx;
int num_devices;

// 1. 获取设备列表
dev_list = ibv_get_device_list(&num_devices, NULL);
if (!dev_list) {
    perror("ibv_get_device_list failed");
    return -1;
}

// 2. 选择第一个设备（实际项目中要遍历选择）
struct ibv_device *dev = dev_list[0];
printf("Using device: %s\n", ibv_get_device_name(dev));

// 3. 打开设备，创建上下文
ctx = ibv_open_device(dev);
if (!ctx) {
    perror("ibv_open_device failed");
    ibv_free_device_list(dev_list);
    return -1;
}

// 4. 查询设备属性
struct ibv_device_attr device_attr;
ibv_query_device(ctx, &device_attr);
printf("Max QP: %d\n", device_attr.max_qp);

// 5. 用完释放
ibv_close_device(ctx);
ibv_free_device_list(dev_list);

这段代码我写过不下百遍了。你注意看，ibv_open_device返回的是一个ibv_context指针。这个context，就是你和硬件之间的「会话句柄」。后面创建PD、CQ、QP，全都依赖它。

我的经验： 千万别忘了调用ibv_free_device_list。我见过太多人只记得close device，忘了释放device list，导致内存泄漏。虽然进程退出时系统会回收，但长期运行的服务程序，这种泄漏会要命。

3.2 rdma-core：用户态驱动的秘密

好，现在问题来了：ibv_open_device到底干了什么？它怎么就和硬件通信了？

答案就在rdma-core里。rdma-core是RDMA的用户态驱动框架。它包含两部分：

librdmacm：连接管理辅助库，帮你处理建立连接的那些繁琐事
libibverbs：我们刚说的核心API库，它内部会调用具体的硬件驱动

说白了，rdma-core就是用户态和内核态之间的「桥梁」。但它不是简单的系统调用封装——它用了内核旁路（Kernel Bypass）技术。

3.2.1 用户态驱动的工作方式

传统的网络编程，你发一个数据包，要经过：用户程序 → 系统调用 → 内核协议栈 → 网卡驱动 → 硬件。

RDMA不一样。它走的是：用户程序 → 用户态驱动 → 直接操作硬件。

为什么会这样？因为RDMA硬件（比如Mellanox的HCA）把大部分控制逻辑都做到了硬件里。用户态驱动只需要把命令写到硬件的一小块内存映射区域（MMIO），硬件自己就处理了。

我举个例子你就明白了：

// 用户态驱动内部（简化示意）
// 这不是真实代码，只是为了说明原理
static int mlx5_post_send(struct ibv_qp *qp, struct ibv_send_wr *wr) {
    // 1. 把WR转换成硬件描述符格式
    struct mlx5_wqe *wqe = get_wqe(qp);
    fill_wqe(wqe, wr);
    
    // 2. 写Doorbell寄存器（MMIO操作）
    // 这一步直接写硬件寄存器，没有系统调用
    writel(qp->doorbell_offset, wqe->index);
    
    // 3. 硬件看到Doorbell，自动从内存取WQE执行
    return 0;
}

看到了吗？writel这个操作，直接写的是PCIe BAR空间映射过来的地址。这就是内核旁路的精髓——零系统调用的数据路径。

关键点： RDMA的数据路径（post_send、post_recv、poll_cq）是用户态直接操作硬件的，不需要切换到内核态。但控制路径（创建QP、注册MR）还是需要内核参与，因为要分配内核资源、管理页表。

3.3 内核态与用户态的交互机制

虽然数据路径绕过了内核，但控制路径逃不掉。内核态和用户态怎么交互？主要通过两个机制：

3.3.1 系统调用接口

libibverbs内部封装了若干ioctl或write系统调用。比如创建QP时：

// 用户态调用
struct ibv_qp *qp = ibv_create_qp(pd, &qp_init_attr);

// 内部实现（简化）
// 1. 构造内核请求结构体
struct ib_uverbs_create_qp cmd;
fill_qp_cmd(&cmd, pd->handle, &qp_init_attr);

// 2. 通过ioctl发送给内核
int fd = pd->context->device->fd;  // 设备文件描述符
ioctl(fd, IB_USER_VERBS_CMD_CREATE_QP, &cmd);

// 3. 内核处理，返回结果
// 内核分配QP资源，返回QP句柄

这个fd是哪来的？就是打开/dev/infiniband/uverbs0这类设备文件得到的。每个RDMA设备对应一个字符设备。

3.3.2 内存映射（mmap）

除了系统调用，还有一个关键机制——mmap。用户态驱动通过mmap把硬件的寄存器空间、队列缓冲区映射到用户进程的地址空间。

我遇到过一个问题：有次调试性能，发现post_send延迟突然变高。查了半天，发现是mmap的页面被换出了。因为RDMA内存要求物理连续且常驻，一旦发生缺页中断，那延迟就惨不忍睹。

避坑指南： 我曾经在项目中遇到一个诡异的问题——程序跑着跑着，ibv_post_send返回EAGAIN。排查后发现是用户态驱动mmap的Doorbell页面被内核回收了。解决方案是使用mlockall锁定进程的虚拟地址空间，防止关键页面被换出。

3.4 设备打开与上下文创建的完整流程

现在我们把整个流程串起来。从你调用ibv_open_device到真正能用硬件，经历了这些步骤：

枚举设备：ibv_get_device_list扫描/sys/class/infiniband，列出所有RDMA设备
打开设备文件：ibv_open_device内部调用open("/dev/infiniband/uverbs0", O_RDWR)
查询设备能力：通过ioctl向内核查询设备属性，填充ibv_context结构体
初始化用户态驱动：加载对应的硬件驱动（比如mlx5），mmap必要的硬件寄存器
返回上下文：你拿到一个ibv_context，后面所有操作都基于它

嗯，这里有个细节：ibv_context里有个struct ibv_device *device字段，指向具体的设备。还有个int cmd_fd，就是那个设备文件描述符。用户态驱动通过这些信息，知道该和哪个硬件通信。

3.4.1 上下文结构体内部

咱们看看ibv_context长什么样（简化版）：

struct ibv_context {
    struct ibv_device      *device;    // 所属设备
    struct ibv_context_ops  ops;       // 操作函数表
    int                     cmd_fd;    // 控制通道fd
    int                     async_fd;  // 异步事件fd
    int                     num_comp_vectors; // 完成向量数
    // ... 还有驱动私有数据
};

这个ops字段特别重要。它是一个函数指针表，指向具体的硬件驱动实现。比如：

struct ibv_context_ops {
    struct ibv_pd *(*alloc_pd)(struct ibv_context *context);
    int (*query_device)(struct ibv_context *context, ...);
    // ... 其他操作
};

这就是多态的思想。你调ibv_alloc_pd(ctx)，实际上调用的是ctx->ops->alloc_pd(ctx)。不同的硬件驱动，填不同的函数指针。

我的建议： 调试RDMA程序时，可以打印ctx->device->name和ctx->ops的地址。这能帮你确认当前用的是哪个驱动。我遇到过因为驱动版本不匹配导致QP创建失败的情况，查这个信息帮了大忙。

3.5 总结与思考

这一章我们覆盖了RDMA软件栈的核心脉络。从libibverbs的API，到rdma-core的用户态驱动，再到内核态交互，最后是设备打开的完整流程。

你想想看，整个设计其实很优雅：

控制路径走内核，安全可靠
数据路径走用户态，极致性能
抽象层隔离硬件差异，应用代码不用改

下一章，我们会深入保护域（PD）和内存注册（MR）。这两个概念是RDMA内存管理的基石，也是很多性能问题的根源。到时候我会分享一些实际项目中的调优经验。

好，今天就到这里。记住一句话：理解软件栈，才能用好硬件。别急着写代码，先把这些底层机制吃透。

📚 课程目录