3. Verbs API概览：分类、调用流程与内核交互
好，咱们进入第三章。这一章我打算给你一个全局视角，看看Verbs API到底长什么样、怎么用、以及它跟内核是怎么打交道的。说实话，很多初学者一上来就扎进具体API的细节里，结果越学越懵。我个人习惯是先看地图，再走路。
3.1 Verbs API的分类
Verbs API，说白了就是RDMA编程的“指令集”。它分两大类：
- 控制路径（Control Path）Verbs：负责资源管理，比如创建QP、注册MR。这些操作通常比较重，会陷入内核。
- 数据路径（Data Path）Verbs：负责数据传输，比如发送、接收、轮询完成队列。这些操作追求极致性能，通常绕过内核，直接操作硬件。
我刚开始接触时，总觉得这两类API差不多。后来在项目中调优，才发现区分它们至关重要——控制路径你随便调，数据路径你写错一行代码，性能直接腰斩。
核心分类表
| 类别 | 典型API | 特点 | 性能敏感度 |
|---|---|---|---|
| 控制路径 | ibv_create_qp, ibv_reg_mr, ibv_alloc_pd | 系统调用，涉及内核态 | 低 |
| 数据路径 | ibv_post_send, ibv_post_recv, ibv_poll_cq | 用户态直接操作硬件 | 极高 |
| 事件管理 | ibv_get_async_event, ibv_ack_async_event | 异步通知机制 | 中 |
你想想看，数据路径的API，每次调用都可能触发几十万次IO操作。所以它的设计原则就是“能省则省”——省掉锁、省掉上下文切换、省掉内存拷贝。
3.2 Verbs API的调用流程
一个典型的RDMA通信流程，我把它拆成5步。嗯，这里要注意，顺序不能乱。
- 初始化：获取设备列表，打开设备，创建PD（保护域）。
- 资源分配：注册MR（内存区域），创建CQ（完成队列），创建QP（队列对）。
- 连接建立：将QP从RESET状态迁移到RTS状态，交换QP编号等信息。
- 数据传输：调用ibv_post_send/ibv_post_recv发起操作，通过ibv_poll_cq获取完成通知。
- 资源清理：销毁QP、CQ、MR、PD，关闭设备。
我曾经在一个项目中，因为忘记把QP状态迁移到RTS就直接发数据，结果卡了半天。后来查文档才发现，QP的状态机是严格的——少一步都不行。
我的小技巧：写代码时，把每一步的返回值都检查一遍。尤其是ibv_modify_qp，它失败了你根本不知道原因。我习惯用perror或者直接打印errno。
下面是一个简化的代码骨架，展示了核心调用顺序：
// 1. 初始化
struct ibv_context *ctx = ibv_open_device(ibv_get_device_list(NULL)[0]);
struct ibv_pd *pd = ibv_alloc_pd(ctx);
// 2. 资源分配
struct ibv_mr *mr = ibv_reg_mr(pd, buf, size, IBV_ACCESS_LOCAL_WRITE);
struct ibv_cq *cq = ibv_create_cq(ctx, 128, NULL, NULL, 0);
struct ibv_qp *qp = ibv_create_qp(pd, qp_init_attr);
// 3. 连接建立（状态迁移）
ibv_modify_qp(qp, &attr, IBV_QP_STATE | ...);
// 4. 数据传输
ibv_post_send(qp, &wr, &bad_wr);
ibv_poll_cq(cq, 1, &wc);
// 5. 清理
ibv_destroy_qp(qp);
ibv_destroy_cq(cq);
ibv_dereg_mr(mr);
ibv_dealloc_pd(pd);
ibv_close_device(ctx);这段代码虽然简单，但五脏俱全。你把它跑通了，基本就掌握了Verbs API的骨架。
3.3 Verbs API与内核的交互
这里有个关键问题：Verbs API到底是怎么跟内核打交道的？
其实，控制路径的API，比如ibv_create_qp，会通过系统调用进入内核。内核里的RDMA子系统（比如InfiniBand驱动或iWARP驱动）负责分配硬件资源，然后把句柄返回给用户态。
但数据路径的API，比如ibv_post_send，就不走内核了。它直接通过内存映射（mmap）操作硬件寄存器，把工作请求（WR）写到硬件队列里。这就是RDMA能实现微秒级延迟的根本原因——省掉了内核的参与。
避坑指南：我曾经在调试一个性能问题时，发现ibv_post_send偶尔会返回EAGAIN。后来才明白，这是因为硬件队列满了。解决办法是增加CQ的深度，或者用ibv_poll_cq及时消费完成事件。记住，硬件资源是有限的，别一股脑往里塞。
具体来说，用户态Verbs库（libibverbs）通过以下机制与内核交互：
- ioctl系统调用：用于控制路径操作，比如创建QP、查询设备属性。
- mmap：将硬件寄存器映射到用户态地址空间，数据路径直接读写。
- 共享内存：用于传递完成事件，比如ibv_get_cq_event。
你想想看，这种设计其实很巧妙。控制路径走内核，保证了资源管理的安全性；数据路径绕过内核，保证了性能。说白了，就是“该慢的慢，该快的快”。
最后，我建议你动手写一个简单的ping-pong程序。不需要多复杂，就是两个节点互相发消息。写完之后，你用strace跟踪一下系统调用，看看哪些Verbs调用走了内核，哪些没走。这个实验做完，你对Verbs API的理解会上一个台阶。
好，这一章就到这儿。下一章我们深入ibv_create_qp，看看QP创建时到底发生了什么。