企业官网建设流程全解析

最近在调一个多机 GPU 集合通信的项目，好几张卡的显存数据要互相搬。一开始走传统 TCP socket，发现 CPU 占用高得吓人，带宽也到不了 InfiniBand 的标称值，后来花了两个晚上把 RDMA 这条路彻底打通，又顺手把 GPUDirect RDMA 接上，效果完全是两个世界。这篇文章就把我踩过的坑和梳理出来的核心概念一次性讲清楚——QP、WQE、CQ、MR、Zero-Copy，还有那个让人又爱又恨的 QP 状态机。

为什么题目里会有“任意门”？因为 RDMA 做的事情，本质上就是在应用程序的内存和网卡之间开一条旁路，让数据不经过 CPU 复制直接跨机传输，像极了游戏里点对点的传送门。再加上最近 VR/MR 开发特别火，比如 pico4 里做 VR 到 MR 的切换，背后依赖的是“渲染管线状态切换”和“内存布局管理”的思维，RDMA 里的 QP 状态机和 MR（Memory Region）机制，其实也有相似的“切换”逻辑。这个类比不是硬凑，后面讲到状态机转移的时候，你会更明显感觉到：任何一套高性能系统，核心都在于什么时候允许状态切换、切换时谁负责任务交接，以及失败后怎么回滚。

这篇文章适合三类人看：刚接触 RDMA 想快速建立整体认知的初学者，已经在用但是被 QP 状态机折磨过的人，以及准备上 GPUDirect RDMA 做多机 GPU 通信但又不知道怎么处理显存注册和 Zero-Copy 的工程师。看完你至少能自己写一个简单的 RDMA 收发程序，并且在遇到丢包、卡死、带宽上不去的问题时，知道从哪里开始排查。

1. 内存旁路运动：我们到底在绕过什么

1.1 传统网络路径的瓶颈在哪里

传统网络的收发路径，往简单了说就是“三次搬运、两次等待”。假设应用进程要发送一个 4KB 的缓冲区，数据从用户态缓冲区复制到内核态 socket 缓冲区，这是一次搬运；内核协议栈把数据切包、添加 TCP/UDP 头，再交给网卡驱动，这又是一次搬运；网卡 DMA 到自己的 FIFO 然后发到线缆上，这是第三次。接收方向几乎是对称的，而且每次搬运都要把 CPU 拖下水，还要处理中断、软中断、内存拷贝、上下文切换。

在小流量场景下，这套路径没什么问题，CPU 完全可以兜得住。但到了 100GbE 或者 HDR InfiniBand 的环境里，线速转发下 CPU 根本来不及处理那么多报文，于是你会看到 cpu0 被打满，网卡带宽只跑到一半，延迟还动不动几十微秒。传统路径的瓶颈本质上不是网卡不够快，而是 CPU 和内核协议栈成了数据通路上的“收费站”。

RDMA 的思路很直接：把“收费站”拆掉，让应用的数据缓冲区直接和网卡对话。网卡上有专门的处理引擎，能自己解析报文头、自己搬运数据、自己生成完成事件，CPU 只在最开始下指令、最后收结果，中间过程完全不参与搬运。

1.2 RDMA 的三种基本语义

RDMA 不只是一种技术，它是一组能力的集合，最常被提到的是三种语义。

第一种是 SEND/RECV，也就是消息传递语义。发送方投递一个发送请求，接收方必须提前投递一个接收请求，两边“对上”之后数据才会被搬运。这种语义偏传统，但是用来做短消息、控制面通信非常灵活。

第二种是 RDMA READ，远程直接读取。本地进程知道远端的地址和访问密钥之后，主动发起一个读操作，数据从远端内存直接被搬回本地缓冲区，远端 CPU 毫不知情，也不会被打扰。

第三种是 RDMA WRITE，远程直接写入。本地进程把数据直接写到远端预先注册好的内存区域里，远端 CPU 同样完全无感。这种语义在 MPI、GPU 集合通信、分布式存储里用得最多，因为它的延迟最低、单向带宽最高。

