Re: [PATCH v2 5/7] NFSD: Evict completed DRC entries via implied ACK

[Jeff Layton <jlayton@kernel.org>]

On Fri, 2026-08-28 at 14:59 -0400, Chuck Lever wrote:
> On Fri, Aug 28, 2026, at 2:38 PM, Jeff Layton wrote:
> > On Fri, 2026-08-28 at 12:17 -0400, Chuck Lever wrote:
> > > A completed DRC entry stays in its bucket until RC_EXPIRE elapses or
> > > the cache exceeds max_drc_entries. Entries whose replies the client
> > > already holds lengthen the bucket and slow every lookup that hashes
> > > there.
> > > 
> > > RFC 1813 Section 4.5 observes that on a connection-oriented transport
> > > a duplicate request arises from reconnection, not from within a live
> > > connection. A fresh request on a live TCP or RDMA connection therefore
> > > means the client is not retransmitting an earlier one. UDP clients
> > > retransmit on timeout over a shared svc_xprt, so eviction is
> > > restricted to transports marked XPT_ORDERED. Even there the evidence
> > > is not conclusive, since a client with several requests outstanding
> > > sends the next before the previous reply arrives. The cache is
> > > advisory: a premature eviction costs a miss and re-execution, the same
> > > outcome memory pressure and RC_EXPIRE already produce.
> > 
> > No, it's not. The DRC is necessary for proper function, and if we drop
> > non-idempotent requests prematurely, then that could cause spurious
> > errors.
> > 
> > Or am I misunderstanding what you mean by "The cache" here?
> 
> Not talking about the NFSv4.1 session cache. The old DRC has
> always been best-effort. It cannot be relied upon for proper
> function, since the DRC is non-deterministic.
> 

Yes, but in this case you can potentially evict this thing well before
you actually need it:

- client does a v3 RENAME (anything non-idempotent, really)
- reply to the RENAME goes out just before a new call comes in (WRITE
or something maybe). The RENAME DRC entry's timestamp is a few jiffies
earlier so we evict it.
- connection drops before client gets the reply and client reconnects
and retransmits the v3 RENAME

...hilarity ensues? Maybe this sort of bad luck never happens in
practice, but I don't see what would prevent it.

> The point I'm making here is that items already get evicted
> due to memory pressure or because the DRC size is capped.
> 
> In particular, if you are actively removing items that are
> very unlikely to be hit, that *reduces* the likelihood that
> other, perhaps more valuable, items will be evicted due to
> memory pressure.
> 

Sure, but usually we evict the oldest stuff first, and we generally
keep a big enough cache to get past the point where retransmissions
occur. This patchset changes that and will evict things earlier.

Maybe that's OK in practice.
-- 
Jeff Layton <jlayton@kernel.org>