On Mon, Nov 09, 2009 at 09:44:31AM +0200, Or Gerlitz wrote:
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?
The extra info in
L1. compute source address
L2. issue kernel rdma_bind to source address and resolve device, port,
pkey
L3. issue ACM address (DGID) resolution call using (device, port,
pkey, dest-ip)
makes sense? if yes, what's the need in the address configuration file?
Here is where we're at today:
Jason Gunthorpe wrote:
The extra info in rdma_resolve_addr2 carries the IB specific path information
from the rdma_getaddrinfo module to the kernel for the address pair. The entire
purpose of AF_IB is to let user space tell the kernel it does not want a kernel
side ND and PR query, instead
On Sun, Nov 08, 2009 at 08:25:55AM +0200, Or Gerlitz wrote:
ACM is intended to be a service that's used by the librdmacm to resolve
address mappings and routes. Trying to have ACM use the librdmacm ends up
with a circular dependency. That's the part I'm trying to avoid.
fail-enough, I
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
Sean Hefty wrote:
I wasn't trying to limit how the SA could 'distribute' QoS information to the
end nodes. ACM will obtain QoS information from the SA when it joins its
multicast groups
excellent... still, this is dependent on how the ACM MGIDs are
constructed, I'll take a look on the code.
Before enhancing the rdma-cm to support the full feature set of the IB
CM, something which I personally don't see the actual need for (but I
will be happy to get educated what applications will or can migrate to
rdma-cm once this is implemented), how about trying to allow for reduced
QoS scheme
