On Tue, 28 Jun 2005, Roland Dreier wrote:
James> First off, here [are the] requirement we are trying to satisfy: James> On the passive side of a connection, a InfiniBand kDAPL James> provider must determine a source IB address for an James> InfiniBand connection request. This information can be James> obtain by a kDAPL consumer either in the James> DAT_CONNECTION_REQUEST_EVENT's dat_cr_arrival_event_data or James> dat_cr_query()'s dat_cr_param structure. James> By interoperable, we mean that the solution must not James> introduce a non-standard protocol or force ULPs using kDAPL James> to perform special operations when using an InfiniBand James> network. Since these two points are mutually contradictory -- the IB communication management protocol does not carry enough information for a connection request to be mapped uniquely back to a source address -- we need to figure out which one to drop. I would argue in favor of the solution selected by SDP: when defining the binding of an abstract protocol to the IB transport, put the source and destination IP addresses in the IB-specific connection setup messages.
I want to make sure I understand your solution. If we choose this option:
- IB services (both kernel and user space) will be configured using IP addresses. By IB services, I'm referring to protocols that are layered directly on top of the InfiniBand protocols (e.g. SDP, NFS-RDMA, iSER, etc.). - IB services will resolve IP addresses to IB addresses using IPoIB ARP (all IB nodes would be required to support IPoIB). - each IB service would place appropriate IP address information in its protocol messages Did I get it right? james _______________________________________________ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
