Subject: Re: Tweaking NFSv4 to be friendlier to hardware

From: Brent Callaghan <[email-masked]>
Date: Fri, 6 Aug 1999 17:03:40 -0700 (PDT)

Constantine Sapuntzakis writes:
> With network speeds moving to 10 Gb/sec and beyond, it seems
> appropriate to consider some sort of hardware acceleration for NFS. I
> would like to suggest two small changes to v4 to make this easier:
> 
> 1) Eliminate the tag field in COMPOUND4args and COMPOUND4resok.
> 
> The purpose of this tag is not described in the document. I suggest
> that if it were to be maintained, it be made an integer.

The tag has no function within the protocol.  It's just to 
facilitate protocol monitoring and debugging, e.g. it would
be printed by a packet sniffer like tcpdump or snoop. Rather
than enumerate a series of compound ops - the tag string could
be displayed in a summary display, e.g. "lock & read".

If, in the course of protocol development, it turns out that
nobody bothers with it, then we'll remove it.

> 2) Add a length field preceding each component operation and component
> response to allow them to be skipped over

Yes, for something like a DMA engine it would make it a bit
easier to scan a compound request looking for juicy chunks
of DMA-able data.  The downside is that it encumbers every
compound op with an extra 4 bytes and makes XDR encoding
more difficult.  Is the extra complexity really worthwhile ?

I'm worried that we add the length fields - then nobody
ever implements a hardware accelerator.  To my knowledge,
nobody has implemented one yet for NFS v2 or v3, other
than the Presto cards that work at the back-end.

Would it be that much more difficult to configure a hardware
accelerator with protocol knowledge enough to parse a compound
request without the length fields?

	Brent

---

From: Naidu Bollineni <[email-masked]>
Date: Fri, 13 Aug 1999 19:18:17 -0700 (PDT)

> From [email-masked] Fri Aug  6 17:08:29 1999
> To: [email-masked]
> Subject: Re: Tweaking NFSv4 to be friendlier to hardware

> nobody bothers with it, then we'll remove it.

Is this tag string going to end at fixed basic data type boundary(say 4 or 8
byte aligned) /

In the compound request/result, the field following the tag is the opcode/code
fields which are going be u_int type.

How is the client/server going to xdr them ?

Naidu

---

From: Brent Callaghan <[email-masked]>
Date: Wed, 18 Aug 1999 13:57:59 -0700 (PDT)

Constantine Sapuntzakis suggested that a size associated
with each compound operation would make it easier for
a hardware accelerator to locate "interesting" ops
more quickly.  

I had several objections to this:

	- The size count is wasted if no hardware accelerator ever uses it.
	  i.e. added complexity with no benefit.

	- The count would require an extra 4 bytes per compound op.

	- The XDR routines would be more complex through the need
	  to "back patch" the count after the operation args or
	  results were XDR'ed.

One compromise solution might be this:

	The current opcode word uses 32 bits to represent an
	operation.  Since there are currently just 32 operations, only
	the bottom 5 bits of each opcode word are used.  Similarly, in
	a response the status word can have up to 39 error codes. Some
	remaining bits in the word could be used to hold a size count.

	Let's be more generous with the number of opcodes and error
	codes and assign an 8-bit field, i.e. allow up to 256 codes.
	That would leave 24 bits to hold a length field.  If the length
	field counts XDR units (4 bytes) then 24 bits would allow
	lengths up to 2**24 * 4 bytes. Plenty for most ops - reads
	and writes in particular.

	While the use of the opcode/status words for length encoding
	would overcome the space problem. The encoding of these 
	lengths would still burden implementations with the XDR
	overhead in back-patching the length.  One way around this
	would be to make the insertion of the length count optional.
	If the field is zero - then no count is present and the
	hardware can just skip the request.  Since compound ops
	can have zero arguments and/or results, we would need to
	add one to the length count to make a zero length a unique
	encoding for "no value".

Comments ?

	Brent