Re: [RFC] XRC upstream merge reboot

[Jack Morgenstein <jackm-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>]

On Thursday 11 August 2011 01:20, Hefty, Sean wrote:
> To help with OFED feature level compatibility, I'm in the process of adding a new call to ibverbs:
> 
> struct ib_qp_open_attr {
>         void (*event_handler)(struct ib_event *, void *);
>         void  *qp_context;
>         u32    qp_num;
> };
> 
> struct ib_qp *ib_open_qp(*xrcd, *qp_open_attr);
> 
> This provides functionality similar to ib_reg_xrc_recv_qp().  It allows any process within
> the xrcd to modify the tgt qp and receive events. 
> Its use is not required, so we can support both usage models. 
> 
> I believe we can define this generic enough that it could eventually be used
> to share other QP types among multiple processes, though more infrastructure would be needed. 
> 
Hi Sean,
Sorry for no reply until now -- I was on vacation for 2 weeks, and got back to work only today.

I am a bit concerned here.  In the current usage model, target QPs are destroyed when their reference count goes to zero
(ib_reg_xrc_recv_qp and ibv_xrc_create_qp increment the reference count, while ib_unreg_xrc_recv_qp decrements it).
In this model, the TGT QP user/consumer does not need to know if it is the last user of the QP (and therefore should
destroy it).  The QP simply gets destroyed when no one is left using it.

In your proposed model, it looks like the last TGT QP user needs to know that it is the last user and must therefore destroy
the TGT QP (rather than the QP being destroyed automatically as the result of the ref count going to zero).

Am I correct?

(Or does every user -- both the creator and the caller of ib_open_qp do an ib_destroy_qp() -- and the destroy actually
occurs when no users who did open/create remain?).

-Jack
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html