All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: "Morten Brørup" <mb@smartsharesystems.com>
Cc: "Harman Kalra" <hkalra@marvell.com>,
	"Anatoly Burakov" <anatoly.burakov@intel.com>,
	"David Hunt" <david.hunt@intel.com>, <dev@dpdk.org>,
	<honnappa.nagarahalli@arm.com>, <nd@arm.com>
Subject: Re: How to rte_epoll_wait for IPC?
Date: Fri, 6 Oct 2023 10:04:12 -0700	[thread overview]
Message-ID: <20231006100412.5e8e9ef2@hermes.local> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9EF09@smartserver.smartshare.dk>

On Fri, 6 Oct 2023 18:28:10 +0200
Morten Brørup <mb@smartsharesystems.com> wrote:

> > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > Sent: Friday, 6 October 2023 18.03
> > 
> > On Fri, 6 Oct 2023 12:03:46 +0200
> > Morten Brørup <mb@smartsharesystems.com> wrote:
> >   
> > > 2. The "processing" thread receives its packets from the rte_ring.  
> > This thread should sleep until packets are ready for it in the rte_ring.  
> > >
> > > The "ingress" thread knows when it puts packets into the rte_ring, so  
> > it can signal that event to the "processing" thread, to wake it up;
> > either as an interrupt/signal, or through a file descriptor. Is this
> > supported by rte_epoll (or other DPDK APIs), and how?
> > 
> > When having to do this in applications, I used a eventfd() as well as
> > the rte ring.
> > The ingress write's to eventfd and the other thread used epoll on the
> > fd.
> > 
> > Optimized this by having the ingress thread only signal via write if
> > ring was in empty state.
> > And the reader thread only needs to do (epoll/read) if ring became empty
> > during last cycle;
> > i.e num packets from rte_ring_burst() was 0.
> > 
> > Basically, when using epoll and other SW event models, you need to turn
> > all data sources
> > into file descriptors.  
> 
> This sounds exactly like what I am looking for.
> 
> Are there DPDK APIs for eventfd(), so I can use them with rte_epoll_wait?

Eventfd is just a system call.

You then add the resulting fd to epoll object with rte_epoll_ctl().


      reply	other threads:[~2023-10-06 17:04 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-06 10:03 How to rte_epoll_wait for IPC? Morten Brørup
2023-10-06 15:27 ` Honnappa Nagarahalli
2023-10-06 15:53   ` Morten Brørup
2023-10-30 13:07     ` Honnappa Nagarahalli
2023-10-06 16:03 ` Stephen Hemminger
2023-10-06 16:28   ` Morten Brørup
2023-10-06 17:04     ` Stephen Hemminger [this message]

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=20231006100412.5e8e9ef2@hermes.local \
    --to=stephen@networkplumber.org \
    --cc=anatoly.burakov@intel.com \
    --cc=david.hunt@intel.com \
    --cc=dev@dpdk.org \
    --cc=hkalra@marvell.com \
    --cc=honnappa.nagarahalli@arm.com \
    --cc=mb@smartsharesystems.com \
    --cc=nd@arm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.