Subject: Tweaking NFSv4 to be friendlier to hardware

From: Constantine Sapuntzakis <[email-masked]>
Date: Fri, 6 Aug 1999 14:36:42 -0700 (PDT)

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.

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

Some NFS optimizations may not need to or be able to parse all
component operations or responses. A length field will allow these
optimizations to skip over components that do not interest them.

For example, a DMA engine may be interested in copying the data
contents of WRITE operations to special, page-aligned buffers.
Ultimately, software will determine whether the write gets committed
(after checking permissions, etc.). Potentially this data will have to
be thrown away (e.g. if one of the operations preceeding the write was
invalid) but that is expected to be the uncommon case.

This DMA engine need not be interested in other operations, like
LOOKUP, so it should not need to parse those requests.

To summarize:

struct COMPOUND4args {
    op    oplist<>;
};

struct op {
    uint32  len;
    opunion op;
};

struct results {
    uint32 len;
    resultdata result;
}

struct COMPOUND4resok {
    results  results<>;
};

-Costa

---

From: Constantine Sapuntzakis <[email-masked]>
Date: 09 Aug 1999 13:30:29 -0700

Based on the suggestion of Mike Eisler and other feedback, here is a
revised proposal:

typedef opaque message<>;

struct COMPOUND4args {
	message	oplist<>;
	utf8string tag;
};

struct COMPOUND4resok {
	message data<>;
	utf8string tag;
};

For the compound4args, the opaque message type contains an op. For
COMPOUND4resok, it contains a resultdata.

The tag field is now at the back of the request, where it can safely
be ignored by a simple parser.

-Costa