Subject: Re: Tweaking NFSv4 to be friendlier to hardware

From: David Robinson <[email-masked]>
Date: Fri, 13 Aug 1999 19:13:53 -0700 (PDT)

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

RFC1832 XDR defines that all strings ends on a 4 byte boundary and
is padded as necessary.

See Section 3.11

---

From: Mike Eisler <[email-masked]>
Date: Sat, 14 Aug 1999 06:50:59 -0700 (PDT)

> RFC1832 XDR defines that all strings ends on a 4 byte boundary and

Right.

Which is why I don't understand why its friendlier to hardware to put the
variable length string at the end of the request, than at the front especially
consdiering that therer is varibly length data predicing that, such at the
authentication cred and verifier in the RPC header. I believe IP options are
also variable length.

There's one issue that where V4 might be more hardware friendly
in ways that V3 fell short. Note that RFC 1831 specifies that
everything is aligned on a 4 byte boundary and is padded to a four
byte boundary, even if it as 64 bits long.

I assume that on most operating environments, something like:

	struct foo {
		int64_t x;
		int y;
	};

is actually 128 bits in length and not 96, with a 4 byte pad
after x, or a 4 byte pad after y. XDR though will pack this into
a 96 bit, united, aligned on a 4 byte boundary. If we have:

	struct foobar {
		struct foo A;
		struct foo B;
	};

Then we are guaranteed that either A.x or B.x will be unaligned on a 64 bit
boundary when it is copied into the machine's main machine from the network.
Some machine architectures might permit that, but handle it inefficiently.
Others, don't allow it at all.

This can be mitigated by carefully going through the protocol and reducing
and/or eliminating situations like the "foo" struct above. It seems to me that
unless we are willing to make the make such changes, the suggested tweaks
aren't going to buy much.

	-mre