DPDK usage discussions
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: Alan Beadle <ab.beadle@gmail.com>
Cc: users@dpdk.org
Subject: Re: Questions about interrupts
Date: Thu, 13 Feb 2025 14:26:13 -0800	[thread overview]
Message-ID: <20250213142613.23d52f6b@hermes.local> (raw)
In-Reply-To: <CANTAOdzuSS0zdSW5L_+8obbaG-nh7nXy=qXFR3YsaxaxDA5YdA@mail.gmail.com>

On Thu, 13 Feb 2025 16:55:57 -0500
Alan Beadle <ab.beadle@gmail.com> wrote:

> Hello,
> 
> I am trying to use rte_epoll_wait() to avoid rx polling and reduce CPU
> utilization while preserving low latency. I am using the Intel X550-T2
> NIC with DPDK 23.11 and the ixgbe driver.
> 
> I was able to make interrupts work and my process is getting
> interrupts when a packet arrives. I followed the example here:
> https://stackoverflow.com/questions/69792978/using-interrupts-with-dpdk
> 
> Before calling rte_epoll_wait(), I must first arm the interrupt by
> calling rte_eth_dev_rx_intr_enable() every time my thread is about to
> wait. However, if a packet arrives between these calls, the interrupt
> will not work and my process will only resume once the timeout is
> reached. This causes huge latency spikes unless my timeout is very
> short, and the minimum time of 1ms is still too long to tolerate this
> problem, since my goal is to keep latency low.

After enabling interrupts, the application should do one more call to rx_burst
which will see if there any packets that raced in.
If it does get some packets, chances are you want to disable interrupts
and go back to polling mode.

See the l3fwd-power example application.


> Here are my questions:
> 1) Is there a way to prevent the thread from suspending at all if the
> interrupt is not "armed" anymore?
> 2) Is it possible to set a timeout shorter than 1 ms? It looks like
> this is not supported by rte_epoll_wait().

Internally rte_epoll_wait is just a wrapper around the epoll system
call. which takes a timeout in milliseconds.

You could make a version of rte_epoll_wait using the newer epoll_pwait2
system call which accepts a timeout in nanosecond resolution.

Read the source of EAL, it is much easier than trying to explain
all this.

  reply	other threads:[~2025-02-13 22:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-13 21:55 Alan Beadle
2025-02-13 22:26 ` Stephen Hemminger [this message]
2025-02-15 15:55   ` Alan Beadle
2025-02-15 15:59     ` Stephen Hemminger

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=20250213142613.23d52f6b@hermes.local \
    --to=stephen@networkplumber.org \
    --cc=ab.beadle@gmail.com \
    --cc=users@dpdk.org \
    /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;
as well as URLs for NNTP newsgroup(s).