这三种语义构成了所有上层应用的基础。你可以把 SEND/RECV 理解成两个人约好时间地点的会面，把 RDMA READ/WRITE 理解成拥有钥匙的快递员直接进房间放东西，区别就在于“远端 CPU 是否参与”。RDMA 高性能的核心，就是尽可能让远端 CPU 参与度降到零。

2. 核心概念拆解：QP/WQE/CQ/MR 是怎么协作的

2.1 QP——通信的“队列对”，一切状态的载体

QP 的全称是 Queue Pair，翻译过来叫队列对，它由一组发送队列（Send Queue）和一组接收队列（Receive Queue）组成。你可以把 QP 理解成一条双向点对点通信“管道”，一台机器的进程要和另一台机器的进程交换数据，两边各创建一个 QP，然后通过交换属性信息把两个 QP“配对”起来，配对完成之后就可以在这条管道上进行所有 RDMA 操作。

每个 QP 都有自己独立的编号（QPN），以及一组传输属性，比如最大消息大小、最大 WR 数量、最大 SGE 数量、使用的端口、访问权限等等。创建 QP 的时候，这些属性基本就要定下来，尤其是队列深度，太小影响吞吐，太大浪费内存。

重点聊一下 QP 类型。最常见的两种是 RC（Reliable Connection，可靠连接）和 UD（Unreliable Datagram，不可靠数据报）。RC 是一对一可靠传输，保证顺序、不丢包、不重复，适合绝大多数高性能场景；UD 是一对多不可靠传输，类似 UDP，报文有最大长度限制，主要用于管理面和需要广播的场景。还有 XRC 这种扩展型，本质上是为多对多通信时减少 QP 数量而设计的，入门阶段不用深究。

业界有一句话叫“RC 是核武器，UD 是杂役，后两者是特种兵”。实际项目中，RPC 和存储协议大多跑在 RC 上，管理面消息才用 UD。

2.2 WQE——下达给网卡的“工作订单”

WQE 的全称是 Work Queue Element，也就是工作队列元素。它分为 Send WQE（发送请求）和 Receive WQE（接收请求），在代码里对应ibv_send_wr结构体和ibv_recv_wr结构体。

一个 WQE 里装的是什么？其实是一张“操作清单”。它至少描述了：

• 执行什么操作，是 SEND 还是 RDMA READ，又或者是 RDMA WRITE。
• 操作的数据在哪里，通过 SGE（Scatter/Gather Element，分散聚合元素）列表指定，每个 SGE 包含内存地址、长度、L_Key。
• 针对 RDMA 操作的目标地址在哪，包含远程 QPN、R_Key、远程地址偏移量。
• 完成事件是通知 CQ，还是要求延迟生成完成事件，甚至要不要 SIG 标志。

把 WQE 投递到 QP 的动作叫ibv_post_send/ibv_post_recv，这个调用非常轻量，通常只需要几百纳秒。网卡硬件会以 DMA 的方式主动从内存里把 WQE 拉取过去，解析并执行。执行完成之后，网卡会生成一个 CQE（Completion Queue Entry）放到完成队列 CQ 里，应用程序通过轮询或事件来取。

理解 WQE 的关键在于：数据搬运指令是由硬件执行的，CPU 只负责“下订单”。下单成本极低，执行效率极高，这就是 RDMA 吞吐高的直接原因。

2.3 CQ——完成事件的统一出口

CQ 的全称是 Completion Queue，完成队列。它不区分发送还是接收，所有 QP 操作完成后生成的完成事件都统一放到这里，应用程序从 CQ 里取出一条一条的完成记录（WC，Work Completion），据此判断哪些操作成功、哪些失败。

CQ 的设计很像餐厅里顾客取餐的窗口：多个厨师窗口做好菜之后放窗台上，顾客到窗口取。厨师看不见顾客，顾客也不阻塞厨师，两边靠一个统一出口解耦。

