Subject: RE: Tweaking NFSv4 to be friendlier to hardware

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 9 Aug 1999 08:58:49 -0700

> 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".

"The tag has no function within the protocol", would seem to 
me to be an argument to delete it.  Things that have no function
or very little function and do have a downside should be removed
unless someone makes a very strong case for them.

This is something that right now exists in the RPC definition 
file but nowhere else in the spec.  It is both in the request
and the response.  Is the server supposed to copy the tag
from the request to the response?  One supposes so but there
is no indication in the spec.  I say that if it isn't important
enough to devote the effort to describe, it isn't important
enough to keep.  

> 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?

In the case of hardware, almost certainly.

V4 has more variable length stuff than v3 (e.g. attribute
model).  I'm even worried about the greater cpu cost to parse
this stuff in a software implementation.  Overall performance
of the protocol can be better, assuming that we make other 
improvements (like better caching).

Hardware implementations tend to be different.  You can add 
complexity for a while and at some point, things can get 
either a *lot* more expensive or just plain impossible.

This specific change (length of each op) might help software
implementations

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 09 Aug 1999 11:08:26 -0500

> enough to devote the effort to describe, it isn't important

I can certainly describe it in the draft so that shouldn't be a 
problem. :-)  I will reiterate Brent's suggestion.  Let's get
through the bake-off in October and see if anyone finds this valuable.
If not, then it should be removed from the definition.

Spencer