3、QP状态机与连接管理：QP状态转换错误、非正常断开重连、以及SRQ使用不当导致的死锁
QP状态机，说白了就是RDMA连接的“生命周期管理”。
我见过太多人在这上面栽跟头了。状态转换搞错，连接断了重连不上，SRQ用着用着程序就卡死了。嗯，今天咱们就把这几个坑一个一个填平。
3.1 QP状态机：别把状态搞乱了
QP的状态转换其实不复杂，但很多人把它想复杂了。核心就这几个状态：RESET、INIT、RTR、RTS，还有SQD、SQE、ERR。
正常流程是这样的：
- RESET → 创建QP后的初始状态
- INIT → 调用
ibv_modify_qp，设置QP属性 - RTR → Ready to Receive，准备好接收了
- RTS → Ready to Send，可以发送数据了
我刚开始做RDMA时，犯过一个低级错误：直接从RESET跳到RTS，跳过了RTR。结果呢？对端发来的数据根本收不到，程序一直卡在等待完成事件上。查了半天才发现是状态机没走对。
正确的代码示例：
// 第一步：RESET → INIT
qp_attr.qp_state = IBV_QPS_INIT;
ibv_modify_qp(qp, &qp_attr,
IBV_QP_STATE | IBV_QP_PKEY_INDEX |
IBV_QP_PORT | IBV_QP_ACCESS_FLAGS);
// 第二步：INIT → RTR
qp_attr.qp_state = IBV_QPS_RTR;
ibv_modify_qp(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);
// 第三步：RTR → RTS
qp_attr.qp_state = IBV_QPS_RTS;
ibv_modify_qp(qp, &qp_attr,
IBV_QP_STATE | IBV_QP_SQ_PSN |
IBV_QP_TIMEOUT | IBV_QP_RETRY_CNT |
IBV_QP_RNR_RETRY | IBV_QP_MAX_QP_RD_ATOMIC);
3.2 非正常断开重连：别想着“原地复活”
连接断了怎么办？很多人第一反应是：把QP状态改回RTS继续用。
错！大错特错！
为什么会这样？因为QP一旦进入ERR状态，它内部的状态机就已经“脏”了。你想想看，发送队列里可能还有没完成的WR，接收队列里也可能有乱序的数据包。强行恢复，数据一致性就全毁了。
我在项目中遇到过这样的情况：网络抖动导致连接断开，我尝试直接修改QP状态回RTS。结果呢？数据发出去对端收不到，对端发来的数据我这边也匹配不上。最后整个集群的数据都乱了，花了整整一天才恢复。
✅ 正确的做法：
- 销毁旧的QP：
ibv_destroy_qp(qp) - 创建新的QP：
ibv_create_qp(pd, &qp_init_attr) - 重新走一遍状态机：RESET → INIT → RTR → RTS
- 重新建立连接（交换QPN等信息）
说白了，就是“旧的不去，新的不来”。别想着修复一个坏掉的QP，直接重建一个更省心。
💡 个人经验： 我习惯在应用层维护一个“连接健康检查”机制。每隔几秒发一个心跳包，如果连续3次没收到回应，就主动触发重连流程。这样比被动等待错误通知要快得多。
3.3 SRQ使用不当导致的死锁：一个隐蔽的陷阱
SRQ（Shared Receive Queue）是个好东西，能节省内存，还能提高性能。但用不好，它就是个“定时炸弹”。
最常见的死锁场景是这样的：
- 应用A通过SRQ接收数据
- 应用A处理完数据后，需要把接收缓冲区归还给SRQ
- 但应用A忘了归还，或者归还的时机不对
- SRQ里的缓冲区越来越少，最后变成0
- 对端发数据过来，没有缓冲区可用，连接就卡死了
我曾经就踩过这个坑。当时做一个分布式存储系统，用SRQ来管理接收缓冲区。上线跑了一个星期，突然所有节点都卡住了。查了半天，发现是某个线程在处理完数据后，没有调用ibv_post_srq_recv把缓冲区还回去。SRQ空了，所有QP都收不到数据了。
⚠️ 死锁的典型特征：
- 程序没有崩溃，但所有IO操作都卡住了
- CPU使用率很低（因为没有事情可做）
- 网络流量降为0
- 日志里没有错误信息（因为不是异常，只是没缓冲区了）
怎么避免？我给你几个建议：
| 问题 | 解决方案 |
|---|---|
| 忘记归还缓冲区 | 在代码里加一个“缓冲区追踪”机制，每次分配和归还都记录日志 |
| 归还时机不对 | 确保在ibv_poll_cq取出完成事件后，立即归还缓冲区 |
| 缓冲区数量不够 | SRQ的缓冲区数量至少是QP数量的2倍以上，留足余量 |
| 多线程竞争 | 用原子操作或锁来保护ibv_post_srq_recv的调用 |
嗯，这里要注意一点：SRQ的缓冲区归还操作必须是线程安全的。我见过有人用多个线程同时调用ibv_post_srq_recv，结果导致内部数据结构损坏，程序直接崩溃。
💡 调试技巧： 如果怀疑是SRQ死锁，可以用ibv_query_srq查看当前的缓冲区数量。如果srq_attr.srq_limit接近0，那基本就是缓冲区耗尽了。
最后总结一下：QP状态机要严格按顺序走，断开连接就重建，SRQ的缓冲区管理要小心谨慎。这三个坑踩一个就够你折腾半天了。