实际操作中，CQ 的深度也有讲究，一般建议设置为“发送队列深度 + 接收队列深度”之和，甚至更大。如果 CQ 深度不够，完成事件无处安放，会导致严重的行为故障，比如 QP 直接进 error 状态。

取完成事件有两种方式：轮询（ibv_poll_cq）和事件（ibv_get_cq_event）。轮询是自旋检查，延迟低但占 CPU，适合密集同步场景；事件是内核唤醒，省 CPU 但延迟稍高，适合空闲等待场景。生产级程序通常两者结合：平时用事件休眠，收到完成事件后立刻切到轮询模式，榨干带宽又不浪费周期。

2.4 MR——内存的“门禁卡”与密钥系统

MR，Memory Region，内存区域，是 RDMA 里最容易被忽视、却最容易出问题的部分。RDMA 要求参与 DMA 操作的内存必须预先注册，注册后得到一对 key——L_Key（本地访问密钥）和 R_Key（远程访问密钥），并返回lkey和rkey。硬件在执行 DMA 时，会拿 WQE 里携带的 key 和真实内存的管理信息做校验，匹配才允许操作。

把这个机制理解成大厦的门禁：内存区域就是房间，MR 注册相当于给房间登记并配发房卡；L_Key 是房主卡，R_Key 是访客卡；远端机器要直接读写本地内存，必须拿到 R_Key 和对应内存地址。这层机制既保证了安全（不知道 key 就无法访问），也保证了性能（硬件能透明 DMA，无需每次都询问内核）。

注册 MR 的 API 是ibv_reg_mr，核心参数就是内存地址、长度和访问权限。访问权限包括本地写（IBV_ACCESS_LOCAL_WRITE）、远程读（IBV_ACCESS_REMOTE_READ）、远程写（IBV_ACCESS_REMOTE_WRITE）、远端原子操作（IBV_ACCESS_REMOTE_ATOMIC）等。注意，IBV_ACCESS_LOCAL_WRITE看起来只影响本地，实际上要让本地 DDMA 写这块内存也必须要，否则很多网卡会拒绝操作。

同样重要的一点：注册 MR 通常意味着这块内存会被锁在物理内存里，不能参与 swap 和减少页迁移。注册大块内存前，建议通过ulimit -l确认锁内存限制，不然会出现mr_reg返回 EPERM 的诡异问题。

3. 任意门的钥匙：GPUDirect RDMA 与 Zero-Copy 的实战收益

3.1 没有 GDR 的时候，GPU 数据是怎么“绕弯”的

当你想把显卡显存里的数据通过网络送到另一台机器时，如果没有 GPUDirect RDMA，数据路径非常憋屈：GPU 先把显存里的数据通过 PCIe 搬到主机内存（通常还需要 cudaMemcpy 建立 staging buffer），再通过 CPU 注册这段主机内存为 MR，最后经网卡发出去。接收方向对称。

这条路径最大的问题是“多了一次主机内存中转”，带宽被 PCIe 往返切割，延迟增加了好几微秒，CPU 还得去协调搬运。就好像你明明在同一个小区，却非要先去小区门口再绕回单元楼。

GPUDirect RDMA（简称 GDR）要解决的就是这件事：让网卡通过 PCIe 的 P2P（Peer-to-Peer，对等直连）能力，直接 DMA 到 GPU 显存，或者直接从 GPU 显存 DMA 读走数据。数据路径从“GPU->主机内存->网卡”变成“GPU->NIC”，中间的拷贝被彻底去掉，CPU 不需要参与数据搬移。

3.2 GDR 的核心实现：显存如何变成可 DMA 的地址

网卡直接访问 GPU 显存，并不是神奇的魔法，其本质是 PCIe P2P 和 GPU 显存映射。要把显存交给 RDMA 硬件，必须拿到显存数据在系统内存空间里的“物理地址映射信息”。两个关键路径：GPU 驱动通过BAR窗口把显存暴露给 PCIe 总线，然后用户层通过 CUDA 的cuPointerGetAttribute拿到指针属性，判断指针类型；再配合cuMemGetAddressRange等接口获取内存的起始范围，基于这些信息产生 mr。

