Jason Gunthorpe wrote:
The entire point of the rdma_getaddrinfo + AF_IB is to avoid hacking up
librdmacm for every address lookup/cache scheme someone invents
the entire simple point I am trying to make is that rdma_getaddrinfo +
AF_INET is doable, is simple and is needed to keep up the essence of the
rdma-cm. I don't see how AF_IB buys anything to anyone that but if you
want to push it up as long as AF_INET is first and most
supported/interoperable future/present go and add your bits. As you
indicated the route lookup I was mentioning could be done in
rdma_addrinfo, sure with &res including both source and destination
addresses. No rdma_resolve_addr2 is needed the one that exists now has
source addresses specified, I don't see that extra info is needed for
AF_INET that was resolved with rdma_getaddrinfo is this AF_IB specific?
I don't see why the app should bother on calling rdma_getaddrinfo, it
can be done by librdmacm with rdma_getaddrinfo having multiple modules
as you suggested. I am in favor of the approach suggested by Sean of
librdmacm either doing its native flow or under environment variable
doing an alternative flow, where your suggestion not to have the 2nd
flow being tightly coupled with ACM, e.g through using get_addrinfo
abstraction and friends makes sense (yes!)
Or.
--
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
