> yes, this was one idea (earlier one that is a new QP type eg > IB_QPT_UD_BML) and the thing is that we would be happy to get your > take on how can this be done with minimum pain regarding ABI issues > both up towards libibverbs consumers and down towards ib_uverbs.
Sorry, I don't have a magic solution for you. To minimize pain about ABI I think the only thing to do is minimize ABI changes. > Actually, looking on the XRC patch set, as it adds new QP type anyway, > IB_QPT_UD_BML might turn to be the simplest way here, but its not > general enough as moving forward, people were talking on other create > flags they want to use from user space (low latency QP, etc) If a QP creation flag works for XRC then I would prefer not to add more QP types I guess. One of the ways that the QP creation flags were originally sold to me was that XRC needed them anyway. So I'm a bit confused about where things have ended up. > Among other things, the XRC patch series adds the > "ibv_create_xrc_rcv_qp" new verb to libibverbs, so my thought here > was that a new way X to create QPs is added, and we want a new way Y > for the block multicast loop. So maybe we can form a framework Z for > creating QPs other then the old one. Alternatively its possible for > the create_qp_with_create_flags verb (and other verbs we want to add > such as cq_modify_moderation_params) to just live next to the new > verbs added to libibverbs in the new ibv_xrc_ops structure which is > added for the verbs context. I don't want to add both an XRC-specific mechanism and a more general mechanism that XRC could have used but doesn't. So yes the "framework Z" approach that works for both seems like the best way forward. - R. _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
