chenBright commented on issue #3132: URL: https://github.com/apache/brpc/issues/3132#issuecomment-3550584228
> > > 我理解，这种场景下，有可能4个窗口期都poll不到send WC。 > > > > > > 想到一个 idea， 应用层记录的 sq_size 耗尽某种程度上也是一种 “事件”，可以自我感知。 比如调用`RdmaEndpoint::CutFromIOBufList` 的时候如果查到 sq_size 为 0 意味着需要去 poll cq，预期一定会有 send WC 产生，除非网络断了。 这时触发一次 PollCq ，然后返回 EAGAIN。 > > 我们跑了一个小时才复现这个问题，[@sunce4t](https://github.com/sunce4t) 没有遇到这个问题， 考虑到这个问题复现概率比较小，需要主动尝试PollCq的概率应该比较小。同时支持自定义等待写的超时时间来控制主动PollCq的频率，让用户有能力在cpu和延时之间做权衡。 > > [brpc/src/brpc/socket.cpp](https://github.com/apache/brpc/blob/a54b6071ba4336dc6a2cc9ad242836b35a26ce62/src/brpc/socket.cpp#L1867-L1870) > > Lines 1867 to 1870 in [a54b607](/apache/brpc/commit/a54b6071ba4336dc6a2cc9ad242836b35a26ce62) > > if (!s->_rdma_ep->IsWritable()) { > g_vars->nwaitepollout << 1; > if (bthread::butex_wait(s->_epollout_butex, > expected_val, &duetime) < 0) { > CQ拆成send CQ（solicited_only=0）和recv CQ（solicited_only=1）这个实现，在我们这边已经验证过没问题的，我认为可以保留。如果在某些场景下，主动尝试PollCq不能很好解决问题，用户通过gflag使能这个实现。 -- 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]
