netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chuck Lever <chuck.lever@oracle.com>
To: NeilBrown <neilb@suse.de>
Cc: Jeff Layton <jlayton@kernel.org>,
	Lorenzo Bianconi <lorenzo@kernel.org>,
	linux-nfs@vger.kernel.org, lorenzo.bianconi@redhat.com,
	kuba@kernel.org, horms@kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH v6 3/3] NFSD: add write_ports to netlink command
Date: Mon, 22 Jan 2024 17:58:38 -0500	[thread overview]
Message-ID: <Za7zHvPJdei/vWm4@tissot.1015granger.net> (raw)
In-Reply-To: <170595930799.23031.17998490973211605470@noble.neil.brown.name>

On Tue, Jan 23, 2024 at 08:35:07AM +1100, NeilBrown wrote:
> On Tue, 23 Jan 2024, Jeff Layton wrote:
> > On Sat, 2024-01-20 at 18:33 +0100, Lorenzo Bianconi wrote:
> > > Introduce write_ports netlink command. For listener-set, userspace is
> > > expected to provide a NFS listeners list it wants to enable (all the
> > > other ports will be closed).
> > > 
> > 
> > Ditto here. This is a change to a declarative interface, which I think
> > is a better way to handle this, but we should be aware of the change.
> 
> I agree it is better, and thanks for highlighting the change.
> 
> > > +	/* 2- remove stale listeners */
> > 
> > 
> > The old portlist interface was weird, in that it was only additive. You
> > couldn't use it to close a listening socket (AFAICT). We may be able to
> > support that now with this interface, but we'll need to test that case
> > carefully.
> 
> Do we ever want/need to remove listening sockets?

I think that might be an interesting use case. Disabling RDMA, for
example, should kill the RDMA listening endpoints but leave
listening sockets in place.

But for now, our socket listeners are "any". Wondering how net
namespaces play into this.


> Normal practice when making any changes is to stop and restart where
> "stop" removes all sockets, unexports all filesystems, disables all
> versions.
> I don't exactly object to supporting fine-grained changes, but I suspect
> anything that is not used by normal service start will hardly ever be
> used in practice, so will not be tested.

Well, there is that. I guess until we have test coverage for NFSD
administrative interfaces, we should leave well enough alone.


> So if it is easiest to support reverting previous configuration (as it
> probably is for version setting), then do so.  But if there is any
> complexity (as maybe there is with listening sockets), then don't
> add complexity that won't be used.
> 
> Thanks,
> NeilBrown

-- 
Chuck Lever

  parent reply	other threads:[~2024-01-22 22:58 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-20 17:33 [PATCH v6 0/3] convert write_threads, write_version and write_ports to netlink commands Lorenzo Bianconi
2024-01-20 17:33 ` [PATCH v6 1/3] NFSD: convert write_threads to netlink command Lorenzo Bianconi
2024-01-20 17:33 ` [PATCH v6 2/3] NFSD: add write_version " Lorenzo Bianconi
2024-01-22 13:27   ` Jeff Layton
2024-01-20 17:33 ` [PATCH v6 3/3] NFSD: add write_ports " Lorenzo Bianconi
2024-01-22 13:41   ` Jeff Layton
2024-01-22 15:35     ` Lorenzo Bianconi
2024-01-22 15:50       ` Jeff Layton
2024-01-22 15:59         ` Lorenzo Bianconi
2024-01-22 21:35     ` NeilBrown
2024-01-22 21:37       ` Jeff Layton
2024-01-22 22:58       ` Chuck Lever [this message]
2024-01-23  9:59         ` Lorenzo Bianconi
2024-01-23 11:17           ` Jeff Layton
2024-01-23 13:21             ` Lorenzo Bianconi
2024-01-23 14:28               ` Jeff Layton
2024-01-24  9:52                 ` Lorenzo Bianconi
2024-01-24 11:24                   ` Jeff Layton
2024-01-24 13:55                     ` Chuck Lever III
2024-01-24 18:10                       ` Jeff Layton
2024-01-25 22:44                       ` NeilBrown
2024-01-26  2:38                         ` Chuck Lever III
2024-01-26  7:27                           ` NeilBrown
2024-01-26 13:58                         ` Chuck Lever III
2024-01-22 16:31   ` kernel test robot
2024-01-22 13:49 ` [PATCH v6 0/3] convert write_threads, write_version and write_ports to netlink commands Jeff Layton
2024-01-22 17:01   ` Lorenzo Bianconi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Za7zHvPJdei/vWm4@tissot.1015granger.net \
    --to=chuck.lever@oracle.com \
    --cc=horms@kernel.org \
    --cc=jlayton@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=lorenzo.bianconi@redhat.com \
    --cc=lorenzo@kernel.org \
    --cc=neilb@suse.de \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).