From: Sagi Maimon <maimon.sagi@gmail.com>
To: netdev@vger.kernel.org
Cc: pabeni@redhat.com, radhey.shyam.pandey@amd.com,
michal.simek@amd.com, andrew+netdev@lunn.ch, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, robert.hancock@calian.com,
sean.anderson@linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Sagi Maimon <maimon.sagi@gmail.com>
Subject: [PATCH net v4] net: axienet: cap the TX poll return value at the NAPI budget
Date: Wed, 30 Sep 2026 10:15:36 +0300 [thread overview]
Message-ID: <20260930071536.627964-1-maimon.sagi@gmail.com> (raw)
axienet_tx_poll() reclaims every completed TX descriptor in one pass:
it passes lp->tx_bd_num to axienet_free_tx_chain() as the descriptor
limit, and @budget is only used as the napi_consume_skb() bulk-free
hint. It then returns the number of packets reclaimed, which is bounded
by the ring size rather than by the budget, so the poll can report more
work than it was given. This was seen after TX completion interrupts
had not been taken for a while and a full ring was reclaimed at once:
eth0: NAPI poll function axienet_tx_poll+0x0/0x180 [xilinx_emac]
returned 96, exceeding its budget of 64.
netpoll is affected as well. poll_one_napi() polls with a budget of 0
to reclaim the TX path only, and warns once if any work is reported.
Keep reclaiming the whole ring and cap only the value returned.
Documentation/networking/napi.rst allows a poll to process any number
of TX completions; it is the reported work that must stay within the
budget. Stopping the reclaim at the budget instead would also leave
completed descriptors for a later poll, which does not come when
napi_disable() is pending. When more than @budget packets were
reclaimed, returning @budget keeps the poll scheduled, and the next poll
completes NAPI and re-enables the interrupt as before. A budget of 0
now yields 0.
Suggested-by: Paolo Abeni <pabeni@redhat.com>
Fixes: 5a6caa2cfabb ("net: xilinx: axienet: Fix packet counting")
Assisted-by: LLM sparse
Signed-off-by: Sagi Maimon <maimon.sagi@gmail.com>
---
Notes:
Changes in v4:
- Different approach, as Paolo Abeni and the review of v3 suggested:
keep reclaiming the whole ring and cap only the value returned,
instead of stopping the reclaim at the budget. napi.rst allows any
number of TX completions per poll, and stopping early could leave
completed descriptors behind while napi_disable() is pending.
- Subject changed to match; v1-v3 were "net: axienet: bound TX
completion cleanup by the NAPI budget".
- Fixes: now names 5a6caa2cfabb, which made the return value unbounded
(review of v3).
- Only axienet_tx_poll() and its kernel-doc change now.
- Suggested-by: Paolo Abeni.
- Build-tested only so far; v3 was tested on hardware, v4 not yet.
- v3: https://lore.kernel.org/netdev/20260924135052.185129-1-maimon.sagi@gmail.com/
Changes in v3:
- Report no work for a budget of 0, so netpoll cannot trip the
WARN_ONCE() in poll_one_napi().
- Add the Assisted-by: tag that v1 and v2 omitted.
- v2: https://lore.kernel.org/netdev/20260917115657.20697-1-maimon.sagi@gmail.com/
Changes in v2:
- Treat a budget of 0 as no limit, so that netpoll still drains the TX
ring.
- v1: https://lore.kernel.org/netdev/20260914114821.55503-1-maimon.sagi@gmail.com/
drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
index 1722b7038f34..243b07fd5be8 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
@@ -984,9 +984,9 @@ axienet_start_xmit_dmaengine(struct sk_buff *skb, struct net_device *ndev)
* axienet_tx_poll - Invoked once a transmit is completed by the
* Axi DMA Tx channel.
* @napi: Pointer to NAPI structure.
- * @budget: Max number of TX packets to process.
+ * @budget: NAPI budget, or 0 when polled by netpoll.
*
- * Return: Number of TX packets processed.
+ * Return: Number of TX packets processed, capped at @budget.
*
* This function is invoked from the NAPI processing to notify the completion
* of transmit operation. It clears fields in the corresponding Tx BDs and
@@ -1027,7 +1027,12 @@ static int axienet_tx_poll(struct napi_struct *napi, int budget)
axienet_dma_out32(lp, XAXIDMA_TX_CR_OFFSET, lp->tx_dma_cr);
spin_unlock_irq(&lp->tx_cr_lock);
}
- return packets;
+
+ /* The whole ring was reclaimed above, which may be more than the
+ * budget, but a poll must not report more work than it was given.
+ * netpoll polls with a budget of 0 and expects no work reported.
+ */
+ return min(packets, budget);
}
/**
base-commit: a7bfaba4823e3c165bb2004c74eff7c096672bc7
--
2.47.0
next reply other threads:[~2026-09-30 7:15 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-30 7:15 Sagi Maimon [this message]
2026-09-30 7:19 ` netdev-bot+sinfo
2026-09-30 10:19 ` Gupta, Suraj
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260930071536.627964-1-maimon.sagi@gmail.com \
--to=maimon.sagi@gmail.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michal.simek@amd.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=radhey.shyam.pandey@amd.com \
--cc=robert.hancock@calian.com \
--cc=sean.anderson@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®