I think it's good idea to support both usage models.
Regards,
Pasha.
>> Things only get complicated when the domain-allocator process allocates a
>> single domain and simply
>> uses that single domain for all jobs (i.e., the domain is never de-allocated
>> for the lifetime of the
>> allocating process, and the allocating process is the server for all jobs).
>
> 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.
>
> - Sean
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
