[PATCH net v5] net: axienet: do not report TX completions as NAPI work

[PATCH net v5] net: axienet: do not report TX completions as NAPI work

[Sagi Maimon]

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.

TX completions are not budgeted work: Documentation/networking/napi.rst
lets a poll process any number of them.  Do as bcmgenet does since
commit a58cdf56b6eb ("net: bcmgenet: complete Tx NAPI after one reclaim
pass"): reclaim the ring, complete NAPI with no work done, re-enable the
TX completion interrupt and return 0.  Re-enabling the interrupt raises
it straight away if more completions are already pending, so none is
left behind.  This also drops the extra poll that used to follow a full
budget's worth of completions, which only found an empty ring.

netpoll polls with a budget of 0 and must not complete NAPI, so skip
the completion then; napi_complete_done() refuses it in that case
anyway.

Suggested-by: Jakub Kicinski <kuba@kernel.org>
Fixes: 5a6caa2cfabb ("net: xilinx: axienet: Fix packet counting")
Assisted-by: LLM sparse
Signed-off-by: Sagi Maimon <maimon.sagi@gmail.com>
---

Notes:
    Changes in v5:
    - Complete NAPI with 0 and return 0, following commit a58cdf56b6eb as
      Jakub suggested, instead of capping the returned packet count at the
      budget.  Subject changed to match.
    - Dropped Suraj's Reviewed-by, as the change is different now.
    - Build-tested only; not yet run on hardware.
    - v4: https://lore.kernel.org/netdev/20260930071536.627964-1-maimon.sagi@gmail.com/
    
    Changes in v4:
    - Keep reclaiming the whole ring and cap only the value returned, as
      Paolo Abeni and the review of v3 suggested, instead of stopping the
      reclaim at the budget.
    - Fixes: now names 5a6caa2cfabb (review of v3).
    - 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().
    - 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 | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
index 09443623a3e2..a13323a9399f 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
@@ -985,9 +985,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: Always 0.  TX completions are not counted against the 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
@@ -1019,7 +1019,12 @@ static int axienet_tx_poll(struct napi_struct *napi, int budget)
 			netif_wake_queue(ndev);
 	}
 
-	if (packets < budget && napi_complete_done(napi, packets)) {
+	/* The whole ring was reclaimed above, so there is nothing left to
+	 * poll for: complete with no work done, as TX completions do not
+	 * count against the budget.  netpoll polls with a budget of 0 and
+	 * must not complete NAPI.
+	 */
+	if (budget && napi_complete_done(napi, 0)) {
 		/* Re-enable TX completion interrupts. This should
 		 * cause an immediate interrupt if any TX packets are
 		 * already pending.
@@ -1028,7 +1033,7 @@ 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;
+	return 0;
 }
 
 /**

base-commit: 6dc989ea46b96ce170840174b4a38c4a387fb005
-- 
2.47.0

Re: [PATCH net v5] net: axienet: do not report TX completions as NAPI work

[netdev-bot+sinfo]

Hi!

This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:

 - What hardware the change was tested on. For driver fixes please
   mention the device (and if relevant firmware version) used for
   testing, or say that the change was not tested on real hardware.

Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account. If the series needs another revision for
other reasons, please include the information in the commit messages
then.

The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.

Re: [PATCH net v5] net: axienet: do not report TX completions as NAPI work

[Sagi Maimon]

On Sun, Oct 4, 2026 at 10:04 AM <netdev-bot+sinfo@kernel.org> wrote:
>
> Hi!
>
> This is an automated message. This series looks like a fix, but its
> commit messages seem to be missing some information:
>
>  - What hardware the change was tested on. For driver fixes please
>    mention the device (and if relevant firmware version) used for
>    testing, or say that the change was not tested on real hardware.
>

> - What hardware the change was tested on. For driver fixes please
>   mention the device (and if relevant firmware version) used for
>   testing, or say that the change was not tested on real hardware.

v5 has not been tested on real hardware; it is build-tested only.

Earlier versions of this fix were tested on the AXI Ethernet MAC (with
the built-in AXI DMA) of an ADVA TimeCard X2, a PCIe card, which is
where the "exceeding its budget" message quoted in the commit message
was seen.  v5 follows the pattern of commit a58cdf56b6eb in bcmgenet,
as suggested in the review of v4.

Sagi
> Please do not repost the series just to address the above. Instead,
> reply to this email with the missing information, so that reviewers
> can take it into account. If the series needs another revision for
> other reasons, please include the information in the commit messages
> then.
>
> The evaluation is done by an LLM so it may be wrong, if you think
> that is the case please reply and explain.