<html>
<body>
<font size=3>At 03:49 PM 7/12/2006, Fabian Tillier wrote:<br>
<blockquote type=cite class=cite cite="">Hi Mike,<br><br>
On 7/12/06, Michael Krause <krause@cup.hp.com> wrote:<br>
<blockquote type=cite class=cite cite=""><br>
At 09:48 AM 7/12/2006, Jeff Broughton wrote:<br><br>
<blockquote type=cite class=cite cite="">Modifying the sockets API is
just defining yet another RDMA API, and we have<br>
so many already....</blockquote><br>
I disagree. This effort has distilled the API to basically one for
RDMA<br>
developers. Applications are supported over this via either MPI or
Sockets.</blockquote><br>
There's been a lot of effort to make the RDMA verbs easy to use.
With<br>
the RDMA CM, socket-like connection semantics can be used to
establish<br>
the connection between QPs. The connection establishment is the
hard<br>
part - doing I/O is trivial in comparisson. This verbs and RDMA
CM<br>
have nothing to do with MPI.<br><br>
If an application is going to be RDMA aware, I don't see any reason
it<br>
shouldn't just use the verbs directly and use the RDMA CM to
establish<br>
the connections.</font></blockquote><br>
What's your point? It seems you are in agreement that there is a
single RDMA API that people can use.<br><br>
<br>
<blockquote type=cite class=cite cite="">
<blockquote type=cite class=cite cite=""><font size=3> It
seems rather self limiting to think the traditional BSD synchronous<br>
Sockets API is all the world should be able to use when it comes to
Sockets.<br>
Sockets developers could easily incorporate the extensions into
their<br>
applications providing them with improved designs and flexibility
without<br>
having to learn about RDMA itself.</blockquote><br>
Wait, you want applications to be able to register memory and issue<br>
RDMA operations, but not have to learn about RDMA? How does that
make<br>
sense?</font></blockquote><br>
The Sockets API extensions allow developers to register
memory. That has been a desire by many when it comes to SDP
or copy avoidance technology as it optimizes the performance path by
eliminating the need to do per op registration. For many
applications which already known working sets, they can use this to
enable the OS and underlying infrastructure to take advantage of this
fact to improve performance and quality of the solution. The
extensions provide the async communications and event collection
mechanisms to also improve performance over the rather limiting select /
poll supported by Sockets today.<br><br>
It currently does not support explicit RDMA but it is rather trivial to
add such calls and remove the need to interject SDP if
desired. The benefits of such new API extensions are
there for those that want to eliminate one more ULP with its unfortunate
IP cloud over head.<br><br>
<br>
<blockquote type=cite class=cite cite="">
<blockquote type=cite class=cite cite=""><font size=3> If the couple
of calls necessary to<br>
extend this API to support direct RDMA would allow them to eliminate
SDP<br>
entirely, well, that has benefits that go beyond just its all
Sockets;</blockquote><br>
For a socket implementation to support RDMA, the socket must have an<br>
underlying RDMA QP. This means that if you want the application
to<br>
not have to be verbs-aware, you can't really get rid of SDP - you're<br>
just extending SDP to let the application have a part in memory<br>
registration and RDMA, while still supporting the traditional BSD<br>
operations. This is IMO more complex than just letting
applications<br>
interface directly with verbs, especially since the SDP
implementation<br>
will size the QP for its own use, without a means for negotiating
with<br>
the user so that you don't cause buffer
overruns.</font></blockquote><br>
Please take a look at the API extensions. I never stated that
one gets rid of SDP unless one adds the RDMA-explicit calls.
<br><br>
As for complexity, well, the goal is to extend to Sockets developers the
optimal communication paradigm already available on OS such as Windows
without having to leave with the same unfortunate constraints imposed by
the OS. The same logic applies to extending the benefits derived
from MPI which supports async communications as well as put / get
semantics which would be analogous to the additional RDMA interfaces I
referenced. <br><br>
I find it strange that people would argue against improving the Sockets
developer's tool suite when the benefits are already proven elsewhere
within the industry and even within this open source effort. Giving
the millions of Sockets developers the choice of a set of extensions that
work over both RDMA and traditional network stacks seems like a no
brainer. Trying to force them to use a native RDMA API even if
semantically similar to Sockets seems like a poor path to pursue.
Leave the RDMA API to the middleware providers and those that need to be
close the metal. <br><br>
<br>
<blockquote type=cite class=cite cite="">
<blockquote type=cite class=cite cite=""><font size=3>it also eliminates
the IP cloud that hovers over SDP licensing. Something<br>
that many developers and customers would appreciate.</blockquote><br>
I believe that Microsoft's IP claims only apply to SDP over IB -- I<br>
don't believe SDP over iWarp is affected. I don't know how the
RDMA<br>
verbs moving towards a hardware independent (wrt IB vs. iWarp)
affects<br>
the IP claims, but it should certainly make things interesting if a<br>
single SDP code base can work over both IB and
iWarp.</font></blockquote><br>
SDP is SDP and it isn't just restricted to IB. I'll leave it
to the lawyers to sort it out but having a single SDP with minor code
execution path deltas for the IB-specifics isn't that hard to
construct. It has been done on other OS already.<br><br>
Mike<br><br>
</body>
</html>