sunce4t commented on issue #3132:
URL: https://github.com/apache/brpc/issues/3132#issuecomment-3546122179

   > > 本端的IBV_SEND_SOLICITED设置后影响的应当是对端是否在comp 
channel上生成一个event以触发poll_cq,这个问题看起来是本端一直没有event产生,导致没法进入poll_cq流程?
   > 
   > 是的,问题是本端没有send CQE产生。
   > 
   > [Solicited 
Event文档](https://www.rdmamojo.com/2014/05/27/solicited-event/)提到,IBV_SEND_SOLICITED是在对端的comp
 channel的生成event。我测过,本端是没有event的,所以不会PollCq。
   > 
   > 当前实现是在对端设置了IBV_SEND_SOLICITED后,触发本端进入PollCq,将这之前的的IBV_WC_SEND顺便poll出来的。
   
   我个人是这样理解的:
   假设本端发送请求,对端回复。正常的逻辑:
   1.对端在回复的时候是设置IBV_SEND_SOLICITED,本端产生event去poll_cq。
   2.poll到send cqe和recv cqe,进行对应窗口更新。
   按照 @legionxiong 的说法,send cqe可能由于网络问题延迟生成。
   那么在  2  这一步,就会出现应用层先看见recv cqe。这也是之前我们遇到的滑动窗口bug。
   
   关于@chenBright 遇到的问题,是否存在这样的情况:
   
在本端的sq应用层窗口消耗完前,本端高速发送数据,对端正常的设置IBV_SEND_SOLICITED进行回复,本端也有产生event去触发poll_cq,由于以太网的问题send
 cqe一直在延迟生成,所以这个过程中一直没有poll到send cqe(这个过程可能有多次event的生成,且在这个过程中send 
cqe的生成都被延迟了)。最后当本端的sq应用层窗口消耗完毕,对端无法再回复,本端也无法再进入poll_cq了;最终导致超时。


-- 
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]

Reply via email to