> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html