[openib-general] [PATCH RFC] return qp pointer as part of ib_wc

Or Gerlitz ogerlitz at voltaire.com
Tue Jan 2 02:54:28 PST 2007


Michael S. Tsirkin wrote:
>>> Use case:
>>> In IPoIB CM code, I have a common CQ shared by multiple QPs.
>>> To track connection usage, I need a way to get at some per-QP context
>>> upon the completion, and I would like to avoid allocating
>>> context object per work request just to stick a QP pointer into it.
>>> With this code, I can just use wc->qp->qp_context.

>> IPoIB CM uses SRQ so you can not stick a qp context in advanced, simply 
>> b/c you can't tell on behalf of which QP this WR would be used.

> Sorry, I could not parse this sentence.

This sentence refers to your use case description, not to what this 
patch is doing. And again, when SRQ is used, the IB consumer can not 
stick a per QP context to the WR on post recv time b/c you can't tell on 
behalf of which QP the SRQ would consume the WR, is it clearer now?

> All my patch does is, put struct ib_qp * instead of qp_num in ib_wc -
> this is more useful for ULPs and turns out not to have extra cost
> for low-level drivers.

sure, it makes sense to me, it can help any IB ULP that uses SRQ or uses 
the same CQ to report completions from multiple QPs.

>> However, looking on ipoib_cm_handle_rx_wc and the code is calls, i don't 
>> see where it uses wc->qp_num. Actually, unless the wc status is not 
>> success, why would you care from which QP you have got this packet?

> To detect stale (unused) connections and remove them.
> I have not pushed this code yet.

So you don't really have a use case which is based on code that can be 
reviewed (or can it be reviewed from your openfabrics GIT?) I understand 
that the logic you suggest comes into play when wc->status is not 
success as i have guessed.

Or.







More information about the general mailing list