> Well, that patch is pretty complex and it slows down common case high > speed calls (eg ibv_poll_cq) unless the provider is (fully?) > upgraded. That is something I wanted to see avoided.
The provider does need to support extensions. They don't need to support any extra calls. The cost should really be minimal and goes away as soon as the provider is updated, which I would expect all of them to be before the next release of verbs or OFED. > Plus I don't see that we should be trying to make extended structures > for many of the things in patch 2 (ibv_qp, ibv_srq, ibv_ah, ibv_mr, > ibv_cq, ibv_pd, ibv_mw). Additional functionality for those objects is > better served through new, optional, function entry points than by > allowing the consumer to muck about directl in those structures. Those > structs, in particular, should have been opaque from day 1, IMHO. There is data sharing that's required between verbs and the provider for verbs to do anything useful. We need to add an xrcd to the QP and xrcd, cq, and srq_num to the SRQ. Verbs uses the xrcd's and cq, but the user needs the srq_num. Verbs doesn't allocate the structures, so it can't store anything. Adding a bunch of get/set calls seems worse to me than just placing the items in a structure. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