代码层面，使用 GDR 一般需要用到 NVIDIA 提供的gdr_api库，或者直接依赖dma-buf的nvidia-peermem模块。流程大致是：

1. 用 CUDA 分配显存（cudaMalloc）。
2. 调用cuPointerGetAttribute获取指针对应的设备信息，确认它是一块 GDR 可访问的显存。
3. 通过gdr_open、gdr_map把显存 BAR 地址映射到本进程的用户空间虚拟地址。
4. 拿这个映射出来的地址去ibv_reg_mr注册 MR。
5. 后续 SEND/RDMA 操作就用这个 MR 上拿到的 lkey/rkey。

这个流程看起来只有几步，实际上很容易在注册 MR 时翻车。最常见的问题是：内存指针不是 CUDA 管控的标准显存（比如 pin buffer 或 managed memory），BAR 映射失败；另一个常见问题是没有加载nvidia-peermem内核模块，网卡驱动根本不知道对端有一个可以 DMA 的设备，P2P 请求会被显卡驱动拒掉。

3.3 Zero-Copy 场景下的收益到底有多大

Zero-Copy 直译是“零拷贝”，但在 RDMA 语境下，它真正的意思是：数据在整个传输路径上不发生“CPU 参与的拷贝”。CPU 不碰数据，不代表没有 DMA 搬运，只是搬运由硬件完成，本质上是“零 CPU 拷贝”。相比传统路径，Zero-Copy 能带来三个直接收益：

• 延迟明显下降。以 InfiniBand HDR 网卡为例，本地 TCP 路径发送 4KB 数据大概 30~50 微秒，RDMA SEND 只要 2~5 微秒；如果走 GDR 从显存直接发送，延迟还能再压低一截。
• 吞吐大幅提升。传统路径受限于 PCIe 带宽和 CPU 内存复制带宽。RDMA 走硬件 DMA，可以吃满网卡限额；GDR 则进一步绕开了主机内存这个瓶颈。
• CPU 占用骤降。数据传输阶段几乎不消耗 CPU，CPU 可以专注处理业务逻辑，一个核跑满就能带动 100Gbps 的通信。

我在一个 8 卡节点上用ib_write_bw测试过：TCP 直连三卡之间的跨机带宽只有 12~15 Gbps，切到 RDMA 后飙升到 180+ Gbps，延迟从几十微秒降到了 2 微秒级别。这不是纸面参数，而是实打实的可观测收益。前提是网卡支持 RoCE 或 InfiniBand，且 BIOS/驱动配置正确。

3.4 Zero-Copy 不是银弹：什么时候不值得用

Zero-Copy 并不永远是最优解，有一个边界条件必须搞清楚：消息长度。如果消息只有几十字节，RDMA 操作本身的链路建立成本、MR 管理和 WQE 投递的固定开销，可能比传统路径更不划算。实际工程里，低于 2KB 的消息往往走共享内存或者本地消息队列更高效，高于 8KB 才是 RDMA 的舒适区。

另外，注册 MR 本身也有成本。如果你的程序频繁分配、释放小内存，并每次都注册 MR，注册/注销的开销会吃掉很多性能。常见做法是内存池化，预分配多个缓冲块，反复注册一次，之后复用。对显存来说，池化同样重要，因为 GDR 注册显存 MR 的代价比主机普通内存更高。

4. 实操：从零写一个 RDMA 收发程序

4.1 环境准备与工具链

实操前首先要确认网卡型号和驱动。命令：

ibstat ibv_devinfo -v

如果输出里能看到端口状态 Active，且有基地址和 GID，说明驱动和链路正常。如果是 RoCE 环境，还要确认rdma-core版本和内核模块，可以直接用rxe_cfg或者系统自带的rdma_rxe模块做软件模拟，本机调试完全够用。

