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?
Attempting to bake it into AF_INET means that librdmacm, possibly the kernel
and maybe even the apps need to be contaminated with ACM specific code, and
that just doesn't seem desirable to me. What happens when someone invents BCM
or CCM? More mess
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
with ACM (later BCM, CCM) plugin used by librdmacm or by calls from
librdmacm to ACM. But in any case, the kernel code nor the app will not
be contaminated.
Or.
--
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
