响应重传 RDMA 读取的 MSN（消息序列号）答案

【问题标题】：MSN (message sequence number) in response for a retransmitted RDMA Read响应重传 RDMA 读取的 MSN（消息序列号）
【发布时间】：2020-02-19 06:49:25
【问题描述】：

在对从 Mellanox CX-4（请求发起者）到另一个 RNIC 的 64K 消息大小运行 ib_read_bw 测试时，从 Mellanox 开始重新传输第 5 次 RDMA-READ 之后的 50KB 数据（前 12KB 已被确认）成功），之后它不断地重新传输剩余 50KB 数据的相同请求，尽管目标 RNIC 正在响应。

观察到目标 RNIC 在第一个 RDMA READ 响应中响应的 MSN 为 11，而不是 5，用于重新传输（对于 50KB）读取请求。

infiniband 规范说，对于重复的请求，RNIC 不应该增加 MSN，这是否意味着，RNIC 应该使用它拥有的任何 MSN 进行响应（它可能已经响应了所有收到的传入请求并且 MSN 为 16 和然后看到重新传输）或者它是否应该以正确的 MSN 响应重新传输的 RDMA READ。

【问题讨论】：

标签： nic infiniband rdma mellanox

【解决方案1】：

InfiniBand 规范说：

对于 RDMA READ 请求，响应者可以在完成对请求的验证后增加其 MSN，并且在它开始传输任何请求的数据之前，并可能返回第一个响应包的 AETH 中增加的 MSN。

和

MSN 不会因重复请求而增加。

(C9-148)

我相信这意味着当重传发生时 MSN 应该保持不变。

【讨论】：

感谢您的评论。我的理解也是一样的。但问题是响应者应该在对重传数据包的回复中包含什么 MSN。例如，在我的情况下，它是重新传输的第 5 个 pkt，所以它应该有 5 个作为 MSN，还是应该有它拥有的最新 MSN（可能是其他数据包（RDMA SEND/WRITE）可能已经收到了 ACK在重新传输之前）？规范确实说“不应更改 MSN”，但并没有明确说明重复响应应该有什么？
据我了解应该是最新的，但我同意不清楚。

【解决方案2】：

是的，根据我的理解，MSN 应该指向原始读取请求。在响应重复的 SEND 或 WRITE 的情况下，PSN 和 MSN 都是最后发送的 ACK。这用作合并的 ACK。
但是在响应读取请求时，PSN是原始读取请求的，因此MSN也应该是原始读取请求的。

来自规范 - “被视为重复的 RDMA READ 请求，重复的 PSN 请求必须在响应者当前的重复 PSN 区域内。此外，被认为是一个有效的重复 RDMA READ 请求，重复请求的 PSN 必须在分配的 PSN 范围内到原始 RDMA READ 响应，以及请求的数据量在重复请求中必须完全包含在原始 RDMA READ 请求中请求的数据。换句话说，重复 RDMA 读取请求中请求的数据必须是正确的原始 RDMA READ 请求中请求的数据的子集。如果重复 RDMA READ 请求的起始 PSN 和长度不不在分配给原始 RDMA READ 响应的 PSN 范围内，请求无效，响应者可能会默默地删除副本 RDMA 读取请求"

【讨论】：