legionxiong commented on issue #3132: URL: https://github.com/apache/brpc/issues/3132#issuecomment-3545698118
> > 滑动窗口失效的原因应该不是共享 CQ 所致， 而是滑动窗口机制依赖一个前置条件并不成立， 就是本端应用层收到了对端应用层的 ACK 就认为底层 SQ 都释放掉了。 在无损的 IB 网络， 这个条件可能成立。 而对于基于以太网的 RoCEv2， 这个是不保证的。 底层驱动发送一个消息后，只有收到对端驱动的 ACK 才会释放 SQ。 当网络压力大的时候， 存在一种情况， 对端收到了消息然后对端应用层也处理了消息， 但是对端驱动层回复的 ACK 丢了或者超时了； 而本端应用层收到了对端应用层发送的 ACK， 累加窗口， 实际上本端驱动层因为接收 ACK 超时导致重发消息， 并未释放 SQ。 > > [@legionxiong](https://github.com/legionxiong) hi，这么理解对吗：就是驱动层ACK丢失了进行重传，导致应用先看见recv cqe去累加窗口，后续再看见send cqe。我理解的话，驱动层ACK是影响cqe的生成，不能直接影响资源的释放。（例如：SQ的释放取决于send cqe从CQ中何时poll下来） 驱动层 ACK 影响的是 WC 的生成， 而 brpc 内有个优化就是 1/4 窗口给 wr 设置一次 IBV_SEND_SIGNALED。 只有设置了 IBV_SEND_SIGNALED 标志的 wr 或者出错了才会给该 wr 生成 WC，可以认为当应用层 poll 到了 opcode 为 IBV_WC_SEND 的 wr 则可以认为该 wr 及其前面 unsignaled 的 SQ 都被释放掉了。 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
