Thread (8 messages) 8 messages, 5 authors, 2021-08-23

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.

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help