[dpdk-dev] [PATCH] doc: abstract the behaviour of rte_ctrl_thread_create
Thomas Monjalon
thomas at monjalon.net
Sat Aug 7 16:55:08 CEST 2021
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 <honnappa.nagarahalli at arm.com>
> ---
> +* 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.
More information about the dev
mailing list