RE: [PATCH 2/2] rdma/cm: allow user to specify IP to DGID mapping

Sean Hefty
2009-10-09T00:24:48Z

>However, I don't manage to follow on your port space discussion with
>Jason. Some apps may have client in user space and server in the
>kernel or vise versa. I wouldn't tie PS_IB or a like with ACM. The ACM
>ARP replacement protocol will reply only if the ip address specified
>in the broadcast request is an ip of this host on that pkey and a port
>connected to that fabric, correct?

Nothing in any of this would require the use of a specific method for path
resolution. The rdma_resolve_route() API does not impose any such limitation.
The problem is that the kernel implementation does. The purpose of these
patches is to allow user space to perform the resolution using whatever
mechanism it chooses, and convey that to the kernel. rdma_resolve_addr() is
similar. Basically treat any mention of ACM in this discussion as an example.

>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.

If an application uses RDMA_PS_TCP, they would expect a 16-bit port number
mapped appropriately to the 64-bit service id. The concept of adding RDMA_PS_IB
would be to expose the full 64-bit service id. 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.)

As for your ACM specific questions - 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.

- Sean