[ewg] rdma/cm: revert associating an RDMA device when binding to loopback

Sean Hefty sean.hefty at intel.com
Tue Feb 9 14:20:43 PST 2010


>1. Is this now the recommended way to find all the IP interfaces that support
>RDMA:
>
>- loop over all local IP addresses
>- if 127.0.0.1/8, skip

Include ipv6 in the checks.

>- try to rdma_bind_addr()
>- if it succeeds and verbs ptr is != NULL, it's an RDMA device

The intent is that rdma_bind_addr should bind to an RDMA device as long as the
address isn't a wildcard, so that resource can be allocated.  If an address is
passed into rdma_bind_addr and the call returns success, then verbs ptr 'should'
be set.  (This is the bug that was fixed, then reverted.)

>(I believe Steve Wise proposed adding an API function to just return a list of
>IP addresses of RDMA devices a while back; it was rejected

Not sure why the idea it was rejected.  I can't think of a problem with
returning a list of devices/ports and the corresponding IP addresses.  Although,
I'd expect the implementation to match what you have above.  At the very least
it could reduce code duplication in librdmacm users.

>2. Before Sean backed out the localhost behavior, when you
>rdma_addr_bind(127.0.0.1), what did the id->verbs pointer correspond to?

id->verbs referenced the first device found with an active port, or the first
device if no ports were active.  This behavior was never updated when iwarp was
added to the stack.

Note that this patch reverted the behavior of rdma_bind_addr(127.0.0.1), but
other new functionality was left in.  The result is that rdma_connect(127.0.0.1)
will still work as long as the selected device can support loopback.

- Sean




More information about the ewg mailing list