I think it would be more accurate to state that DAPL requires the 128-bit "IA Address space" to be administratively subdivided so that each "subnet" unambiguously translates to a specific IA reached network and that translation of the "IA Address" into and from that network's wire protocol is not visible to the DAT Consumer.
ATS is indeed *one* solution for doing so. Adding RARP to IPoIB would make for another solution. Direct translation is also a valid solution for IPv6 compatible network IDs. So with this wealth of options available, do you agree that there is no reason to elevate any of these issues to being visisble to a transport neutral application? -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roland Dreier Sent: Wednesday, August 24, 2005 2:31 PM To: James Lentini Cc: [email protected] Subject: Re: [openib-general] RDMA connection and address translation API Roland> No, I think we just need to realize that a perfectly Roland> transport neutral protocol implementation is not Roland> achievable. It's unfortunate that kDAPL fooled people by Roland> hiding the details of the wire protocol under a supposedly Roland> "neutral API," but the fact is that mapping an abstract Roland> RDMA transport to a real implementation will always Roland> involve arbitrary transport-dependent choices. Further: if we would be willing to say that transport-neutral protocols must use a "kDAPL wire protocol," then there's no problem in defining that wire protocol to put the source and destination IP address somewhere in the CM private data. The current "kDAPL wire protocol" happens to use ATS to try and achieve this (although it doesn't handle the multi-homed case), but that is no more and no less of an arbitrary protocol design choice. So in a nutshell, my objection to using ATS is that it is an arbitrary design choice that doesn't work as well as other equally valid choices. - R. _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
