>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
_______________________________________________
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
