在对从 Mellanox CX-4（请求发起者）到另一个 RNIC 的 64K 消息大小运行 ib_read_bw 测试时，正在从 Mellanox 重新传输第 5 次 RDMA-READ 之后的 50KB 数据（前 12KB 已成功确认），之后它不断地重新传输剩余 50KB 数据的相同请求，尽管目标 RNIC 正在响应。
观察到目标 RNIC 在第一个 RDMA READ 响应中以 11 而不是 5 int 的 MSN 响应，用于重新传输（对于 50KB）读取请求。
infiniband 规范说，对于重复的请求，RNIC 不应该增加 MSN，这是否意味着，RNIC 应该用它拥有的任何 MSN 进行响应（它可能已经响应了所有收到的传入请求并且 MSN 为 16，然后重新传输被看到）或者它是否应该以正确的 MSN 响应重新传输的 RDMA READ。
InfiniBand 规范说：
对于 RDMA READ 请求，响应者可以在完成对请求的验证之后并在开始传输任何请求的数据之前增加其 MSN，并且可以在第一个响应数据包的 AETH 中返回增加的 MSN。
和
MSN 不应因重复请求而增加。
(C9-148)
我相信这意味着当重传发生时 MSN 应该保持不变。
是的，据我了解，MSN 应该指向原始读取请求。在响应重复的 SEND 或 WRITE 的情况下，PSN 和 MSN 都是最后发送的 ACK。这用作合并的 ACK。
但是在响应读取请求时，PSN 是原始读取请求的，因此 MSN 也应该是原始读取请求的。
从规范 - “要被视为重复的 RDMA READ 请求，重复请求的 PSN 必须在响应者当前的重复 PSN 区域内。此外，要被视为有效的重复 RDMA READ 请求，重复请求的 PSN 必须在分配给原始 RDMA READ Response 的 PSN 范围，以及重复请求中请求的数据量必须完全包含在原始 RDMA READ 请求中请求的数据范围内。换句话说，重复 RDMA 中请求的数据READ Request 必须是原始 RDMA READ Request 中请求的数据的适当子集。如果重复 RDMA READ Request 的起始 PSN 和长度不在分配给原始 RDMA READ Response 的 PSN 范围内，请求无效，响应者可能会静默丢弃重复的 RDMA READ 请求“