<snip>

30/07/2021 23:44, Honnappa Nagarahalli:

quoted

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.

My concern is for the word "Wrapper". I am not sure how much we are bound by that to keep the code as a "wrapper".
The new patch does not change the high level behavior.

Are you saying you are ok with the patch without the deprecation notice?

Anyway, there is not enough meaningful acks.