On Wed, Mar 29, 2017 at 07:59:13PM +0300, Sagi Grimberg wrote: > Yea, you're right, and not only I got it wrong, I even contradicted my > own suggestion that was exactly what you and Jason suggested (where is > the nearest rat-hole...) > > So I suggested to signal every X/2 and Marta reported SQ overflows for > high queue-dpeth. Marta, at what queue-depth have you seen this? I just want to clarify my comment about RQ - because you are talking about a queue depth concept. It is tempting to rely on a queue depth of X == SQ depth of X (or 2* in this case) and then try to re-use the flow control on the queue to protect the SQ from overflow. Generally this does not work because the main queue can retire work from either the CQ or the RQ. If the retire workload is mainly RQ based then you can submit to the SQ without a CQ poll and overflow it. Generally I expect to see direct measurement of SQ capacity and plug the main queue when the SQ goes full. To check this use a simple assertion, decrement a counter on every post, increment it appropriately on every polled CQ, init to the SQ depth, and assert the counter never goes negative. Triggering the assertion is an unconditional ULP bug, and is the most likely cause of a posting no space failure. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
