[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <fce7982708d3e82af4e4da10fb8022cc4f851460.camel@kernel.org>
Date: Tue, 29 Oct 2024 14:24:20 -0400
From: Jeff Layton <jlayton@...nel.org>
To: Tom Talpey <tom@...pey.com>, Chuck Lever <chuck.lever@...cle.com>
Cc: Neil Brown <neilb@...e.de>, Dai Ngo <Dai.Ngo@...cle.com>, Olga
Kornievskaia <okorniev@...hat.com>, linux-nfs@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] nfsd: allow for more callback session slots
On Tue, 2024-10-29 at 13:54 -0400, Tom Talpey wrote:
> On 10/29/2024 6:28 AM, Jeff Layton wrote:
> > I'm open to switching to a per-session lock of some sort, but I don't
> > see a real need here. Only one session will be used as the backchannel
> > at a time, so there shouldn't be competing access between different
> > sessions for the cl_lock. We are competing with the other uses of the
> > cl_lock, but this one should be pretty quick. My preference would be to
> > add extra locking only once it becomes clear that it's necessary.
>
> I have a question on what you mean by "Only one session will be used
> as the backchannel". Does this mean that the server ignores backchannels
> for all but one random victim? That doesn't seem fair, or efficient.
> And what happens with nconnect > 1?
>
The server currently picks a single session that it designates as the
backchannel (the clp->cl_cb_session). All the callbacks go over that
session's connections until it's reevaluated in
nfsd4_process_cb_update.
I'm not sure what the server does with nconnect on the backchannel, but
that's a separate project anyway. Getting to the point where we can
send more than one v4.1+ callback at a time is the first step.
> Another question is, what clients are offering this many backchannel
> slots?
>
The Linux NFS client offers 16 slots. I overshot that a little with
this implementation, but the extra memory cost is trivial (an extra 64
bytes per client).
--
Jeff Layton <jlayton@...nel.org>
Powered by blists - more mailing lists