基础库一般用经典 IB verbs 接口，也就是 libibverbs 和 librdmacm。为了省事，我会直接用 librdmacm 进行连接管理，它把 QP 状态的初始化和地址交换封装了一层，配合 CM 事件机制，比裸连接要省心很多。

4.2 核心代码路径：注册 MR、创建 QP、投递 WQE、轮询 CQ

下面这段代码比较简版，但足以体现完整骨架。先看 MR 注册和 QP 创建：

#include <infiniband/verbs.h> #include <rdma/rdma_cma.h> struct ibv_pd *pd; struct ibv_mr *mr; struct ibv_cq *cq; struct ibv_qp *qp; /* 分配上下文和 protection domain */ pd = ibv_alloc_pd(ctx); buffer = malloc(BUF_SIZE); /* 注册内存区域 */ mr = ibv_reg_mr(pd, buffer, BUF_SIZE, IBV_ACCESS_LOCAL_WRITE | IBV_ACCESS_REMOTE_WRITE | IBV_ACCESS_REMOTE_READ); if (!mr) { perror("ibv_reg_mr"); return -1; } /* 创建完成队列 */ cq = ibv_create_cq(ctx, CQ_DEPTH, NULL, NULL, 0); /* 填充 QP 初始化属性 */ struct ibv_qp_init_attr qp_attr = {0}; qp_attr.qp_type = IBV_QPT_RC; qp_attr.send_cq = cq; qp_attr.recv_cq = cq; qp_attr.cap.max_send_wr = 128; qp_attr.cap.max_recv_wr = 128; qp_attr.cap.max_send_sge = 1; qp_attr.cap.max_recv_sge = 1; /* 创建 QP */ qp = ibv_create_qp(pd, &qp_attr); if (!qp) { perror("ibv_create_qp"); return -1; }

创建完 QP 之后，最关键的环节是状态迁移。QP 默认在 RESET 状态，必须先转到 INIT，再转到 RTR，然后才能到 RTS。这三个状态迁移都要通过ibv_modify_qp完成，而且每次传的参数不同。以 RESET->INIT 为例：

struct ibv_qp_attr init_attr = {0}; init_attr.qp_state = IBV_QPS_INIT; init_attr.pkey_index = 0; init_attr.port_num = 1; init_attr.qp_access_flags = IBV_ACCESS_LOCAL_WRITE | IBV_ACCESS_REMOTE_WRITE | IBV_ACCESS_REMOTE_READ; ibv_modify_qp(qp, &init_attr, IBV_QP_STATE | IBV_QP_PKEY_INDEX | IBV_QP_PORT | IBV_QP_ACCESS_FLAGS);

INIT->RTR 需要远程的 QPN、LID、GID、PSN、访问权限等信息，这就需要先在两个进程之间通过某种带外方式交换信息。实际项目中用 TCP socket 交换最方便，也可以用 CM 的rdma_connect自动处理。等双方拿到对端信息后，再执行 RTR 和 RTS 的迁移。

完成这些之后就可以投递 WQE 了。发送数据时的代码大概是：

struct ibv_sge sge = { .addr = (uintptr_t)buffer, .length = data_len, .lkey = mr->lkey, }; struct ibv_send_wr send_wr = {0}; send_wr.opcode = IBV_WR_SEND; send_wr.sg_list = &sge; send_wr.num_sge = 1; send_wr.send_flags = IBV_SEND_SIGNALED; struct ibv_send_wr *bad_wr = NULL; if (ibv_post_send(qp, &send_wr, &bad_wr)) { fprintf(stderr, "ibv_post_send failed\n"); return -1; }

发送端投递之后，接收端需要提前投递接收请求。接收方向相对简单，只需要 SGE 描述接收缓冲区就行：

struct ibv_recv_wr recv_wr = {0}; recv_wr.sg_list = &sge; recv_wr.num_sge = 1; ibv_post_recv(qp, &recv_wr, &bad_wr);

