4、队列对（QP）状态机：Reset、Init、RTR、RTS状态转换、QP属性配置陷阱
QP状态机，说白了就是RDMA通信的“交通灯”。
我刚开始接触RDMA时，觉得这东西不就是几个状态来回切嘛，有啥好研究的？直到有一次线上事故，QP卡在某个中间状态，整个集群的IO都挂了……嗯，从那以后我再也不敢小看这玩意儿了。
4.1 为什么要有QP状态机？
你想想看，一个QP要收发数据，总得有个“准备”的过程吧？
就像你打电话，得先拨号、等待接通、确认对方在线，然后才能开始说话。QP状态机干的就是这个事——它确保通信双方在正确的时机做正确的事。
我个人习惯把QP状态机理解为四个阶段：
- Reset：刚创建，啥也没干
- Init：初始化完成，可以发一些控制消息了
- RTR：准备好接收数据
- RTS：收发全开，正式干活
4.2 Reset状态：一切归零
QP刚创建时，默认就在Reset状态。这时候的QP，说白了就是个空壳子。
我在项目中遇到过有人试图在Reset状态下直接发数据，结果可想而知——操作返回错误，代码直接崩了。
从Reset到Init，需要调用ibv_modify_qp()，设置好基本的QP属性。这里有个坑——很多人忘了设置QP的qp_context，虽然不影响状态转换，但后续调试时会让你抓狂。
4.3 Init状态：准备工作就绪
进入Init状态后，QP的发送队列和接收队列都分配好了内存。但注意，这时候还不能收发数据。
Init状态主要做两件事：
- 配置QP的发送属性（比如最大SGE数、最大WR数）
- 绑定QP到对应的完成队列（CQ）
我记得有一次排查性能问题，发现QP的max_send_wr设得太小，导致发送端频繁阻塞。后来调大了这个值，吞吐量直接翻倍。
max_send_wr和max_recv_wr设到硬件支持的上限。别省这点内存，性能瓶颈往往就出在这里。
4.4 RTR状态：准备好接收
从Init到RTR，是一次关键的状态跃迁。这时候QP已经准备好接收数据了，但还不能发送。
配置RTR时，需要指定：
- 目的QP的QP号（
dest_qp_num） - 目的LID（如果是InfiniBand）或GID（如果是RoCE）
- 接收端的PSN（包序列号）
核心要点：RTR状态下的QP，就像一个只接电话不打出去的电话。它只能收，不能发。
我曾经犯过一个低级错误——在RTR状态下忘了设置dest_qp_num，结果QP一直收不到数据。排查了半天才发现是这里漏了。嗯，这种坑踩过一次就不会再犯了。
4.5 RTS状态：全双工通信
最后一步，从RTR到RTS。这时候QP才真正“活”了，可以同时收发数据。
进入RTS需要配置：
- 发送端的PSN（包序列号）
- 超时重传参数（
timeout、retry_cnt） - 是否启用
RNR NAK（接收端未就绪时的重传机制）
我个人习惯在RTS阶段把retry_cnt设成7（最大值），timeout设成20左右。这样既能保证可靠性，又不会因为重传太频繁影响性能。
timeout设得太小，导致网络抖动时频繁重传，反而把网络打满了。后来调大了timeout值，问题就解决了。记住——不是所有参数都越大越好，也不是越小越好，得根据实际网络环境来。
4.6 QP属性配置陷阱汇总
说了这么多，我把常见的配置陷阱整理成了一张表，方便你对照检查：
| 陷阱 | 表现 | 原因 | 解决方案 |
|---|---|---|---|
| PSN不匹配 | 连接失败或丢包 | 通信双方的PSN不一致 | 确保两端PSN相同，或使用握手协议协商 |
| max_sge设太小 | 大数据传输失败 | SGE数量不足以描述数据缓冲区 | 设到硬件支持的最大值（通常为4或8） |
| 忘记设置dest_qp_num | RTR状态后无法通信 | QP不知道要跟谁通信 | 在modify_qp时务必传入dest_qp_num |
| timeout/retry_cnt不合理 | 性能差或连接断开 | 参数与网络延迟不匹配 | 根据实际RTT调整，建议先测试再上线 |
| CQ绑定错误 | 完成事件收不到 | QP绑定了错误的CQ | 检查CQ的编号和类型是否匹配 |
4.7 状态转换的代码示例
光说不练假把式。下面是一个典型的QP状态转换代码片段：
struct ibv_qp_attr attr;
struct ibv_qp_init_attr init_attr;
// 1. Reset -> Init
memset(&attr, 0, sizeof(attr));
attr.qp_state = IBV_QPS_INIT;
attr.pkey_index = 0;
attr.port_num = 1;
attr.qp_access_flags = IBV_ACCESS_LOCAL_WRITE | IBV_ACCESS_REMOTE_WRITE;
ibv_modify_qp(qp, &attr, IBV_QP_STATE | IBV_QP_PKEY_INDEX | IBV_QP_PORT | IBV_QP_ACCESS_FLAGS);
// 2. Init -> RTR
attr.qp_state = IBV_QPS_RTR;
attr.path_mtu = IBV_MTU_1024;
attr.dest_qp_num = remote_qpn;
attr.rq_psn = 0;
attr.max_dest_rd_atomic = 1;
attr.min_rnr_timer = 12;
ibv_modify_qp(qp, &attr, IBV_QP_STATE | IBV_QP_AV | IBV_QP_PATH_MTU | IBV_QP_DEST_QPN | IBV_QP_RQ_PSN | IBV_QP_MAX_DEST_RD_ATOMIC | IBV_QP_MIN_RNR_TIMER);
// 3. RTR -> RTS
attr.qp_state = IBV_QPS_RTS;
attr.sq_psn = 0;
attr.max_rd_atomic = 1;
attr.retry_cnt = 7;
attr.rnr_retry = 7;
attr.timeout = 20;
ibv_modify_qp(qp, &attr, IBV_QP_STATE | IBV_QP_SQ_PSN | IBV_QP_MAX_QP_RD_ATOMIC | IBV_QP_RETRY_CNT | IBV_QP_RNR_RETRY | IBV_QP_TIMEOUT);
小技巧：每次modify_qp后，建议调用ibv_query_qp()检查一下状态是否真的切换成功了。我见过有些网卡驱动有bug，状态切换失败但没报错，结果后面所有操作都异常。
4.8 总结
QP状态机这东西，说复杂也复杂，说简单也简单。你只要记住：
- 状态转换是单向的，不能回退
- 每个状态都有特定的能力，别越权操作
- 参数配置要匹配两端，否则通信失败
我做了这么多年RDMA，见过太多人栽在QP状态机这个坑里。说白了，它就是RDMA通信的“基本功”，基本功不扎实，后面再花哨的优化都是空中楼阁。
嗯，这一章就到这里。下一章我们聊聊WR（工作请求）的提交与完成机制，那才是真正考验性能调优功底的地方。