> -----Original Message-----
> From: [EMAIL PROTECTED]
> [ mailto:[EMAIL PROTECTED]] On Behalf Of Sean Hefty
> Sent: Wednesday, October 12, 2005 2:36 PM
> To: Michael Krause
> Cc: openib-general@openib.org
> Subject: Re: [openib-general] [RFC] IB address translation using ARP
>
> Michael Krause wrote:
> > 1. Applications want to use existing API to identify remote
> endnodes /
> > services.
>
> To clarify, the applications want to use IP based addressing
> to identify remote endnotes. The connection API is under development.
>
No, I think Mike's comment was dead on. Applications want to
use the existing API. They want to use the existing API even
when the API is clearly defective. Note that there are several
generations of host-resolution APIs for the IP world, with the
earlier ones clearly being heavily inferior (not thread safe,
not IPv4/IPv6 neutral, etc). But they have not been eliminated.
Why, because applications want to use the existing API.
If application developers were rationale and totally open to
adopt new ideas instantly then the active side would ask to
make a connection to a *service*, not to a host with a service
qualifier.
A new API may be under development to meet new needs. But keep in
mind that the application developers expect it to be as close to
what they are used to as possible, and will grumble that it is
not 100% compatible.
This all comes down to economics which is why some ULP such as SDP are created. Let's examine SDP for a moment. The purpose of SDP to enable synchronous and asynchronous Sockets applications to transparently run unmodified over a RDMA capable interconnect. Unmodified means no source code changes and no recompile required (this is possible if the Sockets library is a shared library and dynamically linked). The first part of unmodified means that the existing address / service resolution API calls work (further, no change to the address family, etc. is required to make this work either). Hence, pick any of the get* API calls that are in use today and they should just work.
How does this work? The SDP implementation takes on the burden for the application developer. For iWARP, there really isn't anything special that has to be done as these calls all should provide the necessary information. The port mapper protocol would be invoked which would map to the actual RDMA listen QP and target RNIC. For IB, there is some additional work both in using SID as well as resolving the IP address to the IB address vector but the work isn't that hard to implement (we know this because this has all been implemented on various OS within the industry). The same will be true for NFS/RDMA and iSER - again all use the existing interfaces to identify the address / service and map to an address vector (and again, all of this has been implemented on various OS within the industry).
The above makes ISV and customers very happy as they can take advantage of RDMA technologies without having to go through the lengthy and expensive qualification process that comes when any application is modified / recompiled. This keeps costs low and improves TTM. As for the RDMA connection API, that is simply attempting to abstract to a common interface that any ULP implementation can use to access either iWARP or IB. The RDMA connection API should not be viewed as something end application developers will use but towards middleware developers. This allows everyone to use IP addresses, port spaces, etc. through the existing application API while allowing RDMA to transparently add some intelligence to the process and eventually enable new capabilities like policy management (e.g. how best to map ULP QoS needs to a given path, service rate,etc.) without permuting everything above. Keeping things transparent is best for all. Attempting to require end application developers to modify their code will result in slower adoption and reduced utilization of RDMA technologies within the industry. It really is all about economics and re-using the existing ecosystem / infrastructure.
Mike
_______________________________________________ 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
