MSN (消息序列号)作为对重传的RDMA读取的响应
在对从Mellanox CX-4 (请求发起方)到另一个RNIC的64K消息大小运行ib_read_bw测试时，对于50KB的数据(前12KB已成功ACKed )，从Mellanox开始重新传输第5个RDMA-READ，之后它继续重新传输剩余50KB数据的相同请求，尽管目标RNIC正在响应。
一种观察结果是，对于重发的(对于50KB)读请求，目标RNIC在第一RDMA读响应中以MSN 11而不是5INT来响应。
infiniband规范说，对于重复请求，RNIC不应该增加MSN，这是否意味着RNIC应该用它拥有的任何MSN来响应(它可能已经响应了接收到的所有传入请求，并且MSN为16，然后看到了重发)，或者它应该用适当的MSN来响应重发的RDMA读取。
回答 2
Stack Overflow用户
发布于 2020-02-19 19:46:44
InfiniBand规范规定：
对于RDMA读请求，应答器可以在它已经完成验证请求之后并且在它已经开始发送任何所请求的数据之前递增其
，并且可以在第一响应分组的AETH中返回递增的MSN。
和
对于重复请求，MSN不应递增。
(C9-148)
我认为这意味着当发生重传时，MSN应该保持不变。
Stack Overflow用户
发布于 2020-02-27 18:36:01
是的，根据我的理解，MSN应该指向原始的读取请求。在响应重复发送或写入的情况下，PSN和MSN都是最后发送的ACK。这就像一个合并的ACK。
但是当响应于读请求时，PSN是原始读请求的，因此MSN也应该是原始读请求的。
From Spec -“要被视为重复的RDMA读取请求，重复请求的PSN必须在响应者当前的重复PSN区域内。此外，为了被认为是有效的复制RDMA读取请求，复制请求的PSN必须落入分配给原始RDMA读取响应的PSN的范围内，并且复制请求中所请求的数据量必须完全包含在原始RDMA读取请求中所请求的数据的范围内。换句话说，复制RDMA读取请求中请求的数据必须是原始RDMA读取请求中请求的数据的适当子集。如果重复的RDMA读取请求的起始PSN和长度不在分配给原始RDMA读取响应的PSN的范围内，则该请求是无效的，并且响应器可以静默地丢弃该重复的RDMA读取请求。
https://stackoverflow.com/questions/60294533
复制相似问题
腾讯云开发者
