Re: Should we establish a new nfsdctl userland program?

[Chuck Lever III <chuck.lever@oracle.com>]

> On Feb 5, 2024, at 1:03 PM, Jeff Layton <jlayton@kernel.org> wrote:
> 
> On Mon, 2024-02-05 at 18:44 +0100, Lorenzo Bianconi wrote:
>>> On Mon, 2024-02-05 at 17:46 +0100, Lorenzo Bianconi wrote:
>>>> 
>>>> 
>>>> I agree on it. In order to proceed I guess we should define a list of
>>>> requirements/expected behaviour on this new user-space tool used to
>>>> configure nfsd. I am not so familiar with the user-space requirements
>>>> for nfsd so I am just copying what you suggested, something like:
>>>> 
>>>> $ nfsdctl stats                                                 <--- fetch the new stats that got merged
>>>> $ nfsdctl xprt add proto <udp|tcp> host <host> [port <port>]    <--- add a new listen socket, by address or hostname
>>> 
>>> Those look fine.
>>> 
>>> All of the commands should display the current state too when run with
>>> no arguments. So running "nfsctl xprt" should dump out all of the
>>> listening sockets. Ditto for the ones below too.
>> 
>> ack
>> 
> 
> I think we might need a "nfsdctl xprt del" too. I know we don't have
> that functionality now, but I think it's missing. Otherwise if you
> mistakenly set the wrong socket with the interface above, how do you fix
> it?

Is "nfsdctl xprt" for managing listeners? I think the following
might be more in line with how NFS and RPC deal with transports:

  nfsdctl listen netid xxx addr yyyyy [ port zzz ]

or

  nfsdctl listen netid xxx dns yyyyy [ port zzz ]

"xxx" would be one of

  udp, udp6, tcp, tcp6, rdma, rdma6, local

"addr yyyy" would be an IP presentation address, in an address
family that matches the netid's family. Recall that TI-RPC
considers IPv4 and IPv6 listeners each as separate endpoints.

"dns yyyy" would be a DNS label

Do we need to add a keyword to control whether the kernel
registers the new listening endpoint with the local rpcbind?


> Alternately, we could provide some way to reset the server state
> altogether:
> 
>     # nfsdctl reset
> 
> ?
> 
>>> 
>>>> $ nfsdctl proto v3.0 v4.0 v4.1                                  <--- enable NFSv3 and v4.1
>>> 
>>> The above would also enable v4.0 too?
>>> 
>>> For this we might want to use the +/- syntax, actually. Also, there were
>>> no minorversions before v4, so it probably better not to accept that for
>>> v3:
>>> 
>>>     $ nfsdctl proto +v3 -v4.0 +4.1

I would prefer not using "proto" since that term is already
overloaded. "version" might be better, and maybe we don't
need the "v" suffix...?


--
Chuck Lever