On Wed, 20 Nov 2024, Jeff Layton wrote:
> On Tue, 2024-11-19 at 11:41 +1100, NeilBrown wrote:
> > Here is v2 of my series for on-demand allocation and freeing of session DRC slots.
> >
> > - Now uses an xarray to store slots, and the limit is raised to 2048
> > - delays retiring a slot until the client has confirmed that it isn't
> > using it as described in RFC:
> >
> > The replier SHOULD retain the slots it wants to retire until the
> > requester sends a request with a highest_slotid less than or equal
> > to the replier's new enforced highest_slotid.
> >
> > - When a retired slot is used, allow the seqid to be the next in sequence
> > as required by the RFC:
> >
> > Each time a slot is reused, the request MUST specify a sequence
> > ID that is one greater than that of the previous request on the
> > slot.
> >
> > or "1" as (arguably) allowed by the RFC:
> >
> > The first time a slot is used, the requester MUST specify a
> > sequence ID of one
> >
>
> I thought that the conclusion of the IETF discussion was that we should
> reset this to 1. It'd be ideal to just do that, as then we wouldn't
> need NFSD4_SLOT_REUSED.
I thought the conclusion was:
I'm convinced. The next draft of rfc5661bis will address this issue.
Until the issue is addressed I don't think it would be wise to preempt
the result.
>
> Are there any clients that expect to reuse the old seqid in this
> situation? I know the Linux client doesn't. Do Solaris or FreeBSD?
I don't know. But I tend to code the the spec, not to other clients.
I still think the specs says
Each time a slot is reused, the request MUST specify a sequence
ID that is one greater than that of the previous request on the
slot.
and I don't see any good reason not to treat what we are doing here as
"reuse".
So I'm making a concession to the linux client and to you by allowing
'1'. I'm still not convinced that it is a good idea. At best I'm
convinced that the spec can be read to suggest that might be an option.
Thanks,
NeilBrown
