DPDK patches and discussions
 help / color / mirror / Atom feed
* rte_control event API?
@ 2025-05-01 15:06 Stephen Hemminger
  0 siblings, 0 replies; only message in thread
From: Stephen Hemminger @ 2025-05-01 15:06 UTC (permalink / raw)
  To: techboard; +Cc: dev

There was recent discussions about drivers creating control threads.
The current drivers that use rte_thread_create_internal_control keeps growing, 
but it got me looking at if this could be done better.

Rather than having multiple control threads which have potential conflicts, why not
add a new API that has one control thread and uses epoll. The current multi-process
control thread could use epoll as well. Epoll scales much better and avoids
any possibility of lock scheduling/priority problems.

Some ideas:
   - single control thread started (where the current MP thread is started)
   - have control_register_fd and control_unregister_fd
   - leave rte_control_thread API for legacy uses

Model this after well used libevent library https://libevent.org

Open questions:
   - names are hard, using event as name leads to possible confusion with eventdev
   - do we need to support:
        - multiple control threads doing epoll?
        - priorities
        - timers?
        - signals?
        - manual activation?
        - one off events?
   - could alarm thread just be a control event

   - should also have stats and info calls

   - it would be good to NOT support as many features as libevent, since
     so many options leads to bugs.

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2025-05-01 15:06 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-05-01 15:06 rte_control event API? Stephen Hemminger

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).