最后是轮询 CQ。完成事件有两种处理方式，这里给出最基本的轮询写法：

struct ibv_wc wc; while (1) { int n = ibv_poll_cq(cq, 1, &wc); if (n > 0) { if (wc.status != IBV_WC_SUCCESS) { fprintf(stderr, "work completion failed: %s\n", ibv_wc_status_str(wc.status)); break; } if (wc.opcode & IBV_WC_RECV) { /* 收到数据，处理 recv buffer */ } break; } }

这段代码没有处理连接建立、多线程、错误重传等细节，但核心链路是完整的。实际项目里还需要考虑：接收侧预投递多少个接收 WQE、发送侧的网络拥塞控制是否开启、CQ 轮询线程的 CPU 亲和性设置等。

4.3 快速验证：两行命令跑通 RDMA 性能测试

如果不想写 C 代码，可以直接用 perftest 工具验证链路带宽和延迟。在两台机器上分别执行：

# 机器 A ib_write_bw -d mlx5_0 -x 3 -F --report_gbits # 机器 B ib_write_bw -d mlx5_0 -x 3 -F 192.168.1.10 --report_gbits

-d指定网卡设备，-x指定 GID index，RoCE 环境通常需要匹配一下，否则会报地址解析错误。--report_gbits让输出显示 GB/s 单位。如果输出显示带宽接近网卡标称值，说明 RDMA 环境正常。

如果连接出问题，第一步检查两端是否能互相ping，第二步看ibstat端口状态，第三步看防火墙和子网管理器（InfiniBand 环境必须有 opensm 或者硬件 SM 在运行），RoCE 环境要确保 PFC/ETS 无损网络配置正确，不然重传率会高到让你怀疑人生。

5. QP 状态机深度解读：状态切换是门手艺活

5.1 QP 状态：从 RESET 到 RTS 再到 ERROR

QP 状态机是 RDMA 里最容易出问题的一环，也是排查故障时最应该第一个怀疑的对象。QL 只有四个主状态，但迁移条件极其严格。

开发中常见的错误是：还没把 QP 迁到 RTS 就开始ibv_post_send，拿到的错误是IBV_WC_WR_FLUSH_ERR，意思是请求被硬件 flush 了。这就像你还没把电梯门打开就让人往里冲，门都没开，货自然进不去。

迁移 QP 状态时有几个字段特别容易漏，比如init_attr.qp_access_flags只影响 INIT 阶段，rtr_attr.path_mtu、rtr_attr.rq_psn、rtr_attr.dest_qp_num是 RTR 阶段必须的，而 RTS 阶段必须带sq_psn和timeout、retry_cnt、rnr_retry等重传参数。漏掉retry_cnt或rnr_retry，会导致网络不稳定时遇到丢包不重传，表现为偶发卡顿。

5.2 状态切换和信息交换的“握手”

这里顺带解释一下 QP 状态机为什么和 VR/MR 切换有类似的地方。做 pico4 的 VR 到 MR 切换时，系统需要重新申请相机权限、重置渲染目标、将不可见层从渲染管线中摘除，这些操作必须按顺序执行，而且任何一步失败都不能继续下一步。RDMA 的 QP 迁移同样是严格顺序化的：INIT 不配好端口信息，就没有办法进入 RTR；RTR 不拿到对端 QPN 和 PSN，就没有办法进入 RTS。

做过 Unity MR 开发的人应该容易理解这种“状态门锁”的设计——本质上是为了保证系统不会在半配置状态下处理数据流，这是任何高性能系统共通的防御式设计。实际排查 QP 问题时，我经常画一张状态机表，对着表一项一项核对属性是否配齐，比直接看报错日志高效得多。

5.3 排查状态机问题的思路

遇到 QP 状态不对，先执行ibv_query_qp看看当前状态和期望状态差在哪里。代码里可以这样：

