[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