从一次诡异的丢包说起去年做分布式存储项目，凌晨三点被值班电话叫醒——集群某节点RDMA写操作间歇性超时。抓包看链路层一切正常，ibv_poll_cq返回的WC状态码全是IBV_WC_SUCCESS，但上层应用就是收不到数据完成通知。折腾到天亮才发现，问题出在Completion Channel的轮询策略上——我们用了默认的阻塞式轮询，但生产环境某个NUMA节点的中断亲和性配置错误，导致CQ事件被延迟处理了整整200微秒。从那以后，我养成了一个习惯：凡是涉及RDMA事件通知的代码，必须手写两套方案——Completion Channel和Event Channel各一套，线上跑A方案，B方案作为热备随时切换。Completion Channel：你的CQ事件管家Completion Channel本质上是一个文件描述符，专门用来接收CQ（Completion Queue）的事件通知。创建它的API长这样：structibv_comp_channel*channel=ibv_create_comp_channel
从一次诡异的丢包说起去年做分布式存储项目，凌晨三点被值班电话叫醒——集群某节点RDMA写操作间歇性超时。抓包看链路层一切正常，ibv_poll_cq返回的WC状态码全是IBV_WC_SUCCESS，但上层应用就是收不到数据完成通知。折腾到天亮才发现，问题出在Completion Channel的轮询策略上——我们用了默认的阻塞式轮询，但生产环境某个NUMA节点的中断亲和性配置错误，导致CQ事件被延迟处理了整整200微秒。从那以后，我养成了一个习惯：凡是涉及RDMA事件通知的代码，必须手写两套方案——Completion Channel和Event Channel各一套，线上跑A方案，B方案作为热备随时切换。Completion Channel：你的CQ事件管家Completion Channel本质上是一个文件描述符，专门用来接收CQ（Completion Queue）的事件通知。创建它的API长这样：structibv_comp_channel*channel=ibv_create_comp_channel