> > If a CM REQ actually gets to the remote side, it could be rejected as an > invalid GID, and the client could retry the request. > > Retrying the request is practically calling > > 1. rdma_resolve_addr > 2. rdma_resolve_route > 3. rdma_connect
Yep - the entire setup is broken. If the wrong remote GID was resolved, then the wrong local GID _may_ have been selected. There's no easy guaranteed recovery here. > where step #1 would get wrong GID from the client arp cache and hence > step #3 would result in a reject and so on... > I am starting to think that the rdma address resolution must not make > use of the arp cache, or at least provide applications > the API to dictate that ARP request must be sent, how this sounds? Clients should not be made aware of how the resolution was done. The RDMA CM needs to abstract that problem. Alternate mechanisms may be usable, but there aren't exactly a whole lot of options available. The client could use native IB addressing at this point if it does not want to rely on address translation. - 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
