However I'm not sure I understand why the MAD layer wants to resize these objects -- given that the number of QPs is known in advance and that the MAD layer can choose how many work requests to post per QP, I'm not sure what is gained by trying to resize things dynamically.
Actually, I haven't really implemented the "dynamically" part, where you resize the CQ during operation. The spec said that when you create a QP, it can be larger than what you specified. If so, I see good value in increasing the size of the associated CQ, if it is supported by the driver.
Might this be useful for redirected QPs ?
Since the client allocates the QP and CQ in this case, they would be responsible for resizing the CQ appropriately. The MAD layer could provide queuing to prevent send queue overflow, or not, depending on how we want to implement it.
Should the incorporation of this functionality be deferred until either there is hardware which supports this or we find some use for it ?
I think we should go ahead an put this code in. We need to handle the case where the QP is sized larger than what we request anyway, to ensure that we don't overrun the CQ.
_______________________________________________
openib-general mailing list
[EMAIL PROTECTED]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
