Re: [dpdk-dev] [PATCH] doc: abstract the behaviour of rte_ctrl_thread_create
From: Thomas Monjalon <hidden>
Date: 2021-08-07 14:55:17
30/07/2021 23:44, Honnappa Nagarahalli:
The current expected behaviour of the function rte_ctrl_thread_create is rigid which makes the implementation of the function complex. Make the expected behaviour abstract to allow for simplified implementation. With this change, the calls to pthread_setaffinity_np can be moved to the control thread. This will avoid the use of pthread_barrier_wait and simplify the synchronization mechanism between rte_ctrl_thread_create and the calling thread. Signed-off-by: Honnappa Nagarahalli <redacted> --- +* eal: The expected behaviour of the function ``rte_ctrl_thread_create`` + abstracted to allow for simplified implementation. The new behaviour is + as follows: + Creates a control thread with the given name. The affinity of the new + thread is based on the CPU affinity retrieved at the time rte_eal_init() + was called, the dataplane and service lcores are then excluded.
I don't understand what is different of the current API: * Wrapper to pthread_create(), pthread_setname_np() and * pthread_setaffinity_np(). The affinity of the new thread is based * on the CPU affinity retrieved at the time rte_eal_init() was called, * the dataplane and service lcores are then excluded. Anyway, there is not enough meaningful acks.