> Yes, good point. If the other side does not have rsockets then it is not that > straightforward. > > Some thoughts: > > 1. The best option might be if we exchanged an option during > connection setup. This tells the peers if the other side is capable of RDMA. > If it is then one can switch to support of RDMA. > > One obvious area of capability exchange is with TCP option. This requires TCP > extension though. > > Is there any other mechanism to exchange capabilities? > > > 2. In IPoIB, the address resolution returns RC or UD flags. This can allow > one to determine if the remote peer is capabile of RDMA i.e. use of RC but > does not tell us if rsockets is present on the peer. > Can one still attmept an rsockets based connection over RC mode? > > > 3. Use a service discovery mechanism to determine if the remote peer supports > rsockets. This will need to determine if the remote port is enabled; not just > that rsockets is present on the system.
Just to be clear, rsockets has limited fallback support today, mainly targeting the client side of the connection. Another option, which I think ends up being a requirement for iWarp, is to use a port mapper function. But I'd also be willing to live without fallback support on apps that require fork support. Regarding the choices above, I have given thought to introducing a service for supporting rsocket UDP (to handle UDP port to QP mappings). Maybe that would give us the most flexibility to solving this and all future problems. - 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
