On 2/19/26 6:52 PM, Stephen Hemminger wrote: > 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. >
Thanks Stephen. I will address this on the next version.
