Subject: Re: [nfsv4] I-D ACTION:draft-ietf-nfsv4-rpcrdma-00.txt

From: David Robinson <[email-masked]>
Date: Fri, 29 Oct 2004 18:07:45 -0500

Brent and Tom,

> 	Title		: RDMA Transport for ONC RPC
> 	Author(s)	: B. Callaghan, T. Talpey
> 	Filename	: draft-ietf-nfsv4-rpcrdma-00.txt
> 	Pages		: 30
> 	Date		: 2004-7-2
> 	
> A protocol is described providing RDMA as a new transport for ONC
>    RPC.  The RDMA transport binding conveys the benefits of efficient,
>    bulk data transport over high speed networks, while providing for
>    minimal change to RPC applications and with no required revision of
>    the application RPC protocol, or the RPC protocol itself.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-rpcrdma-00.txt

Some high level comments.

Like Mallikarjun, I found ambiguity in sections 2 and 3 with respect to
the chunking rules that lead to initial confusion.

At first the text implies that anything can be chunked with the
obvious caveats that chunking "short" messages may not be very
efficient. There are some loose statements about handling arrays
but in is never very definitive about which data types may be
chunked and which MUST NOT be chunked.

I would suggest that clarity could be added by explicitly calling
out which data types defined in RFC1832 may be chunked and any
rules that may apply (e.g. MUST inline the length of a variable
length array, how to multi-chunk an array) and which MUST NOT be
chunked (e.g unsigned integer). Additionally I would expect, but
it is not stated, that chunks would be at a minimum one XDR basic
block size (4 bytes) and if chunks would be a multiple of the
basic block size or if not, is any XDR padding implicit or
placed in the inline stream?

An alternative approach for consideration would be to relax the
rules about what could and could not be chunked. Allow any arbitrary
portion of the XDR stream to be chunked regardless of offset or
size. The decoding would simple compare the current position
of the XDR stream and determine if it was in a chunk or inline
and perform the decode from the appropriate place. A common and
sane implementation would usually only chunk arrays so the
logic for arrays would effectively be the same as already proposed
and xdr_int() would usually find its 4 bytes inline. But if
an xdr_int were part of a chunk it would just copy them from its actual
location. This would put a very small burden on the decode
logic to determine where the data actually was, but in reality
the chunking would be almost always the same as the existing
proposal.

One advantage of this approach is that the entire section 5
on large chunkless messages can be removed. There are no
longer cases where a message could not be chunked if desired
so they don't need to be special cased. Now, in the
normal decode of small types like ints they would simply
detect that the data was in a chunk and copy from it instead
of the inline buffer. This would allow messages that contain
both long ranges of many small buffers and large buffers to
both use RDMA. Currently a COMPOUND of an 8KB READDIR
followed by an 8KB READ can either RDMA just the READ,
or create a long message of the full 16KB and copy the READ data.
Using the relaxed approach there could be 2 chunks, one for the
decode of the READDIR pieces and one for ultimate destination
buffer for the READ.

	-David

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4