<html>
<body>
<font size=3>At 03:14 PM 10/12/2005, Caitlin Bestler wrote:<br>
<blockquote type=cite class=cite cite=""> <br><br>
> -----Original Message-----<br>
> From: openib-general-bounces@openib.org <br>
>
[<a href="mailto:openib-general-bounces@openib.org" eudora="autourl">
mailto:openib-general-bounces@openib.org</a>] On Behalf Of Sean
Hefty<br>
> Sent: Wednesday, October 12, 2005 2:36 PM<br>
> To: Michael Krause<br>
> Cc: openib-general@openib.org<br>
> Subject: Re: [openib-general] [RFC] IB address translation using
ARP<br>
> <br>
> Michael Krause wrote:<br>
> > 1. Applications want to use existing API to identify remote
<br>
> endnodes / <br>
> > services.<br>
> <br>
> To clarify, the applications want to use IP based addressing <br>
> to identify remote endnotes. The connection API is under
development.<br>
> <br><br>
<br>
No, I think Mike's comment was dead on. Applications want to<br>
use the existing API. They want to use the existing API even<br>
when the API is clearly defective. Note that there are several<br>
generations of host-resolution APIs for the IP world, with the<br>
earlier ones clearly being heavily inferior (not thread safe,<br>
not IPv4/IPv6 neutral, etc). But they have not been eliminated.<br><br>
Why, because applications want to use the existing API.<br><br>
If application developers were rationale and totally open to<br>
adopt new ideas instantly then the active side would ask to<br>
make a connection to a *service*, not to a host with a service<br>
qualifier.<br><br>
A new API may be under development to meet new needs. But keep in<br>
mind that the application developers expect it to be as close to<br>
what they are used to as possible, and will grumble that it is<br>
not 100% compatible. </font></blockquote><br>
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. <br><br>
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).<br><br>
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.<br><br>
Mike<br><br>
</body>
</html>