Re: [PATCH net-next] net: bcmgenet: complete Tx NAPI after one reclaim pass

[Nicolai Buchwitz]

On 28.9.2026 15:14, Eric Dumazet wrote:

> [...]

> Reviewed-by: Eric Dumazet <edumazet@xxxxxxxxxx>
>
> As a follow-up, you can get rid of ring->lock in the TX
> fastpath altogether (it looks like a leftover from before TX reclaim
> was moved to NAPI in commit 4092e6acf5cb ("net: bcmgenet: use NAPI for
> Tx completion")).

Thanks Eric, makes sense. I'll sent a follow up along with some some 
other findings.

> bcmgenet_xmit() is already serialized by the netdev queue lock, and
> bcmgenet_tx_poll() by NAPI. To make them lockless with respect to each
> other:
>
> 1. Drop ring->free_bds and compute available space from
>    (READ_ONCE(ring->prod_index) - READ_ONCE(ring->c_index)) & 
> DMA_C_INDEX_MASK.
> 2. Use the lockless queue stop/wake helpers from <net/pkt_sched.h>
>    (netif_txq_maybe_stop() and __netif_txq_completed_wake()).
> 3. Ensure proper memory barriers between populating tx_cb_ptr /
>    writing TDMA_PROD_INDEX in bcmgenet_xmit() and reading
>    TDMA_CONS_INDEX / freeing tx_cbs in __bcmgenet_tx_reclaim() (since
>    bcmgenet uses readl_relaxed/writel_relaxed).
> 4. Avoid sharing ring->stats64.syncp between bcmgenet_add_tsb()
>    (tx_dropped) and __bcmgenet_tx_reclaim(), and serialize
>    bcmgenet_timeout() with napi_disable() + __netif_tx_lock_bh().

The timeout path needs rework anyway. It currently resets the ring
while TDMA is still running, which it definitely shouldn't.

> [...]

Regards,
Nicolai