<div dir="ltr"><div>Thanks Sean for your quick response.</div><div><br></div>I found a workaround to the problem. Previously I was doing cq_read for multiple completions. If I do cq_read for a single completion the problem goes away. Is this the expected behavior or something wrong with my program or a bug in libfabric?<div><br></div><div>The problem was on the receiver side. Once I start doing single cq_reads on the receive side the transmissions started to complete.</div><div><div><br></div><div>The slowdown was pretty significant in my case. <br><div><div><br></div><div>Thanks,</div><div>Supun..<br><div><br></div><div><br></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 21, 2017 at 12:50 PM, Hefty, Sean <span dir="ltr"><<a href="mailto:sean.hefty@intel.com" target="_blank">sean.hefty@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> It seems when the number of nodes increases, some of the QPs become<br>
> slow randomly. I noticed this with the CQs for transmitting. It seems<br>
> the CQ's doesn't give the completion events in an adequate time. Some<br>
> of them basically take the abnormally long time to complete. The<br>
> application uses flow control etc, and it seems those aspects are fine.<br>
<br>
</span>How many nodes does it take before you see the slow down?  Eventually the number of active connections will swamp the caching capabilities on the NIC/HCA, which will result in QP states being swapping to/from the card from memory.  You can also see slowdowns if receive side buffers are not being re-posted quickly enough.<br>
<br>
Other than those guesses, we'd need more information about the setup/application to know if this is something in the verbs provider or underlying hardware/software.<br>
<span class="HOEnZb"><font color="#888888"><br>
- Sean<br>
</font></span></blockquote></div><br></div>