Re: [nfsv4] Review of draft-ietf-nfsv4-rfc5667bis-09

[Chuck Lever <[e-mail]>]

> On Apr 27, 2017, at 7:38 AM, karen deitke <[e-mail]> wrote:
> 
> "However, implementations have practical limits on the number of
>  chunks_or_  _segments_  they are prepared to process in one of these
>  lists."
> 
> Agreed, but what is the practical limit?

There has to be a limit based on rsize/wsize constraints, page
size, client memory registration mode, the maximum size of
transport headers, and so on.

"Implementations have practical limits" means implementers
get to choose to support only a certain number of segments or
chunks to keep their implementations as simple as possible. The
choice of the limit is based on the features they want their
implementation to support. The protocol specification doesn't
define a limit.

It's OK that the protocol doesn't define a limit. The problem
is there's no way for a client and server to discover the
other's actual limits. Since we're documenting the protocol
here, not defining it, we're stuck with that for the moment.

We could do something clever like add these limits to the
RDMA CM private data.


> There are cases where a solaris client can send up to 16 segments in one write chunk.  WOuld that be considered under the "practical limit"?

No, that would _be_ the practical limit for your client.

For example, the Linux server has a limit of about 260 segments,
because it supports 1MB NFS READs and WRITEs, and 256 pages (plus
a few to accommodate non-aligned payloads) is needed with 4KB
pages.

The Linux server has a limit of 1 normal Read chunk or 1
Position-zero Read chunk. That's totally arbitrary, and was an
implementation choice based on what the Linux client of 2008
might send. Clearly, the Linux server will need to be improved
to support more general clients like Solaris.


--
Chuck Lever