RE: [PATCH] link-local address fix for rdma_resolve_addr

Sean Hefty
2009-10-21T23:58:02Z

>$ ip route get 10.0.0.11 from 192.168.122.1
>local 10.0.0.11 from 192.168.122.1 dev lo
> cache <local> mtu 16436 advmss 16396 hoplimit 64
>
>(192.168.122.1 is bound to a different device on my system than
>10.0.0.11)
>
>The new case trips the if == loopback and does
>rdma_translate_ip(10.0.0.11)
>
>The old case does rdma_translate_ip(192.168.122.1)
>
>I don't think this is a significant difference, both behaviors are
>reasonable choices and the code/complexity savings are worth it, IMHO.
>[Alternatively, I suppose one could call rdma_translate_ip(rt->rt_src)
>and if that fails then do rdma_translate_ip(dst_in) but why bother?]

I agree this usage case is weird, but I'm still not sure about the patch. If
the destination service is listening on 10.0.0.11, then the listen is bound to a
different gid than the source gid that we're trying to connect from. The
src_dev_addr and dst_dev_addr need to reflect this, so that a PR gives us a path
that routes the CM REQ correctly.

- Sean