Received-SPF: pass (google.com: domain of linux-nfs+bounces-1792-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Date: Mon, 5 Feb 2024 17:46:07 +0100
From: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
To: Jeff Layton <jlayton@kernel.org>
Cc: Chuck Lever <chuck.lever@oracle.com>, NeilBrown <neilb@suse.com>,
	Dai Ngo <dai.ngo@oracle.com>,
	"olga.kornievskaia" <olga.kornievskaia@gmail.com>,
	Tom Talpey <tom@talpey.com>, linux-nfs <linux-nfs@vger.kernel.org>
Subject: Re: Should we establish a new nfsdctl userland program?
Message-ID: <ZcEQzyrZpyrMJGKg@lore-desk>
References: <8a7bbc05b6515109692cb88ad68374d14fc01eca.camel@kernel.org>
 <Zb0hlnQmgVikeNpi@lore-rh-laptop>
 <e706a77b4ddbceeb8b0ebac4dcbca03f8196e8a5.camel@kernel.org>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="41hxKUPJ+PtSz3ku"
Content-Disposition: inline
In-Reply-To: <e706a77b4ddbceeb8b0ebac4dcbca03f8196e8a5.camel@kernel.org>


--41hxKUPJ+PtSz3ku
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

> On Fri, 2024-02-02 at 18:08 +0100, Lorenzo Bianconi wrote:
> > > The existing rpc.nfsd program was designed during a different time, w=
hen
> > > we just didn't require that much control over how it behaved. It's
> > > klunky to work with.
> > >=20
> > > In a response to Chuck's recent RFC patch to add knob to disable
> > > READ_PLUS calls, I mentioned that it might be a good time to make a
> > > clean break from the past and start a new program for controlling nfs=
d.
> > >=20
> > > Here's what I'm thinking:
> > >=20
> > > Let's build a swiss-army-knife kind of interface like git or virsh:
> > >=20
> > > # nfsdctl=A0stats			<--- fetch the new stats that got merged
> > > # nfsdctl add_listener		<--- add a new listen socket, by address or h=
ostname
> > > # nfsdctl set v3 on		<--- enable NFSv3
> > > # nfsdctl set splice_read off	<--- disable splice reads (per Chuck's =
recent patch)
> > > # nfsdctl set threads 128	<--- spin up the threads
> > >=20
> > > We could start with just the bare minimum for now (the stats interfac=
e),
> > > and then expand on it. Once we're at feature parity with rpc.nfsd, we=
'd
> > > want to have systemd preferentially use nfsdctl instead of rpc.nfsd to
> > > start and stop the server. systemd will also need to fall back to usi=
ng
> > > rpc.nfsd if nfsdctl or the netlink program isn't present.
> > >=20
> > > Note that I think this program will have to be a compiled binary vs. a
> > > python script or the like, given that it'll be involved in system
> > > startup.
> > >=20
> > > It turns out that Lorenzo already has a C program that has a lot of t=
he
> > > plumbing we'd need:
> > >=20
> > > =A0=A0=A0=A0https://github.com/LorenzoBianconi/nfsd-netlink
> >=20
> > This is something I developed just for testing the new interface but I =
agree we
> > could start from it.
> >=20
> > Regarding the kernel part I addressed the comments I received upstream =
on v6 and
> > pushed the code here [0].
> > How do you guys prefer to proceed? Is the better to post v7 upstream an=
d continue
> > the discussion in order to have something usable to develop the user-sp=
ace part or
> > do you prefer to have something for the user-space first?
> > I do not have a strong opinion on it.
> >=20
> > Regards,
> > Lorenzo
> >=20
> > [0] https://github.com/LorenzoBianconi/nfsd-next/tree/nfsd-next-netlink=
-new-cmds-public-v7
> >=20
> >=20
>=20
> My advice?
>=20
> Step back and spend some time working on the userland bits before
> posting another revision. Experience has shown that you never realize
> what sort of warts an interface like this has until you have to work
> with it.
>=20
> You may find that you want to tweak it some once you do, and it's much
> easier to do that before we merge anything. This will be part of the
> kernel ABI, so once it's in a shipping kernel, we're sort of stuck with
> it.
>=20
> Having a userland program ready to go will allow us to do things like
> set up the systemd service for this too, which is primarily how this new
> program will be called.

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=A0stats                                                 <--- fetc=
h 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
$ nfsdctl proto v3.0 v4.0 v4.1                                  <--- enable=
 NFSv3 and v4.1
$ nfsdctl set threads 128                                       <--- spin u=
p the threads

Can we start from [0] to develop them?

Regards,
Lorenzo

[0] https://github.com/LorenzoBianconi/nfsd-netlink

> --=20
> Jeff Layton <jlayton@kernel.org>
>=20

--41hxKUPJ+PtSz3ku
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQTquNwa3Txd3rGGn7Y6cBh0uS2trAUCZcEQzgAKCRA6cBh0uS2t
rMzaAP9l/bpJg/6gB+MNuLKKcUo69a1XDPGkA58cOl73C4UccQD+KtqT87L+S1ey
s5iI5MvECARMKsyIS8BeD+yoNMkM3gY=
=50pK
-----END PGP SIGNATURE-----

--41hxKUPJ+PtSz3ku--