Sean Hefty wrote:
From the perspective of IB, the RDMA CM simply defines a specific format to
private data and service ID carried in the IB CM REQ. As long as any use
adheres to that protocol, interoperability won't be an issue.
okay, I just wanted to make sure that the whole thing (ACM + modified
librdmacm + modifed rdma-cm) is applicable AND inter-operable for
AF_INET / PS_TCP applications.
Looking on kernel cma.c format_hdr code it first branches on the address
family and next of the port space.
Going with your proposed flow, I understand that an app call to
rdma_resolve_addr will be broken down to rdma_bind_addr, ACM resolution
of the destination GID and then rdma_set_ib_dest, so things should work
perfect for AF_INET / PS_TCP apps, correct?
The only missing piece here is the route lookup from user space for
applications not specifying a source address in their rdma_resolve_addr
invocation, do you still need help to implement that?
Essentially, the RDMA CM interface would become capable of connecting to any IB
application. (I really haven't thought through the details yet, and the
addition of RDMA_PS_IB shouldn't be part of the initial patch submission.)
fair-enough, I just wanted to make sure with you that AF_IB / PS_IB
aren't tightly coupled with the proposed change and you have clarified that.
The ACM responds based on a configuration file. The ib_acme utility can create
that file using the active IP, pkey, port information of the system, but the
current ACM implementation does not adjust to dynamic changes or detect
misconfigurations or other made up words.
I see. Does the new flow of librdmacm is going to be under new API, eg
rdma_resolve_addr/route_ext or the same API optionally talking to ACM
through some IPC if the ACM daemon is running, or something else?
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
