Re: [PATCH net-next V2] net: axienet: Clear stale AXI DMA TX/RX status before re-enabling interrupts

[Jakub Kicinski]

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
net: axienet: Clear stale AXI DMA TX/RX status before re-enabling interrupts

This patch clears the AXI DMA IOC/DELAY status bits at the end of the TX
and RX NAPI poll handlers to avoid a redundant stale interrupt caused by
IOC/DELAY bits latched into the status register while interrupts were
masked in the control register during NAPI. The clear is performed
unconditionally, before the napi_complete_done() / CR re-enable step.

> diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> index fcf517069d16..29050c8d04e2 100644
> --- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> +++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> @@ -1018,6 +1018,13 @@ static int axienet_tx_poll(struct napi_struct *napi, int budget)
>  			netif_wake_queue(ndev);
>  	}
>  
> +	/* Clear stale IOC/DELAY bits that may have latched during the
> +	 * poll window to prevent a stale interrupt when there is no
> +	 * work pending.
> +	 */
> +	axienet_dma_out32(lp, XAXIDMA_TX_SR_OFFSET,
> +			  XAXIDMA_IRQ_IOC_MASK | XAXIDMA_IRQ_DELAY_MASK);
> +
>  	if (packets < budget && napi_complete_done(napi, packets)) {
>  		/* Re-enable TX completion interrupts. This should
>  		 * cause an immediate interrupt if any TX packets are

[High]
Can this sequence race with a late completion arriving after the poll
loop has exited but before the SR write?

The AXI DMA engine writes cur_p->status and latches SR.IOC asynchronously
from CPU execution. The poll loop's exit condition reads cur_p->status,
and between that read and the unconditional SR IOC/DELAY clear that this
hunk adds, the hardware can set COMPLETE_MASK on the next BD and latch
SR.IOC for it. That legitimate notification would then be wiped by the
new W1C write.

Since napi_schedule() is only called from the ISR, and the ISR only fires
when the IRQ line asserts, napi_complete_done() will succeed here even
though a new completion has appeared. The subsequent CR re-enable would
then observe SR.IOC=0, so the level-sensitive line does not re-assert,
and the completed BD is stranded until the next unrelated completion or
DELAY-timer expiry moves things forward.

Before this patch, any SR bit latched during the poll window (whether
stale or from a late completion) re-asserted the IRQ line after CR
re-enable, which the changelog frames purely as an unnecessary stale
interrupt:

    After NAPI completion, re-enabling interrupts immediately
    re-asserts the IRQ line due to these stale status register bits,
    even when no new work is pending.

Did that same behavior also serve as the recovery path for a completion
that lands in the SR-clear/CR-reenable window? If so, would it be worth
either re-checking cur_p->status after the SR clear and skipping
napi_complete_done() when new work has appeared, or performing the CR
re-enable before the SR clear so a late latch still asserts the line?

NAPIF_STATE_MISSED does not appear to help here because it requires a
napi_schedule() call, which only the ISR performs.

For configurations where axienet_calc_cr() does arm the DELAY timer
(coalesce count > 1), the stranded BD is recovered when DELAY expires:

    /* Only set interrupt delay timer if not generating an interrupt on
     * every packet
     */

Under DIM with low traffic the coalesce count can settle at 1, in which
case DELAY is not armed and there is no bounded recovery for the last
BD of a burst until another packet arrives. Is that concern valid, or is
there another mechanism that ensures the last BD is drained?

> @@ -1293,6 +1300,13 @@ static int axienet_rx_poll(struct napi_struct *napi, int budget)
>  		cur_p = &lp->rx_bd_v[lp->rx_bd_ci];
>  	}
>  
> +	/* Clear stale IOC/DELAY bits that may have latched during the
> +	 * poll window to prevent a stale interrupt when there is no
> +	 * work pending.
> +	 */
> +	axienet_dma_out32(lp, XAXIDMA_RX_SR_OFFSET,
> +			  XAXIDMA_IRQ_IOC_MASK | XAXIDMA_IRQ_DELAY_MASK);
> +

The same question applies to the RX path: a completion arriving after
the while loop's cur_p->status check but before this SR write would have
its SR.IOC latch cleared, and the subsequent CR re-enable would then not
re-assert the line. Is there a reason the RX path is not exposed to the
same race?
-- 
pw-bot: cr