[PATCH net v3] net: axienet: bound TX completion cleanup by the NAPI budget
Sagi Maimon
maimon.sagi at gmail.com
Wed Sep 30 00:16:52 PDT 2026
On Tue, Sep 29, 2026 at 4:22 PM Paolo Abeni <pabeni at redhat.com> wrote:
>
> On 9/24/26 15:50, Sagi Maimon wrote:
> > axienet_tx_poll() passes lp->tx_bd_num to axienet_free_tx_chain() as
> > @nr_bds, and @budget is only forwarded to napi_consume_skb() as its
> > bulk-free hint. Nothing limits the cleanup loop to the NAPI budget, so
> > the number of packets returned is bounded by the TX ring size rather
> > than by the budget, and the poll can report more work than it was
> > given:
> >
> > eth0: NAPI poll function axienet_tx_poll+0x0/0x180 [xilinx_emac]
> > returned 96, exceeding its budget of 64.
> >
> > Returning more than the budget breaks the NAPI contract. It also makes
> > the "packets < budget" test in axienet_tx_poll() false, so
> > napi_complete_done() is skipped and TX completion interrupts are not
> > re-enabled on that pass. NAPI reschedules the poll, so this recovers,
> > but the accounting is wrong either way.
> >
> > In steady state fewer descriptors complete per poll than the budget
> > allows, which is why this is rarely observed. Triggering it needs more
> > than @budget completions outstanding at once - for example when TX
> > completion interrupts have not been taken for a while and a full ring is
> > reclaimed in one go.
> >
> > Stop the loop once the budget is spent.
>
> Napi can process as much TX descriptor as available, even above `budget`
> see:
>
> https://elixir.bootlin.com/linux/v7.2.8/source/Documentation/networking/napi.rst#L68
>
> The solution would be capping axienet_tx_poll() return value to `budget`.
Agreed, and v4 does exactly that: the ring is still reclaimed in full,
and axienet_tx_poll() returns min(packets, budget), which also gives 0
for netpoll's budget of 0. It is posted as "net: axienet: cap the TX
poll return value at the NAPI budget".
Thanks,
Sagi
pw-bot: cr
>
> /P
>
More information about the linux-arm-kernel
mailing list