On Mon, 2 Nov 2026 07:08:09 +0000
Orgad Shaneh <[email protected]> wrote:
> Rx interrupt enable and disable take the per-device reset_ops_lock
> with a trylock and return -EBUSY when it is held. Every Rx queue
> takes that lock on each enable and disable, so with two or more
> queues on different lcores the calls collide routinely. A failed
> enable leaves the CQ unarmed, and a thread that then sleeps in
> rte_epoll_wait() is not woken by the next packet; it sleeps until
> its timeout with packets in the ring. A failed disable leaves the
> event unconsumed. Applications do not expect -EBUSY from these
> calls outside a reset, and l3fwd-power ignores the return value.
>
> Seen on Azure (MANA VF) with 2 queues and a 10 ms epoll timeout:
> about 550 lost wakeups per queue in one run, p99 latency 9.9 ms,
> and 22.7% packet loss at the higher rate tested. With one queue
> there was no loss.
>
> The section under the lock is a doorbell write or a non-blocking
> read of the completion channel, so wait for the lock instead.
> The device state check is kept, so the calls still return -EBUSY
> while a reset is in progress; a caller that arrives while the reset
> thread holds the lock waits for that step to finish first.
>
> Fixes: 077ca514d641 ("net/mana: support device reset")
> Cc: [email protected]
>
> Signed-off-by: Orgad Shaneh <[email protected]>
> ---
Since this is better than current main I applied it to next-net
AI review noted:
Patch 2/2
---------
Info: blocking can be long while a reset is in progress.
The reset thread holds reset_ops_lock across mana_dev_stop(),
mana_mp_req_on_rxtx(RESET_ENTER) and mana_dev_close(). On reset
exit it holds it across ibv_close_device(), mana_pci_probe(),
mana_mp_req_on_rxtx(RESET_EXIT) and mana_dev_start(). Each mp
request is rte_mp_request_sync() with MANA_MP_REQ_TIMEOUT_SEC (5 s).
An lcore that calls rte_eth_dev_rx_intr_enable() during one of
those steps can block for several seconds instead of getting
-EBUSY at once.
No deadlock results: mana_reset_enter() only spins on the
burst_state busy bit, which an lcore in rx_intr_enable/disable
does not hold, and the ethdev event callbacks are all emitted after
the lock is dropped. This is acceptable for a stable fix. It would
help to say "may block for the duration of the reset teardown or
re-probe step" in the commit message, rather than "waits for that
step to finish".
The burst_state gate mentioned below the --- is the better
long-term design, since it avoids putting every queue's
sleep/wakeup through one device mutex. Fine as a follow-up for
main; not needed for this fix.
