From: Kevin Traynor <ktraynor@redhat.com>
To: David Marchand <david.marchand@redhat.com>
Cc: dev@dpdk.org, thomas@monjalon.net, dsosnowski@nvidia.com,
viacheslavo@nvidia.com, stable@dpdk.org,
Harman Kalra <hkalra@marvell.com>
Subject: Re: [PATCH v2 2/2] eal/linux: handle interrupt epoll events
Date: Tue, 10 Feb 2026 14:47:05 +0000 [thread overview]
Message-ID: <8d2aed2e-87fb-4946-b96a-f0d07a11d5f2@redhat.com> (raw)
In-Reply-To: <CAJFAV8w0ic1OzGHSmLecR4bGjPCxTWuYA_yCEoxqBSR28aKo5A@mail.gmail.com>
On 10/02/2026 09:17, David Marchand wrote:
> Hello Kevin,
>
> On Fri, 6 Feb 2026 at 18:21, Kevin Traynor <ktraynor@redhat.com> wrote:
>>
>> Add handling for epoll error and disconnect conditions EPOLLERR,
>> EPOLLHUP and EPOLLRDHUP.
>>
>> These events indicate that the interrupt file descriptor is in
>> an error state or there has been a hangup.
>>
>> Only do this for interrupts that are read in eal. Interrupts that
>> are read outside eal should deal with different interrupt scenarios
>> appropriate to their functionality. e.g. virtio interrupt handling
>> has reconnect mechanisms for some cases.
>>
>> Also, treat no bytes read as an error condition.
>>
>> Bugzilla ID: 1873
>> Fixes: af75078fece3 ("first public release")
>> Cc: stable@dpdk.org
>
> Cc: Harman.
>
>>
>> Signed-off-by: Kevin Traynor <ktraynor@redhat.com>
>> ---
>> lib/eal/linux/eal_interrupts.c | 67 ++++++++++++++++++++++------------
>> 1 file changed, 44 insertions(+), 23 deletions(-)
>>
>> diff --git a/lib/eal/linux/eal_interrupts.c b/lib/eal/linux/eal_interrupts.c
>> index 9db978923a..68ca0f929e 100644
>> --- a/lib/eal/linux/eal_interrupts.c
>> +++ b/lib/eal/linux/eal_interrupts.c
>> @@ -887,4 +887,26 @@ rte_intr_disable(const struct rte_intr_handle *intr_handle)
>> }
>>
>> +static void
>> +eal_intr_source_remove_and_free(struct rte_intr_source *src)
>> +{
>> + struct rte_intr_callback *cb, *next;
>> +
>> + /* Remove the interrupt source */
>> + rte_spinlock_lock(&intr_lock);
>> + TAILQ_REMOVE(&intr_sources, src, next);
>> + rte_spinlock_unlock(&intr_lock);
>> +
>> + /* Free callbacks */
>> + for (cb = TAILQ_FIRST(&src->callbacks); cb; cb = next) {
>> + next = TAILQ_NEXT(cb, next);
>> + TAILQ_REMOVE(&src->callbacks, cb, next);
>> + free(cb);
>> + }
>> +
>> + /* Free the interrupt source */
>> + rte_intr_instance_free(src->intr_handle);
>> + free(src);
>> +}
>> +
>> static int
>> eal_intr_process_interrupts(struct epoll_event *events, int nfds)
>> @@ -952,4 +974,16 @@ eal_intr_process_interrupts(struct epoll_event *events, int nfds)
>>
>> if (bytes_read > 0) {
>> + /**
>> + * Check for epoll error or disconnect events for
>> + * interrupts that are read directly in eal.
>> + */
>> + if (events[n].events & (EPOLLERR | EPOLLHUP | EPOLLRDHUP)) {
>> + EAL_LOG(INFO, "Disconnect condition on fd %d "
>
> This is an anormal situation, I would make this log level the same as
> other logs below.
>
> The fact that the interrupt fd gets into this state should be
> something to report and investigate.
>
ok. I'll change to warning.
>
>> + "(events=0x%x), removing from epoll",
>> + events[n].data.fd, events[n].events);
>> + eal_intr_source_remove_and_free(src);
>> + return -1;
>> + }
>> +
>> /**
>> * read out to clear the ready-to-be-read flag
>> @@ -957,5 +991,7 @@ eal_intr_process_interrupts(struct epoll_event *events, int nfds)
>> */
>> bytes_read = read(events[n].data.fd, &buf, bytes_read);
>> - if (bytes_read < 0) {
>> + if (bytes_read > 0) {
>> + call = true;
>> + } else if (bytes_read < 0) {
>> if (errno == EINTR || errno == EWOULDBLOCK)
>> continue;
>> @@ -965,27 +1001,12 @@ eal_intr_process_interrupts(struct epoll_event *events, int nfds)
>> events[n].data.fd,
>> strerror(errno));
>> - /*
>> - * The device is unplugged or buggy, remove
>> - * it as an interrupt source and return to
>> - * force the wait list to be rebuilt.
>> - */
>> - rte_spinlock_lock(&intr_lock);
>> - TAILQ_REMOVE(&intr_sources, src, next);
>> - rte_spinlock_unlock(&intr_lock);
>> -
>> - for (cb = TAILQ_FIRST(&src->callbacks); cb;
>> - cb = next) {
>> - next = TAILQ_NEXT(cb, next);
>> - TAILQ_REMOVE(&src->callbacks, cb, next);
>> - free(cb);
>> - }
>> - rte_intr_instance_free(src->intr_handle);
>> - free(src);
>> - return -1;
>> - } else if (bytes_read == 0)
>> - EAL_LOG(ERR, "Read nothing from file "
>> + } else { /* bytes == 0 */
>
> "bytes_read == 0", or remove this comment as the code is quite compact
> and leaves little space for wondering what this else block is about.
>
Ack. I will take it as a compliment and remove the comment ;-)
>
>> + EAL_LOG(WARNING, "Read nothing from file "
>
> I would keep this log at the same level than the < 0 condition.
> It seems the same type of error.
>
>> "descriptor %d", events[n].data.fd);
>
> And avoid splitting the format string.
>
Ack.
>
>> - else
>> - call = true;
>> + }
>> + if (bytes_read <= 0) {
>> + eal_intr_source_remove_and_free(src);
>> + return -1;
>> + }
>> }
>>
>> --
>> 2.52.0
>>
>
> Except those nits, the fix looks correct.
>
> Acked-by: David Marchand <david.marchand@redhat.com>
>
Thanks David. I will make these changes in v3.
>
>
>
next prev parent reply other threads:[~2026-02-10 14:47 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-28 12:20 [PATCH] eal/linux: handle epoll error conditions Kevin Traynor
2026-01-29 12:51 ` Kevin Traynor
2026-02-06 17:20 ` [PATCH v2 0/2] interrupt epoll event handling Kevin Traynor
2026-02-06 17:20 ` [PATCH v2 1/2] net/mlx5: check for no data read in devx interrupt Kevin Traynor
2026-02-07 6:09 ` Stephen Hemminger
2026-02-10 15:05 ` Kevin Traynor
2026-02-10 17:05 ` Slava Ovsiienko
2026-02-10 19:07 ` Kevin Traynor
2026-02-10 20:58 ` Slava Ovsiienko
2026-02-19 14:44 ` Kevin Traynor
2026-02-06 17:20 ` [PATCH v2 2/2] eal/linux: handle interrupt epoll events Kevin Traynor
2026-02-07 6:11 ` Stephen Hemminger
2026-02-10 13:35 ` Kevin Traynor
2026-02-10 9:17 ` David Marchand
2026-02-10 14:47 ` Kevin Traynor [this message]
2026-02-10 18:06 ` [PATCH v3 0/2] interrupt epoll event handling Kevin Traynor
2026-02-10 18:06 ` [PATCH v3 1/2] net/mlx5: check for no data read in devx interrupt Kevin Traynor
2026-02-10 18:06 ` [PATCH v3 2/2] eal/linux: handle interrupt epoll events Kevin Traynor
2026-02-19 14:37 ` [PATCH v4 0/3] interrupt disconnect/error event handling Kevin Traynor
2026-02-19 14:38 ` Kevin Traynor
2026-02-19 14:38 ` [PATCH v4 1/3] eal/linux: handle interrupt epoll events Kevin Traynor
2026-02-19 14:38 ` [PATCH v4 2/3] eal/interrupt: add interrupt event info Kevin Traynor
2026-02-26 15:41 ` David Marchand
2026-03-02 11:47 ` Kevin Traynor
2026-02-19 14:38 ` [PATCH v4 3/3] net/mlx5: check devx disconnect/error interrupt events Kevin Traynor
2026-03-03 16:16 ` Slava Ovsiienko
2026-02-19 18:52 ` [PATCH v4 0/3] interrupt disconnect/error event handling Stephen Hemminger
2026-03-02 11:41 ` Kevin Traynor
2026-03-03 18:58 ` [PATCH v5 " Kevin Traynor
2026-03-03 18:58 ` [PATCH v5 1/3] eal/linux: handle interrupt epoll events Kevin Traynor
2026-03-03 18:58 ` [PATCH v5 2/3] eal/interrupt: add interrupt event info Kevin Traynor
2026-03-03 18:58 ` [PATCH v5 3/3] net/mlx5: check devx disconnect/error interrupt events Kevin Traynor
2026-03-04 11:09 ` [PATCH v5 0/3] interrupt disconnect/error event handling David Marchand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8d2aed2e-87fb-4946-b96a-f0d07a11d5f2@redhat.com \
--to=ktraynor@redhat.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=dsosnowski@nvidia.com \
--cc=hkalra@marvell.com \
--cc=stable@dpdk.org \
--cc=thomas@monjalon.net \
--cc=viacheslavo@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox