Re: [PATCH v4 0/3] interrupt disconnect/error event handling

Kevin Traynor
2026-03-02T11:41:11Z

On 2/19/26 6:52 PM, Stephen Hemminger wrote:
> On Thu, 19 Feb 2026 14:38:49 +0000
> Kevin Traynor <ktraynor@redhat.com> 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 <stephen@networkplumber.org>
>
> 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.
>

Thanks Stephen. I will address this on the next version.