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