"why NFSv3?" [was: Re: [PATCH v11 00/20] nfs/nfsd: add support for localio]

[Mike Snitzer <snitzer@kernel.org>]

Earlier yesterday I answered the question about "why NFSv3?" in simple
terms.  Chuck and Christoph rejected it.  I'm _not_ being evassive.
There isn't a lot to it: "More efficient NFS in containers" _is_ the
answer.

But hopefully this email settles "why NFSv3?".  If not, please help me
(or others) further your understanding by reframing your NFSv3 concern
in terms other than "why NFSv3?".

Why NFSv3?
----------

The localio feature improves IO performance when using NFSv3 and NFSv4
with containers.  Hammerspace has immediate need for the NFSv3
support, because its "data movers" use NFSv3, but NFSv4 support is
expected to be useful in the future.

Why not use pNFS?
-----------------

Just because Hammerspace is very invested in pNFS doesn't mean all
aspects are framed in terms of it.

The complexity of a pNFS-based approach to addressing localio makes it
inferior to the proposed solution of an autonomous NFS client and
server rendezvous to allow for network bypass.  There is no need for
pNFS and by not using pNFS the localio feature is accessible for
general NFSv3 and NFSv4 use.

Answering "Why NFSv3?" with questions:
--------------------------------------

1) Why wasn't general NFS localio bypass controversial 3 weeks ago?
Instead (given all inputs, NFSv3 support requirement being one of
them) the use of a "localio protocol" got broad consensus and buyin
from Chuck, Jeff, and Neil.

I _thought_ we all agreed localio was a worthwhile _auxilliary_
addition to Linux's NFS client and server (to give them awareness of
each other through nfs_common) regardless of NFS protocol version.
That is why I registered a localio RPC program number with IANA, at
Chuck's suggestion, see:
https://www.iana.org/assignments/rpc-program-numbers/rpc-program-numbers.txt

$ cat rpc-program-numbers.txt | egrep 'Snitzer|Myklebust|Lever'
   Linux Kernel Organization                  400122         nfslocalio                   [Mike_Snitzer][Trond_Myklebust][Chuck_Lever]
   [Chuck_Lever]           Chuck Lever           mailto:chuck.lever&oracle.com  2024-06-20
   [Mike_Snitzer]          Mike Snitzer          mailto:snitzer&kernel.org      2024-06-20
   [Trond_Myklebust]       Trond Myklebust       mailto:trondmy&hammerspace.com 2024-06-20

2) If we're introducing a general NFS localio bypass feature _and_
NFSv3 is important to the stakeholder proposing the feature _and_
NFSv3 support is easily implemented and supported: then why do you
have such concern about localio supporting NFSv3?

3) Why do you think NFSv3 unworthy?  Is this just a bellweather for
broader opposition to flexfiles (and its encouraging more use of
NFSv3)?  Flexfiles is at the heart of NFSv3 use at Hammerspace.  I've
come to understand from Chuck and Christoph that the lack of flexfiles
support in NFSD helps fuel dislike for flexfiles.  That's a lot for me
to unpack, and pretty far removed from "why NFSv3?", so I'd need more
context than I have if Hammerspace's use of flexfiles is what is
fueling your challenge of localio's NFSv3 support.

...

Reiterating and then expanding on my earlier succinct answer:

  localio supporting NFSv3 is beneficial for NFSv3 users (NFSv3 in
  containers).

  Hammerspace needs localio to work with NFSv3 to assist with its
  "data movers" that run on the host (using nfs [on host] and nfsd
  [within container]).

Now you can ask why _that_ is.. but it really is pretty disjoint from
the simple matter of ensuring localio support both NFSv3 and NFSv4.

I've shared that Hammerspace's "data movers" use NFSv3 currently, in
the future they could use NFSv4 as needed.  Hence the desire to
support localio with both NFSv3 and NFSv4.  [when I picked up the
localio code NFSv4 wasn't even supported yet].