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.

Reply via email to