[openib-general] RDMA connection and address translation API

[Caitlin Bestler]

-----Original Message-----
From: openib-general-bounces at openib.org
[mailto:openib-general-bounces at openib.org] On Behalf Of Roland Dreier
Sent: Wednesday, August 24, 2005 2:03 PM
To: Tom Tucker
Cc: openib-general at openib.org
Subject: Re: [openib-general] RDMA connection and address translation API



By the way, as far as I can tell, there is NO formal documentation of the
NFS-RDMA wire protocol.  The current draft (draft-ietf-nfsv4-rpcrdma-01.txt)
simply says:

     This protocol is designed to function with equivalent semantics
     over all appropriate RDMA transports.  In its abstract form, this
     protocol does not implement RDMA directly. [...]  It therefore
     becomes a useful, implementable standard when mapped onto a
     specific RDMA transport, such as iWARP [RDDP] or Infiniband [IB].

     [...]

     In setting up a new RDMA connection, the first action by an RPC
     client will be to obtain a transport address for the server.  The
     mechanism used to obtain this address, and to open an RDMA
     connection is dependent on the type of RDMA transport, and outside
     the scope of this protocol.

So it seems perfectly reasonable and acceptable for the mapping of NFS-RDMA
onto IB to specify that the source and destination IP addresses for an IB
connection are placed in the CM private data.
This seems much easier than trying to turn ATS into an IETF standard.

 - R.

<caitlin>
NFS over RDMA was intended to be implemented using DAPL in a transport
neutrall way. Now having the transport layer *add* data before the
private data is legitimate for any specific transport. It would just
have to be defined independently of openib and linux.

Basically, any solution that allows NFS over RDMA to be coded with
the *same* set of kDAPL calls to listen/connect/accept/reject would
be compliant with the intent -- as long as the mapping to wire protocols
was straight-forward and allowed non-kDAPL implementations. For example,
mapping the DAPL private data to the IETF MPA Request/Reply frame 
Private Data certainly qualifies as "straight forward".
</caitlin>