On Sun, Oct 25, 2009 at 01:32:27PM +0200, Or Gerlitz wrote: > Jason Gunthorpe wrote: > >So why not have a more general, flexible approach? Isolating ACM from > >librdmacm by using AF_IB is a good idea, it keeps them seperate and lets > >ACM and future go where ever. I hope Sean can make it work with the > >rdma_getddrinfo idea, that would completely seperate ACM and librdmacm
> Generally speaking, AF_IB/PS_IB sounds okay to me, even though I am not > clear what applications are going to use it, maybe some examples please? Again, my hope with the rdma_getaddrinfo idea is that apps using that API get *all* the features with no additional code changes. Things like GID addressing, ACM, etc all just exist under the rdma_getaddrinfo API, so the apps don't care. So, any time a *user* wants to use native IB features - APM, user path selection, GID addressing, IB routing, etc - or users that want to work with native IB labels for partitioning, QOS and IB routing. > I don't agree, the only place where librdmacm goes to ACM is to resolve > DGID and a route. This can be done with rdma_getdgidinfo & > rdma_getrouteinfo if you like (maybe you do the implementation?), or I would not be interested in such a poor API as a rdma_getdginfo, rdma_getrouteinfo. Such a design ignores the hard won lessons of IP. Jason -- 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
