研究员RDMA黑客，有没有人知道rdma_get_recv_comp（），它是否会超时调用__ibv_get_cq_event（）？
我的问题是使用与此处所示相同的程序： RDMA program randomly hangs
它工作正常，但它不能抵抗随机客户端断开连接。具体来说，如果我强行终止客户端，那么服务器会卡在rdma_get_recv_comp（）/ ipv_get_cq_event（）中。
这是针对Mellanox ConnectX-3而且我检查了默认超时是2.14s并且重试= 1.但是我不清楚阻塞模式下的ibv_get_cq_event（）是否会超时。 ibv_modify_qp（）文档中对超时的解释似乎建议超时仅适用于发送（rdma_get_send_comp（）），因为只有发送方等待ACK。但是我也没有看到允许接收超时的任何困难。
如果在这种情况下预计挂在rdma_get_recv_comp（）内部，我该如何避免它或实现超时？
一些可能性：
更改我的客户端关闭序列，以便它执行所有必要的发送，以便它不会让服务器上的rdma_get_recv_comp（）挂起？
将rdma_get_recv_comp（）替换为轮询接收完成的循环
答案 0 :(得分：2)
ibv_get_cq_event()没有超时。它等待完成事件（在工作请求完成时生成并生成完成队列条目）。如果没有生成任何事件，比如因为您的接收永远不会完成，那么您将永远等待。如果QP（连接）转换为错误状态，那么所有已发布的接收都将以刷新状态完成 - 但如果在轮询所有完成之前销毁QP，则它们将从CQ中删除。
所以你的问题可能是当客户端断开连接时，另一方不一定检测到断开连接 - 例如，如果客户端只是重新启动，那么RDMA CM将不会干净地断开连接，如果服务器端没有在飞行中有任何发送，它不会注意到断开连接。您可以使用某种keepalive处理此问题 - 0字节RDMA WRITE对此非常有用，因为它们是NOP，但如果连接出现任何问题，则会失败。
或者，当它从RDMA CM收到断开连接通知时，您的服务器可能太急于破坏QP。您希望在连接结构上有引用计数，以便在销毁QP之前等待您要等待的所有内容。
最后，可以以非阻塞方式使用ibv_get_cq_event()。该联机帮助页有一个示例，即在基础完成通道文件描述符上使用poll()来等待超时的事件。