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

["Chuck Lever" <cel@kernel.org>]

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.

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.


-- 
Chuck Lever