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

[Sean Hefty]

>The local loopback case uses PRs?

Yes - the rdma cm makes no distinction when resolve route is called.  It does a
PR query.

>Even so, it still seems OK to me:
>
>Path:
> addr4_resolve_remote
>  $ ip route get 10.0.0.11 from 192.168.122.1
>    local 10.0.0.11 from 192.168.122.1 dev lo
>  srcIP = 192.168.122.1
>  rdma_translate_ip(dst_ip = 10.0.0.11)
>   rdma_copy_addr("eth0");
>    src_dev_addr = eth0.dev_addr  (ie GID of 10.0.0.11)
>  memcpy(dst_dev_addr = src_dev_addr) (ie GID of 10.0.0.11)
>
>So everthing is bound to the GID of 10.0.0.11 which matches the listen
>of 10.0.0.11, which seems OK.

The source could have called rdma_bind_addr(192.168.122.1) prior to calling
rdma_resolve_addr().  (DAPL does this.)  This would have returned a different
RDMA device than binding to 10.0.0.11.  The client app could have allocated
resources on that device, but the CM REQ will carry the gid/lid of the other
device.  The endpoints won't be able to communicate.

Yes, it's weird, and may not be optimal, but if a source address is explicitly
given, then its mapping to a specific RDMA device should be honored.

- Sean