当从Mellanox CX-4(请求启动器(向另一个RNIC运行64K消息大小的ib_read_bw测试时，正在从Mellanix向病房重新传输50KB数据的第5个RDMA-read(前12KB已成功确认(，之后它继续重新传输剩余50KB数据相同的请求，尽管目标RNIC正在响应。
一个观察结果是，对于重新发送的(对于50KB(读取请求，目标RNIC以11的MSN而不是第一个RDMA READ响应的5 int进行响应。
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 Request，则重复的PSN请求必须在响应程序的当前重复PSN区域内。此外要被视为有效的重复RDMA READ请求重复请求的PSN必须在分配的PSN范围内原始RDMA READ响应，以及请求的数据量在重复的请求中必须完全包含在原始RDMA READ Request中请求的数据。换句话说在重复的RDMA READ Request中请求的数据必须是正确的原始RDMA READ Request中请求的数据的子集。如果重复RDMA READ Request的起始PSN和长度不落在分配给原始RDMA READ响应的PSN的范围内，请求无效，响应程序可能会静默地丢弃重复项RDMA读取请求">