<html>
<body>
<font size=3>At 09:48 AM 7/12/2006, Jeff Broughton wrote:<br>
</font><blockquote type=cite class=cite cite="">
<font face="arial" size=2 color="#0000FF">Mike,<br>
</font><font size=3> <br>
</font><font face="arial" size=2 color="#0000FF">The whole purpose of SDP
is to make sockets go faster without having to have the applications
modified. This is what the customers want. I've heard this
time and time again, across a wide spectrum of
customers.</font></blockquote><br>
I am well aware of this. However, Linux / Unix do not support async
communications which severely limits the potential performance benefits
of SDP. When we wrote the SDP specification it was fully understood
that optimal performance is achieved through async
communications. We spent considerable time constructing SDP
to support both synchronous and asynchronous communication paradigms
which there are many applications that would benefit.
Customers want to be able to use RDMA interconnects without recompilation
and through the use of SDP and shared libraries this is certainly
practical to execute. Developers however are not the same as
customers and it is developers who would benefit from the Sockets
extensions and this would in turn benefit customers. <br><br>
<blockquote type=cite class=cite cite="">
<font face="arial" size=2 color="#0000FF">Modifying the sockets API is
just defining yet another RDMA API, and we have so many already....
</font></blockquote><br>
I disagree. This effort has distilled the API to basically one for
RDMA developers. Applications are supported over this via either
MPI or Sockets. It seems rather self limiting to think
the traditional BSD synchronous Sockets API is all the world should be
able to use when it comes to Sockets. Sockets developers could
easily incorporate the extensions into their applications providing them
with improved designs and flexibility without having to learn about RDMA
itself. If the couple of calls necessary to extend this API to
support direct RDMA would allow them to eliminate SDP entirely, well,
that has benefits that go beyond just its all Sockets; it also eliminates
the IP cloud that hovers over SDP licensing. Something that
many developers and customers would appreciate.<br><br>
In the end, this effort could choose to progress Sockets technology and
extend the number of developers and applications that can achieve optimal
performance with only minor knowledge growth or they can live with the
limitations of the BSD Sockets API and either accept performance loss or
be forced to jump through the hoops of using other rather niche or
obscure API to accomplish what is possible with a small number of Sockets
extensions which were defined by people with years of experience
implementing Sockets and working with application developers.<br><br>
Mike<br><br>
<blockquote type=cite class=cite cite=""><font size=3> <br>
</font><font face="arial" size=2 color="#0000FF">-Jeff<br>
</font><font size=3><br>
<dl><hr>
</font>
<dd><font face="tahoma" size=2>From:</b>
openfabrics-ewg-bounces@openib.org
[<a href="mailto:openfabrics-ewg-bounces@openib.org" eudora="autourl">
mailto:openfabrics-ewg-bounces@openib.org</a>] On Behalf Of </b>Michael
Krause<br>
<dd>Sent:</b> Wednesday, July 12, 2006 9:23 AM<br>
<dd>To:</b> Tziporet Koren; Scott Weitzenkamp (sweitzen)<br>
<dd>Cc:</b> OpenFabricsEWG; openib<br>
<dd>Subject:</b> Re: [openfabrics-ewg] [openib-general] OFED 1.1 release
- schedule and features<br>
</font><font size=3><br>
<dd>At 12:59 AM 7/12/2006, Tziporet Koren wrote:<br>
<blockquote type=cite class=cite cite="">
<dd>Scott Weitzenkamp (sweitzen) wrote:<br>
<dd>> For SDP, I would like to see "improved stability"
(maybe you have this <br>
<dd>> in mind under "beta quality"), also how about
"AIO support"? The rest <br>
<dd>> of the list looks good.<br>
<dd>> <br>
<dd>Yes - beta quality means improved stability.<br>
<dd>AIO is not planed for 1.1 (schedule issue). If needed we can add it
to 1.2</blockquote><br>
<dd>Would be nice if people thought about implementing the Sockets API
Extensions from the OpenGroup. They provide explicit memory
management and async communications which will allow SDP performance to
be fully exploited. The benefits go beyond what is found in
AIO or on other OS such as Windows. If one were to extend slightly
to have explicit RDMA Read and Write from the Sockets API, then it would
be quite possible to eliminate SDP entirely for new applications leaving
SDP strictly for legacy Sockets environments.<br><br>
<dd>Mike<br><br>
<br>
<blockquote type=cite class=cite cite="">
<dd>Tziporet<br><br>
<dd>_______________________________________________<br>
<dd>openib-general mailing list<br>
<dd>openib-general@openib.org<br>
<dd>
<a href="http://openib.org/mailman/listinfo/openib-general" eudora="autourl">
http://openib.org/mailman/listinfo/openib-general</a><br><br>
<dd>To unsubscribe, please visit
<a href="http://openib.org/mailman/listinfo/openib-general" eudora="autourl">
http://openib.org/mailman/listinfo/openib-general</a>
</blockquote></font>
</dl></blockquote></body>
</html>