[Rdma-developers] Re: [openib-general] OpenIB and OpenRDMA: Convergence on common RDMAAPIs and ULPs for Linux

[Talpey, Thomas]

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.