Hi Mike, On 7/12/06, Michael Krause <[EMAIL PROTECTED]> 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 _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
