InfiniBand/RDMA Send场景下如何获取附带的8字节自定义ACK

首先澄清两个常见认知偏差：

1. 网卡硬件自动生成的传输层ACK属于协议栈底层应答，仅能证明报文抵达对端网卡，无法证明对端应用已经完成数据块的接收、校验、业务处理，不能替代业务层自定义ACK。
2. 本地发送CQE携带的WR ID是标准64位（正好8字节），但这个值是本地Post发送请求时自行填入的上下文标识，对端无法修改填充，确实没法用来传递对端返回的自定义信息。

以下是按额外开销从低到高排序的生产可用方案：

• 方案1：双向流捎带确认（Piggybacking）
  把客户端、服务端的通信配置为全双工双向流模式，无需单独发送ACK报文。服务端处理完客户端发来的数据块后，不需要为ACK单独Post发送请求，直接把8字节ACK附在服务端下一次发给客户端的业务数据报文头部，随业务报文同步传输。如果场景中服务端本身存在持续的反向业务数据发送，这个方案完全不会产生额外报文开销，额外成本和硬件传输层ACK基本持平。针对偶发的服务端暂时无反向业务数据的情况，可以配置10us级别的极短捎带超时，超时后再触发单独ACK发送，绝大多数生产场景都能覆盖99%以上的请求。
• 方案2：IBV_SEND_INLINE 模式发送极小ACK报文
  如果服务端存在长时间无反向业务数据的场景，不需要发送常规RDMA Send报文传输8字节ACK。Post ACK发送请求时设置内联发送标志，8字节ACK会直接写入WQE（工作队列元素），不需要网卡额外发起DMA读内存操作，整个报文仅包含RDMA传输层头部+8字节有效数据，线速下封装后不超过以太网最小帧长，开销比常规Send低70%以上，几乎不会产生可感知的性能损耗。
  注意不要尝试使用带立即数的Send传ACK：立即数字段仅32位（4字节），长度不足以承载8字节自定义内容。
• 方案3：预注册ACK内存区 + RDMA Write with Immediate 应答
  建连阶段客户端预先注册一块缓存行对齐的8字节内存作为专属ACK接收槽，把这块内存的远程访问地址、RKey通过初始建连握手报文同步给服务端。服务端处理完数据后，不需要走Send流程、也不需要提前Post接收请求，直接发起带立即数的RDMA Write操作，把8字节ACK直接写入客户端预注册的ACK槽，立即数字段填充对应客户端数据块的序列号做防乱序校验。客户端收到RDMA Write产生的CQE时，直接从预注册内存区读取8字节ACK即可。整个流程比常规Send ACK少两次WQE调度开销，性能比普通Send ACK高40%左右。

以下方案不推荐在生产环境使用：

• 尝试修改网卡固件、驱动复用硬件传输层ACK携带自定义数据：InfiniBand/RoCE规范中传输层ACK报文格式固定，无预留自定义字段，修改后会破坏跨厂商网卡兼容性，稳定性无保障。

内容的提问来源于stack exchange，提问作者Mihir Shah