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

[Michael S. Tsirkin]

> >>> 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?

OK, but how does this refer to the use case description?

> > 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.

And that's exactly what IPoIB CM does.

> >> 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?)

Well, I did note the patch is untested.
I'm testing the code in question, and plan to push to openfabrics RSN.
I'll post a patch as well.

> I understand 
> that the logic you suggest comes into play when wc->status is not 
> success as i have guessed.

No, I want to have an LRU list of pages.

-- 
MST