On Fri, 2023-09-22 at 13:12 +0200, Christian Marangi wrote:
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 9201ed778ebc..14bf6fae6662 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -2994,13 +2994,25 @@ static void stmmac_tx_timer_arm(struct stmmac_priv *priv, u32 queue)
> {
> struct stmmac_tx_queue *tx_q = &priv->dma_conf.tx_queue[queue];
> u32 tx_coal_timer = priv->tx_coal_timer[queue];
> + struct stmmac_channel *ch;
> + struct napi_struct *napi;
>
>
> if (!tx_coal_timer)
> return;
>
>
> - hrtimer_start(&tx_q->txtimer,
> - STMMAC_COAL_TIMER(tx_coal_timer),
> - HRTIMER_MODE_REL);
> + ch = &priv->channel[tx_q->queue_index];
> + napi = tx_q->xsk_pool ? &ch->rxtx_napi : &ch->tx_napi;
> +
> + /* Arm timer only if napi is not already scheduled.
> + * Try to cancel any timer if napi is scheduled, timer will be armed
> + * again in the next scheduled napi.
> + */
> + if (unlikely(!napi_is_scheduled(napi)))
> + hrtimer_start(&tx_q->txtimer,
> + STMMAC_COAL_TIMER(tx_coal_timer),
> + HRTIMER_MODE_REL);
> + else
> + hrtimer_try_to_cancel(&tx_q->txtimer);
When this function is called from within the napi poll function
(stmmac_tx_clean()), NAPI_STATE_SCHED will always be set and so after
this patch the "We still have pending packets, let's call for a new
scheduling" logic will never start the timer. Was that really
intentional?
