At 03:36 AM 6/1/2005, Christoph Hellwig wrote: >kDAPL is supposed to serve two needs: > (1) provide an unified API for different RDMA transports > (2) provide various higher level helpers >... >For (1) doing a proper RDMA stack should solve thing, and the discussion >how to do it is already ongoing on this list. Once we have proper RMDA >stack that part of KDAPL isn't needed at all anymore.
I certainly agree, and have said so before, that if there is a portable layer (verbs or otherwise) which allows me to have a single NFS module working over both IB and iWARP, then kDAPL is not architecturally necessary. The verbs API however, isn't it. The current NFS/RDMA client, over kDAPL, is 3.6KLOC, on the order of the same amount of code as the sockets NFS: about 1800 lines for connection management and transport handling, about 800 for marshalling to and from RPC, and the rest managing the RPC's themselves. This is a HUGE advantage, because it means none of the RDMA complexity is in the RPC or NFS modules. In fact, the NFS module is completely unchanged (same binary). Which is exactly how want it! So, again, I'm happy to use another RDMA API. But the top-level requirements are: - must enable single upper layer implementation (one RPC/RDMA module) - must perform equally well for all transports - must not expose needless complexity - must exist :-) I think kDAPL already is such a thing. When the OpenIB kDAPL starts to work, we'll run the NFS/RDMA client on it the next day. BTW the Linux NFS/RDMA server (also on kDAPL) is accepting connections at CITI, now moving on to actually executing RPCs. Tom. _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
