Sean – thanks for the feedback. Reg the XRC semantics and object model: - XRC domain object allows many to many mappings where multiple XRC TGT QPs and multiple XRC SRQs can be mapped to each other, thus a notion of domain needs to be creates to define such group. With RSS/TSS we only have many to one mapping where child QPs are mapped directly to single parent. The RSS indirection table defines which child QP will receive the ingress, there’s no remote mapping control like in the XRC case where the initiator defines the destination receive queue. - The XRC protection domain attribute was established to allow verification of a match between the destined XRC TGT QP and the targeted XRC SRQ, with RSS/TSS we don’t enforce such a match. >From the above reason’s we didn’t find justification for creating yet another new object – RSS/TSS domain.
Reg ib_qp_init_attr and ib_qp_type, since RSS/TSS child/parent attributes can be defined for multiple QP types (today IB_QPT_UD and IB_QPT_RAW_PACKET), we believe it is cleaner to have another attribute of ib_qpg_type. Reg ib_open_qp() and sharing the parent QP across multiple process, currently we don’t support it, user mode API will provide RSS/TSS parent QP creation and children in user space in the same process. Having said that, we may add such support in future and current scheme allows such future expansion where RSS/TSS parent QP may be defined as shared, where in such case it will be allocated in kernel using the open_qp semantics and may use shared protection domain to do so. Tzahi On Tue, Jun 12, 2012 at 11:44 PM, Hefty, Sean <[email protected]> wrote: >> Do you have something more specific re how to actually align (say) the >> RSS QP group into the framework used by XRC? > > Not really. That was more of a conceptual statement regarding the design. > The operation, particularly on the receive side, just seems similar. > > I don't think we should force a fit if it doesn't, but what's missing from > the XRC framework to support RSS? > > I guess more specifically, if I look at the changes to ib_verbs.h, can we > avoid the changes to ib_qp_init_attr and ib_qp? I.e. why can't the qp_type > indicate the type of group, or why couldn't ib_open_qp() be used? Should the > associated QPs share some sort of common protection domain, like an XRCD, to > provide some security on sharing the underlying QP across processes? > -- > 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 -- 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
