Re: [PATCH net v7] net: stop defer_count outliving the deferred-free list

[Joseph Kain]

On Mon, Nov 2, 2026 at 1:21 PM <netdev-bot+sashiko@xxxxxxxxxx> wrote:
>
> With the subtraction moved after the napi_consume_skb() loop, does
> deferral stay disabled for the whole drain?

Yes, for a full batch. The detached skbs remain charged until the
freeing loop completes; smaller batches can leave capacity for
further admissions. I should have explained this admission-window
change.

Preliminary non-PREEMPT_RT x86 VM tests recorded no limit rejections
in either variant at skb_defer_max=128. Results at 16 and 32 showed
mixed rejection and purge counts. Throughput and CPU cost were not
measured, so these results do not establish a performance advantage
for either ordering.

I propose retaining the current single-pass drain for now. If
another revision is needed, I will explicitly document that the
detached batch remains charged until freeing completes.

> This is a pre-existing issue, but can a runtime change to
> net.core.skb_defer_max still leave a per-(cpu, node) queue at or above
> the new limit with no purge pending?

Agreed, and as you say it is pre-existing: neither the reject path nor
proc_do_skb_defer_max() kicks, before or after this patch. Both of your
examples look right to me. It is out of scope for this patch, which is
about counts outliving the list.