RE: How to rte_epoll_wait for IPC?

["Morten Brørup" <mb@smartsharesystems.com>]

> From: Honnappa Nagarahalli [mailto:Honnappa.Nagarahalli@arm.com]
> Sent: Friday, 6 October 2023 17.27
> 
> > From: Morten Brørup <mb@smartsharesystems.com>
> > Sent: Friday, October 6, 2023 5:04 AM
> >
> > Dear Harman, Anatoly and David,
> >
> > I have been looking somewhat into power management, and have a
> question
> > about rte_epoll:
> >
> > Can I use rte_epoll to wait for an event (or interrupt/signal) in one
> EAL thread,
> > generated by another EAL thread?
> >
> > Here's a simple use case with two EAL threads:
> >
> > 1. The "ingress" thread receives its packets from the NICs, filters
> the packets
> > and puts them into a an rte_ring for the "processing" thread. The
> "ingress"
> > thread can sleep and use RX interrupts to wake up, as shown in the
> l3fwd-
> > power example. All good.
> >
> > 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?
> This feature is supported by using rte_wait_until_equal_xx APIs in
> rte_ring.

Thank you for the suggestion, Honnappa.

rte_wait_until_equal_xx would be an excellent solution for physical appliances.

However, I am looking for O/S level sleeping, like epoll(), so the hypervisor can detect that the thread is idle. (I should have mentioned this!)

> 
> >
> >
> > In a generic scenario, an EAL thread could be rte_epoll_wait'ing for a
> variety of
> > event sources. This may require a different, more advanced, solution.
> >
> > A solution to the simple use case suffices.
> >
> >
> > PS: I'm using the standard acronym IPC in the subject, although I'm
> asking
> > about Inter Thread Communication, not Inter Process Communication. I'm
> not
> > looking for a multi process solution.
> >
> >
> > Med venlig hilsen / Kind regards,
> > -Morten Brørup