Hal Rosenstock wrote:
(We should be able to pull that from ib_at.)
or sdp_link which has the more temporal netdev references currently :-)
I will look at both. Thanks.
The API is similar to the route
portion of ib_at, but corrects issues with canceling requests.
What are you referring to here ?
It looks like the user can get a callback after cancel returns. This is a
similar problem that we discussed wrt canceling MADs many moons ago. The return
code can be misleading.
The intent is that the CMA will use this service to locate the
proper RDMA device GUID
This is the outgoing device, right ?
correct
and port to use in establishing a connection.
Hopefully, this makes it clearer how I envision address translation wrt
the CMA.
When/if there are multiple paths, how is the selection performed ?
Also, on the passive side, would a rdma_resolve_route also be done or
something else or wouldn't just a path lookup suffice here ? If it is
the latter, is that hidden under the rdma_accept or handled otherwise ?
On the passive side, the source/destination IP addresses are carried in the CM
REQ. The CM provides path records as part of the REQ callback.
What happens if the destination IP address is a local one ? I think
there is some missing code here.
I think there's code in at.c to handle that case that could be re-used.
Also, shouldn't non subnet local destination IP addresses be handled ?
How does that map to the IB subnet? Would it require global routing, or are
non-subnet local addresses a valid configuration on a local IB subnet?
- Sean
_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
