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@xxxxxxxxxx>
