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.