struct ibv_qp_attr attr; struct ibv_qp_init_attr init_attr; ibv_query_qp(qp, &attr, IBV_QP_STATE, &init_attr); printf("QP state = %d\n", attr.qp_state);

再配合ibv_asyncwatch抓异步事件，一般能看到QP_FATAL、PATH_MIGRATED、SQ_DRAINED等关键事件。如果异步事件显示IBV_EVENT_QP_LAST_WQE_REACHED，说明接收队列已经没有接收 WQE，程序要及时重新投递接收请求，否则 QP 会因为长期没有接收缓冲区而挂死。

6. 常见问题与避坑清单：我从实战里总结的经验

6.1 内存相关的坑：MR、锁页和显存

先列一张高频问题速查表，这些问题我基本都亲手踩过：

6.2 网络配置和性能优化

网络层面的问题往往比代码层面更隐蔽。RoCE 环境对 PFC（优先级流控）和 ECN 极其敏感，如果交换机没有开启 PFC，流量一大就会丢包，丢包直接表现为 RDMA 带宽断裂。排查这类问题时，网卡统计里重点看rx_roce_errors、tx_packets和rx_dropped。建议对网卡开启ibstat -p看丢包计数器，如果非零，先查交换机 QoS 配置。

另外，建议将 CPU 亲和性与中断绑定做一下，把 CQ 轮询线程绑定到网卡所属的 NUMA 节点上，避免跨 NUMA 访问内存出现 PCIe 链路绕远。在 2 路甚至 8 路服务器上，这个优化可能直接带来 20%~30% 的带宽提升。

还有一个小技巧：ibv_post_recv尽量一次性投递多个接收 WQE，不要来一条数据就投一条。批量投递能显著减少硬件轮询和用户态库的互斥操作，我在项目中把接收队列深度设为 256，再配合批量投递，消息处理峰值提升了接近一倍。

6.3 调试工具和日志建议

工具不在多而在会用。我日常调试 RDMA 的固定三步分别是：

1. ibstatus确认端口物理状态。
2. ibv_devinfo -v查设备能力，重点是 max_mr_size、max_qp_wr、max_sge、device_cap_flags，确认是否支持 GDR。
3. rdma statistic或网卡厂商计数器（mlx5 系列用mlx5_ib出错日志），查丢包和报文级错误。

日志方面，开启rdma-core的 debug 日志很有用，可以设置环境变量：

export RDMA_VERBS_LOG_LEVEL=4 export RDMA_CM_LOG_LEVEL=4

能看到完整的事件和状态机迁移日志，对定位 QP 状态问题帮助很大。

7. 一点实操碎碎念

说实话，RDMA 这套东西刚接触的时候容易觉得文档晦涩，概念又多，而且很多资料直接跳到内核代码或者英文手册，劝退了不少人。但真正把它跑通之后回头看，核心链路其实就是“注册内存、创建 QP、配好状态机、投递请求、取完成事件”这五步，没有想象中那么玄乎。

我个人实际操作中最受益的一个习惯是：每改一个 QP 属性，都顺手把ibv_query_qp的完整输出打印出来对比。很多时候问题不是“配置错了”，而是“配置漏了”。比如 state 已经是 RTS，但sq_psn和对端不一致，表现就是握手正常，发数据却永远 timeout。这类问题肉眼几乎无法从代码里看出来，只有靠状态机全量输出才能一眼定位。

最后再分享一个小技巧：如果你要在多个 GPU 节点之间做 AllReduce 之类的集合通信，不要自己从零裸写 RDMA 代码。直接用开源的集合通信框架（比如 NCCL 的 P2P/IB 后端），把底层环境验证好就足够了。自己写到的程度，应该是理解原理和排查问题，而不是把时间耗在重复造轮子上。RDMA 是一个一旦参数调对就稳定如老狗的东西，可如果参数没调对，它也能在一堆日志里把你折磨到怀疑人生。希望这篇文章能帮你少走几步弯路，至少遇到问题的时候，知道该往哪个方向去查。