Thomas> As I said - I am not attached to ATS. I would welcome an
Thomas> alternative.
Sure, understood. I'm suggesting a slight tweak to the IB wire
protocol. I don't think there's a difference in the security
provided, and carrying the peer address in the CM private data avoids
a lot of the conceptual and implementation difficulties of ATS.
Thomas> But in the absence of one, I like what we have. Also, I do
Thomas> not want to saddle the NFS/RDMA transport with carrying an
Thomas> IP address purely for the benefit of a missing transport
Thomas> facility. After all NFS/RDMA works on iWARP too.
I'm not sure I understand this objection. We wouldn't be saddling the
transport with anything -- simply specifying in the binding of
NFS/RDMA to IB that certain information is carried in the private data
fields of the CM messages used to establish a connection. Clearly
iWARP would use its own mechanism for providing the peer address.
This would be exactly analogous to the situation for SDP -- obviously
SDP running on iWARP does not use the IB CM to exchange IP address
information in the same way the SDP over IB does.
Actually, SDP on iWARP uses the SDP port mapper protocol to comprehend the IP address / port tuples used on both sides of the communication before the connection is established (this protocol could be used by any mapping service since it is implemented on top of UDP so could be re-used by other subsystems like NFS. The TCP transport then connects normally and one can ask it for the IP address / port tuple that is really being used. Port mapper may be viewed as akin to the SID protocol defined for IB. The SDP hello is then exchange in byte stream as opposed to IB CM.
The port mapper supports both centrally managed and distributed usage models, supports the ability to return diff IP address than requested, support multiple IP addresses per port, etc. One can construct a very flexible infrastructure that supports nearly any type of mapping one desires to same or different hardware or endnodes. It is fairly light weight and can support caching of data for a period of time or even a one-shot connection attempt.
Mike
_______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
