On Thu, 19 Feb 2026 14:38:49 +0000
Kevin Traynor <[email protected]> wrote:

> These patches are to fix some issues with epoll event handling for
> EPOLLERR/EPOLLRDHUP/EPOLLHUP.
> 
> 1/3: handles these disconnect/error events for interrupts that are read
> in eal
> 
> 2/3: provides an API for interrupt callbacks to get the interrupt events
> for the active interrupt
> 
> 3/3: deal with the observed issue as reported in
> https://bugs.dpdk.org/show_bug.cgi?id=1873 where mlx5 devx interrupts
> cause a busy-loop and 100% CPU of dpdk-intr thread.
> 
> v4:
> Updated to allow for case where devx interrupt handler may handle
> multiple completions during one interrupt call, leading to no data being
> read in a subsequent call as flagged by Slava.
> 
> - 1/3 No change
> - 2/3 New API rte_intr_active_events() to get interrupt events
> - 3/3 Use new API in mlx5 devx interrupt handler to detect if
>   disconnect/error events and if so unregister the callback
> 
> v3:
> - 1/2 and 2/2 fix some coding nits (Stephen/AI/David)
> - 2/2 Make log level consistant (David)
> 
> v2:
> - Only handle disconnect/error epoll events when the read is done in eal
>   interrupt code. This is to allow interrupt handlers like virtio deal
>   with disconnects in an appropriate
> - Detect if not data is read in the mlx dex interrupt and if so unregister
>   the callback
> 
> Kevin Traynor (3):
>   eal/linux: handle interrupt epoll events
>   eal/interrupt: add interrupt event info
>   net/mlx5: check devx disconnect/error interrupt events
> 
>  drivers/net/mlx5/linux/mlx5_ethdev_os.c |  20 +++++
>  lib/eal/freebsd/eal_interrupts.c        |   7 ++
>  lib/eal/include/rte_interrupts.h        |  23 ++++++
>  lib/eal/linux/eal_interrupts.c          | 103 +++++++++++++++++-------
>  lib/eal/windows/eal_interrupts.c        |   7 ++
>  5 files changed, 133 insertions(+), 27 deletions(-)
> 

Series-Acked-by: Stephen Hemminger <[email protected]>

FYI - AI review gives long winded version of "this is patch is good"
The only worthwhile feedback was that there should be a release note for
a new API.

Reply via email to