> Having looked at implementation issues, it will be much simpler to just, as > you say, > mimic the consumer API -- in kernel space as well.
Yes, in fact I think we might be able to get away with not breaking the user-kernel ABI. If I understand things correctly, XRC QPs do not have an SRQ attached to them, so we could overload the srq_handle member of struct ib_uverbs_create_qp to hold the xrc_domain_handle when creating an XRC QP. Then if we're OK with having create_xrc_srq be a separate operation from create_srq, I think everything else doesn't break the ABI. Does that seem like a good plan? The only ugly thing is making the interface a little fatter than it needs to be with the duplicated create_xrc_srq and create_srq operations; but we save the pain of bumping the ABI and avoid the ugliness of putting generic objects into the driver-specific data (which would force us to export the lookup of XRC objects from the uverbs module, etc). - 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
