[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