[openib-general] [RFC] IB address translation using ARP

[Michael Krause]

At 03:14 PM 10/12/2005, Caitlin Bestler wrote:
>
>
> > -----Original Message-----
> > From: openib-general-bounces at openib.org
> > [mailto:openib-general-bounces at openib.org] On Behalf Of Sean Hefty
> > Sent: Wednesday, October 12, 2005 2:36 PM
> > To: Michael Krause
> > Cc: openib-general at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20051013/20892c21/attachment.html>