Re: [dpdk-dev] [PATCH] doc: abstract the behaviour of rte_ctrl_thread_create

[Thomas Monjalon <thomas@monjalon.net>]

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