> Even so, the point of passing it into rdma_getaddrinfo is to restrict
> the device rdma_getaddrinfo selects, it doesn't matter that you can get
> back to the PD from the addrinfo if that PD doesn't have the resources
> you need attached to it. Again, I'm thinking from the app perspective
> where juggling multiple PDs isn't really done, and thus multiple
> connections on different HCAs are not supported by the app. This model
> should be supportable without introducing random failures when
> rdma_getaddrinfo returns things that use other devices.
But why select the PD as the restriction, rather than just the device?
If rdma_getaddrinfo calls into a service to obtain some of its information,
then at some point an address must be sufficient. What about just passing in a
device guid as the ai_src_addr?
or, I guess we could add the device to rdma_getaddrinfo:
rdma_getaddrinfo(struct ibv_context *verbs, char *node, char *service,
struct rdma_addrinfo *hints, struct rdma_addrinfo **res);
> - Create the TGT QP on the initiator side and pass its info in the
> private message and do a double QP setup. More complex - does
> rdmacm provide hooks to do this?
I thought about this as well. The librdmacm could steal more of the private
data for this - just giving less to the user when connecting using XRC. Right
now, the rdma_cm doesn't provide anything to help connect XRC QPs, so we can do
what makes the most sense. I still don't know how the apps exchange SRQs,
which is really part of the entire connection process...
- 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
