> On Nov 13, 2024, at 10:19 PM, NeilBrown <neilb@xxxxxxx> wrote: > > On Thu, 14 Nov 2024, Jeff Layton wrote: >> On Wed, 2024-11-13 at 12:31 +1100, NeilBrown wrote: >>> >>> So initialising them all to 1 when the session is created, as you do in >>> init_session(), is clearly correct. Reinitialising them after >>> target_highest_slot_id has been reduced and then increased is not >>> justified by the above. >>> >> >> But, once the client and server have forgotten about those slots after >> shrinking the slot table, aren't they effectively new? IOW, once you've >> shrunk the slot table, the slots are effectively "freed". Growing it >> means that you have to allocate new ones. The fact that this patch just >> keeps them around is an implementation detail. > > > There is no text in the RFC about shrinking or growing or forgetting. > The only meaning given to numbers like ca_maxreqs is that the client > shouldn't use a larger slot number than the given one. > > I think the slot table is conceptually infinite and exists in its > entirety from the moment CREATE_SESSION completes to the moment > DESTROY_SESSION completes (or a lease expires or similar). The client > can limit how much of that infinitude that it will choose to use, and > the server can limit how much of it it will allow to be used so neither > need to store the full infinity. But it never changes size. > Implementations can choose how much to store in real memory and can > discard every except (I think) the last sequence number seen on any slot > for which a request was sent (client) or accepted (server). This is, IMO, one possible implementation of a slot table. As you say, the spec doesn't provide a lot of guidance about it. Therefore I believe other implementations are possible. It would be prudent to survey some of them. > I agree that this seems less that ideal and it would be good if the > protocol has a mechanism for the client and server to agree to reset > the seqid for some slots. But I cannot find any such mechanism. -- Chuck Lever
