On Wed, 24 Aug 2005, Roland Dreier wrote:
> James> You need to consider what makes sense for *both* ib and > James> iwarp. Keep in mind that the correct API will allow a > James> consumer to use ib and iwarp devices transparently. In > James> other words their will be one code path that support both. > > James> If we were to adopt your proposal, the consumer would need > James> to perform unnecessary operations on iWARP. > > No, I think we just need to realize that a perfectly transport neutral > protocol implementation is not achievable. It is achievable. Although the IB and iWARP protocols are different, they can provide the same services to NFS-RDMA. IB is missing one service that iWARP has, namely that nodes can be identified with IP addresses. The ATS mechanism provides this capability for IB networks. If there are better mechanisms that do the same thing, then NFS-RDMA can use them. The important things is not to push this up into the ULPs. The NFS-RDMA protocol is being standardized in the IETF. There is no reason to upset that process. If an additional IB specific protocol is necessary, it should be standardized in the IBTA. > It's unfortunate that kDAPL fooled people by hiding the details of > the wire protocol under a supposedly "neutral API," but the fact is > that mapping an abstract RDMA transport to a real implementation > will always involve arbitrary transport-dependent choices. The kDAPL API *is* transport neutral. This has been demonstrated at several interoperability tests at which the same applications were run on both IB and iWARP. kDAPL isn't the only transport neutral networking API. The Sockets API supports UDP and TCP transports via the same interface. I believe we are very close to reaching agreement on a transport neutral RDMA connection API. Comparing your API proposal to the API that we proposed at the BOF, they are very similar. The most important similarity is that both use IP addressing. The only real point of debate is over how to perform the address translation (IP <-> GID) on IB. I believe we should separate that from the API discussion. _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
