From: Sagi Maimon <maimon.sagi@gmail.com>
To: netdev@vger.kernel.org
Cc: radhey.shyam.pandey@amd.com, michal.simek@amd.com,
andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, robert.hancock@calian.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Sagi Maimon <maimon.sagi@gmail.com>
Subject: [PATCH net v3] net: axienet: bound TX completion cleanup by the NAPI budget
Date: Thu, 24 Sep 2026 16:50:52 +0300 [thread overview]
Message-ID: <20260924135052.185129-1-maimon.sagi@gmail.com> (raw)
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. cur_p->skb is only set on a
packet's last descriptor, so breaking there never leaves a packet
half-freed. The check is skipped on the @force path, which cleans up
after a DMA mapping failure.
A budget of 0 is a separate case. netpoll calls napi->poll() with a
budget of 0 to reclaim the TX path only, and expects no work to be
reported. Treat 0 as no limit in the cleanup loop so the ring is still
drained, and have axienet_tx_poll() report no work for it. Returning
the reclaimed count would trip the WARN_ONCE() in poll_one_napi(),
which the unbounded loop could already do before this change.
Tested on an AXI Ethernet MAC behind a PCIe endpoint: traffic passes
with this change applied. Neither an over-budget poll nor the netpoll
path was exercised in that test.
Fixes: 9e2bc267e780 ("net: axienet: Use NAPI for TX completion path")
Assisted-by: LLM sparse
Signed-off-by: Sagi Maimon <maimon.sagi@gmail.com>
---
Notes:
Changes in v3:
- Report no work for a budget of 0: axienet_tx_poll() now returns
"budget ? packets : 0", so netpoll cannot trip the WARN_ONCE() in
poll_one_napi() (Sashiko).
- Reword the @budget kernel-doc and the in-loop comment to cover both
uses of a budget of 0 (Sashiko).
- Drop the wrong claim that a budget of 0 matters to the @force callers
(Sashiko).
- Add a hardware test note, and 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 reclaimed nothing for it (Sashiko).
- v1: https://lore.kernel.org/netdev/20260914114821.55503-1-maimon.sagi@gmail.com/
.../net/ethernet/xilinx/xilinx_axienet_main.c | 22 +++++++++++++++++--
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
index 782f903d318f..7fd77f8cb57c 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
@@ -772,7 +772,11 @@ static int axienet_device_reset(struct net_device *ndev)
* @force: Whether to clean descriptors even if not complete
* @sizep: Pointer to a u32 accumulating the total byte count of
* completed packets (using skb->len). Ignored if NULL.
- * @budget: NAPI budget (use 0 when not called from NAPI poll)
+ * @budget: NAPI budget, or 0 when not called from NAPI poll; also passed
+ * to napi_consume_skb(). When @force is false, cleanup stops once
+ * @budget completed packets have been freed. A budget of 0 means
+ * no limit: netpoll polls with it to drain the TX ring, and
+ * axienet_tx_poll() then reports no work.
*
* Would either be called after a successful transmit operation, or after
* there was an error when setting up the chain.
@@ -788,6 +792,16 @@ static int axienet_free_tx_chain(struct axienet_local *lp, u32 first_bd,
dma_addr_t phys;
for (i = 0; i < nr_bds; i++) {
+ /* A NAPI poll must not return more than its budget. Stop on a
+ * packet boundary once it is spent - cur_p->skb is only set on
+ * a packet's last descriptor, so no packet is left half-freed.
+ * A zero budget means no limit: netpoll polls with a budget of
+ * 0 to reclaim the TX path, so the ring must still be drained;
+ * axienet_tx_poll() reports no work to it.
+ */
+ if (!force && budget && packets >= budget)
+ break;
+
cur_p = &lp->tx_bd_v[(first_bd + i) % lp->tx_bd_num];
status = cur_p->status;
@@ -1027,7 +1041,11 @@ 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;
+
+ /* netpoll polls with a budget of 0 to reclaim the TX path and expects
+ * no work to be reported; see poll_one_napi().
+ */
+ return budget ? packets : 0;
}
/**
base-commit: 879e280b8486d4612ad1aa050d6fada2dd80cf1c
--
2.47.0
reply other threads:[~2026-09-24 13:51 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20260924135052.185129-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 \
/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®