[openfabrics-ewg] [openib-general] OFED 1.1 release - schedule and features

[Fabian Tillier]

Hi Mike,

On 7/12/06, Michael Krause <krause at cup.hp.com> wrote:
>
> At 09:48 AM 7/12/2006, Jeff Broughton wrote:
>
>> Modifying the sockets API is just defining yet another RDMA API, and we have
>> so many already....
>
> I disagree.  This effort has distilled the API to basically one for RDMA
> developers.  Applications are supported over this via either MPI or Sockets.

There's been a lot of effort to make the RDMA verbs easy to use.  With
the RDMA CM, socket-like connection semantics can be used to establish
the connection between QPs.  The connection establishment is the hard
part - doing I/O is trivial in comparisson.  This verbs and RDMA CM
have nothing to do with MPI.

If an application is going to be RDMA aware, I don't see any reason it
shouldn't just use the verbs directly and use the RDMA CM to establish
the connections.

>    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.

Wait, you want applications to be able to register memory and issue
RDMA operations, but not have to learn about RDMA?  How does that make
sense?

>  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;

For a socket implementation to support RDMA, the socket must have an
underlying RDMA QP.  This means that if you want the application to
not have to be verbs-aware, you can't really get rid of SDP - you're
just extending SDP to let the application have a part in memory
registration and RDMA, while still supporting the traditional BSD
operations.  This is IMO more complex than just letting applications
interface directly with verbs, especially since the SDP implementation
will size the QP for its own use, without a means for negotiating with
the user so that you don't cause buffer overruns.

> it also eliminates the IP cloud that hovers over SDP licensing.   Something
> that many developers and customers would appreciate.

I believe that Microsoft's IP claims only apply to SDP over IB -- I
don't believe SDP over iWarp is affected.  I don't know how the RDMA
verbs moving towards a hardware independent (wrt IB vs. iWarp) affects
the IP claims, but it should certainly make things interesting if a
single SDP code base can work over both IB and iWarp.

- Fab