[v16,2/9] eal: add thread attributes
Checks
Commit Message
From: Narcisa Vasile <navasile@microsoft.com>
Implement thread attributes for:
* thread affinity
* thread priority
Implement functions for managing thread attributes.
Priority is represented through an enum that allows for two levels:
- RTE_THREAD_PRIORITY_NORMAL
- RTE_THREAD_PRIORITY_REALTIME_CRITICAL
Affinity is described by the rte_cpuset_t type.
An rte_thread_attr_t object can be set to the default values
by calling rte_thread_attr_init().
Signed-off-by: Narcisa Vasile <navasile@microsoft.com>
---
lib/eal/common/rte_thread.c | 46 ++++++++++++++++++
lib/eal/include/rte_thread.h | 91 ++++++++++++++++++++++++++++++++++++
lib/eal/version.map | 4 ++
lib/eal/windows/rte_thread.c | 44 +++++++++++++++++
4 files changed, 185 insertions(+)
Comments
09/10/2021 09:41, Narcisa Ana Maria Vasile:
> From: Narcisa Vasile <navasile@microsoft.com>
>
> Implement thread attributes for:
> * thread affinity
> * thread priority
> Implement functions for managing thread attributes.
>
> Priority is represented through an enum that allows for two levels:
> - RTE_THREAD_PRIORITY_NORMAL
> - RTE_THREAD_PRIORITY_REALTIME_CRITICAL
It doesn't say how do you translate these priorites in POSIX and win32.
> Affinity is described by the rte_cpuset_t type.
>
> An rte_thread_attr_t object can be set to the default values
> by calling rte_thread_attr_init().
>
> Signed-off-by: Narcisa Vasile <navasile@microsoft.com>
[...]
> lib/eal/common/rte_thread.c | 46 ++++++++++++++++++
> lib/eal/windows/rte_thread.c | 44 +++++++++++++++++
These 2 files look like code duplication.
On Tue, Oct 12, 2021 at 06:12:21PM +0200, Thomas Monjalon wrote:
> 09/10/2021 09:41, Narcisa Ana Maria Vasile:
> > From: Narcisa Vasile <navasile@microsoft.com>
> >
> > Implement thread attributes for:
> > * thread affinity
> > * thread priority
> > Implement functions for managing thread attributes.
> >
> > Priority is represented through an enum that allows for two levels:
> > - RTE_THREAD_PRIORITY_NORMAL
> > - RTE_THREAD_PRIORITY_REALTIME_CRITICAL
>
> It doesn't say how do you translate these priorites in POSIX and win32.
I'll send a new version with a better commit message.
Thread priorities on both Linux-based and Windows platforms are similarly
constructed from a class/policy + priority value. Currently in DPDK, most threads
operate at the OS-default priority level but there are cases when increasing the
priority is useful. For example, the Mellanox data path acceleration driver requires
realtime thread priority. Similarly, some Windows applications will require elevated
priority.
For these reasons, EAL will advertise 2 priority levels which are named suggestively
"normal" and "realtime_critical" and are computed as follows:
For Linux and similar platforms:
* EAL "normal" priority corresponds to the (default) SCHED_OTHER policy + a priority value of
(sched_get_priority_min(SCHED_OTHER) + sched_get_priority_max(SCHED_OTHER))/2.
Note that on Linux the resulting priority value will be 0,
in accordance to the docs guidance that mention the value should be 0 for SCHED_OTHER policy.
* EAL "realtime" priority corresponds to the SCHED_RR policy + a priority value of
sched_get_priority_max(SCHED_RR);
For Windows:
* EAL "normal" corresponds to class NORMAL_PRIORITY_CLASS +
priority THREAD_PRIORITY_NORMAL
* EAL "realtime_critical" corresponds to class REALTIME_PRIORITY_CLASS +
priority THREAD_PRIORITY_TIME_CRITICAL
>
> > Affinity is described by the rte_cpuset_t type.
> >
> > An rte_thread_attr_t object can be set to the default values
> > by calling rte_thread_attr_init().
> >
> > Signed-off-by: Narcisa Vasile <navasile@microsoft.com>
> [...]
> > lib/eal/common/rte_thread.c | 46 ++++++++++++++++++
> > lib/eal/windows/rte_thread.c | 44 +++++++++++++++++
>
> These 2 files look like code duplication.
>
>
09/11/2021 02:59, Narcisa Ana Maria Vasile:
> On Tue, Oct 12, 2021 at 06:12:21PM +0200, Thomas Monjalon wrote:
> > 09/10/2021 09:41, Narcisa Ana Maria Vasile:
> > > From: Narcisa Vasile <navasile@microsoft.com>
> > >
> > > Implement thread attributes for:
> > > * thread affinity
> > > * thread priority
> > > Implement functions for managing thread attributes.
> > >
> > > Priority is represented through an enum that allows for two levels:
> > > - RTE_THREAD_PRIORITY_NORMAL
> > > - RTE_THREAD_PRIORITY_REALTIME_CRITICAL
> >
> > It doesn't say how do you translate these priorites in POSIX and win32.
>
> I'll send a new version with a better commit message.
> Thread priorities on both Linux-based and Windows platforms are similarly
> constructed from a class/policy + priority value. Currently in DPDK, most threads
> operate at the OS-default priority level but there are cases when increasing the
> priority is useful. For example, the Mellanox data path acceleration driver requires
> realtime thread priority. Similarly, some Windows applications will require elevated
> priority.
It should not. We should not use realtime priority.
> For these reasons, EAL will advertise 2 priority levels which are named suggestively
> "normal" and "realtime_critical" and are computed as follows:
>
> For Linux and similar platforms:
> * EAL "normal" priority corresponds to the (default) SCHED_OTHER policy + a priority value of
> (sched_get_priority_min(SCHED_OTHER) + sched_get_priority_max(SCHED_OTHER))/2.
> Note that on Linux the resulting priority value will be 0,
> in accordance to the docs guidance that mention the value should be 0 for SCHED_OTHER policy.
>
> * EAL "realtime" priority corresponds to the SCHED_RR policy + a priority value of
> sched_get_priority_max(SCHED_RR);
>
> For Windows:
> * EAL "normal" corresponds to class NORMAL_PRIORITY_CLASS +
> priority THREAD_PRIORITY_NORMAL
> * EAL "realtime_critical" corresponds to class REALTIME_PRIORITY_CLASS +
> priority THREAD_PRIORITY_TIME_CRITICAL
On Tue, Nov 09, 2021 at 09:27:09AM +0100, Thomas Monjalon wrote:
> 09/11/2021 02:59, Narcisa Ana Maria Vasile:
> > On Tue, Oct 12, 2021 at 06:12:21PM +0200, Thomas Monjalon wrote:
> > > 09/10/2021 09:41, Narcisa Ana Maria Vasile:
> > > > From: Narcisa Vasile <navasile@microsoft.com>
> > > >
> > > > Implement thread attributes for:
> > > > * thread affinity
> > > > * thread priority
> > > > Implement functions for managing thread attributes.
> > > >
> > > > Priority is represented through an enum that allows for two levels:
> > > > - RTE_THREAD_PRIORITY_NORMAL
> > > > - RTE_THREAD_PRIORITY_REALTIME_CRITICAL
> > >
> > > It doesn't say how do you translate these priorites in POSIX and win32.
> >
> > I'll send a new version with a better commit message.
> > Thread priorities on both Linux-based and Windows platforms are similarly
> > constructed from a class/policy + priority value. Currently in DPDK, most threads
> > operate at the OS-default priority level but there are cases when increasing the
> > priority is useful. For example, the Mellanox data path acceleration driver requires
> > realtime thread priority. Similarly, some Windows applications will require elevated
> > priority.
>
> It should not. We should not use realtime priority.
Thomas, can you join the community sync tomorrow? I'll bring this up to discuss.
High performance applications benefit from an option to raise the priority of their threads
to avoid being preemted by other threads on the system. If there are issues with realtime
priority on some of the platforms, maybe we can add a warning for the user to make them
aware of possible crashes as Stephen H. suggested some time ago. Note that this patch doesn't
change the priority of EAL threads, enabling the higher priority will be done through a command
line option when starting the application.
Maybe we can explore raising the priority but not to the realtime level.
>
> > For these reasons, EAL will advertise 2 priority levels which are named suggestively
> > "normal" and "realtime_critical" and are computed as follows:
> >
> > For Linux and similar platforms:
> > * EAL "normal" priority corresponds to the (default) SCHED_OTHER policy + a priority value of
> > (sched_get_priority_min(SCHED_OTHER) + sched_get_priority_max(SCHED_OTHER))/2.
> > Note that on Linux the resulting priority value will be 0,
> > in accordance to the docs guidance that mention the value should be 0 for SCHED_OTHER policy.
> >
> > * EAL "realtime" priority corresponds to the SCHED_RR policy + a priority value of
> > sched_get_priority_max(SCHED_RR);
> >
> > For Windows:
> > * EAL "normal" corresponds to class NORMAL_PRIORITY_CLASS +
> > priority THREAD_PRIORITY_NORMAL
> > * EAL "realtime_critical" corresponds to class REALTIME_PRIORITY_CLASS +
> > priority THREAD_PRIORITY_TIME_CRITICAL
>
>
On Tue, 9 Nov 2021 19:04:17 -0800
Narcisa Ana Maria Vasile <navasile@linux.microsoft.com> wrote:
> > > I'll send a new version with a better commit message.
> > > Thread priorities on both Linux-based and Windows platforms are similarly
> > > constructed from a class/policy + priority value. Currently in DPDK, most threads
> > > operate at the OS-default priority level but there are cases when increasing the
> > > priority is useful. For example, the Mellanox data path acceleration driver requires
> > > realtime thread priority. Similarly, some Windows applications will require elevated
> > > priority.
> >
> > It should not. We should not use realtime priority.
>
> Thomas, can you join the community sync tomorrow? I'll bring this up to discuss.
>
> High performance applications benefit from an option to raise the priority of their threads
> to avoid being preemted by other threads on the system. If there are issues with realtime
> priority on some of the platforms, maybe we can add a warning for the user to make them
> aware of possible crashes as Stephen H. suggested some time ago. Note that this patch doesn't
> change the priority of EAL threads, enabling the higher priority will be done through a command
> line option when starting the application.
> Maybe we can explore raising the priority but not to the realtime level.
Let me put it more succulently.
Almost all DPDK applications have threads that are a 100% CPU doing polling.
Putting those thread as real-time thread breaks Linux badly because the kernel
can and will try and run work on those CPU's and the system is broken/unstable/dead
at that point.
This is a case of different definitions and expectations of real-time in
Linux and Windows. Linux definition of real-time priority is for well behaved
and time critical applications. It expects RT applications to run, then sleep.
-----Original Message-----
From: Stephen Hemminger <stephen@networkplumber.org>
Sent: Tuesday, November 9, 2021 8:00 PM
To: Narcisa Ana Maria Vasile <navasile@linux.microsoft.com>
Cc: thomas <thomas@monjalon.net>; dev@dpdk.org; Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>; Khoa To <khot@microsoft.com>; Dmitry Malloy <dmitrym@microsoft.com>; Tyler Retzlaff <roretzla@microsoft.com>; talshn <talshn@mellanox.com>; Omar Cardona <ocardona@microsoft.com>; bruce.richardson@intel.com; david.marchand@redhat.com; Kadam, Pallavi <pallavi.kadam@intel.com>
Subject: [EXTERNAL] Re: [dpdk-dev] [PATCH v16 2/9] eal: add thread attributes
On Tue, 9 Nov 2021 19:04:17 -0800
Narcisa Ana Maria Vasile <navasile@linux.microsoft.com> wrote:
> > > > I'll send a new version with a better commit message.
> > > > Thread priorities on both Linux-based and Windows platforms are similarly
> > > > constructed from a class/policy + priority value. Currently in DPDK, most threads
> > > > operate at the OS-default priority level but there are cases when increasing the
> > > > priority is useful. For example, the Mellanox data path acceleration driver requires
> > > > realtime thread priority. Similarly, some Windows applications will require elevated
> > > > priority.
> > >
> > > It should not. We should not use realtime priority.
> >
> > Thomas, can you join the community sync tomorrow? I'll bring this up to discuss.
> >
> > High performance applications benefit from an option to raise the
> > priority of their threads to avoid being preemted by other threads on
> > the system. If there are issues with realtime priority on some of the
> > platforms, maybe we can add a warning for the user to make them aware
> > of possible crashes as Stephen H. suggested some time ago. Note that
> > this patch doesn't change the priority of EAL threads, enabling the higher priority will be done through a command line option when starting the application.
> > Maybe we can explore raising the priority but not to the realtime level.
> Let me put it more succulently.
> Almost all DPDK applications have threads that are a 100% CPU doing polling.
> Putting those thread as real-time thread breaks Linux badly because the kernel can and will try and run work on those CPU's and the system is broken/unstable/dead at that point.
The suggestion is that when running on Windows it should be possible for the application to be configured to use real-time threads, there is no implication that it will force real-time priority on Linux. If it doesn't make sense for it to be configured on Linux then don't configure it. But saying it shall not be configurable for any platform just because one platform can't make use of the configuration and those platforms have to run compromised makes little sense. Linux administrators are (or should be) knowledgeable enough to know what configuration to use.
> > This is a case of different definitions and expectations of real-time in Linux and Windows. Linux definition of real-time priority is for well behaved and time critical applications. It expects RT applications to run, then sleep.
On Wed, 10 Nov 2021 04:20:52 +0000
Tyler Retzlaff <roretzla@microsoft.com> wrote:
> > >
> > > High performance applications benefit from an option to raise the
> > > priority of their threads to avoid being preemted by other threads on
> > > the system. If there are issues with realtime priority on some of the
> > > platforms, maybe we can add a warning for the user to make them aware
> > > of possible crashes as Stephen H. suggested some time ago. Note that
> > > this patch doesn't change the priority of EAL threads, enabling the higher priority will be done through a command line option when starting the application.
> > > Maybe we can explore raising the priority but not to the realtime level.
>
> > Let me put it more succulently.
> > Almost all DPDK applications have threads that are a 100% CPU doing polling.
> > Putting those thread as real-time thread breaks Linux badly because the kernel can and will try and run work on those CPU's and the system is broken/unstable/dead at that point.
>
> The suggestion is that when running on Windows it should be possible for the application to be configured to use real-time threads, there is no implication that it will force real-time priority on Linux. If it doesn't make sense for it to be configured on Linux then don't configure it. But saying it shall not be configurable for any platform just because one platform can't make use of the configuration and those platforms have to run compromised makes little sense. Linux administrators are (or should be) knowledgeable enough to know what configuration to use.
>
Why not just make it always return an error when real-time is requested on Linux from a DPDK thread.
The experience on the mailing list is that users will find trouble.
Maybe it is just that the sampling is biased. Users that are knowledgeable or figure out
problems themselves don't come to the mailing list.
On Tue, Nov 09, 2021 at 10:29:25PM -0800, Stephen Hemminger wrote:
> On Wed, 10 Nov 2021 04:20:52 +0000
> Tyler Retzlaff <roretzla@microsoft.com> wrote:
>
> > > >
> > > > High performance applications benefit from an option to raise the
> > > > priority of their threads to avoid being preemted by other threads on
> > > > the system. If there are issues with realtime priority on some of the
> > > > platforms, maybe we can add a warning for the user to make them aware
> > > > of possible crashes as Stephen H. suggested some time ago. Note that
> > > > this patch doesn't change the priority of EAL threads, enabling the higher priority will be done through a command line option when starting the application.
> > > > Maybe we can explore raising the priority but not to the realtime level.
> >
> > > Let me put it more succulently.
> > > Almost all DPDK applications have threads that are a 100% CPU doing polling.
> > > Putting those thread as real-time thread breaks Linux badly because the kernel can and will try and run work on those CPU's and the system is broken/unstable/dead at that point.
> >
> > The suggestion is that when running on Windows it should be possible for the application to be configured to use real-time threads, there is no implication that it will force real-time priority on Linux. If it doesn't make sense for it to be configured on Linux then don't configure it. But saying it shall not be configurable for any platform just because one platform can't make use of the configuration and those platforms have to run compromised makes little sense. Linux administrators are (or should be) knowledgeable enough to know what configuration to use.
> >
>
> Why not just make it always return an error when real-time is requested on Linux from a DPDK thread.
>
I would tend to agree with this suggestion, that we just return ENOTSUP
error code for Linux. It's too easy to lock up a linux system with realtime
DPDK threads. If a user really knows what they are doing and they need
realtime priority on linux, they can use the linux scheduler APIs directly.
However, I am ok with having such a function supported on Windows if it's
needed. Unfortunately, I don't know for sure about BSD, but it probably
should follow the linux approach initially unless proved safe.
/Bruce
-----Original Message-----
From: Bruce Richardson <bruce.richardson@intel.com>
Sent: Wednesday, November 10, 2021 1:21 AM
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: Tyler Retzlaff <roretzla@microsoft.com>; Narcisa Ana Maria Vasile <navasile@linux.microsoft.com>; thomas <thomas@monjalon.net>; dev@dpdk.org; Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>; Khoa To <khot@microsoft.com>; Dmitry Malloy <dmitrym@microsoft.com>; talshn <talshn@mellanox.com>; Omar Cardona <ocardona@microsoft.com>; david.marchand@redhat.com; Kadam, Pallavi <pallavi.kadam@intel.com>
Subject: Re: [EXTERNAL] Re: [dpdk-dev] [PATCH v16 2/9] eal: add thread attributes
> On Tue, Nov 09, 2021 at 10:29:25PM -0800, Stephen Hemminger wrote:
> > On Wed, 10 Nov 2021 04:20:52 +0000
> > Tyler Retzlaff <roretzla@microsoft.com> wrote:
> >
> > > > >
> > > > > High performance applications benefit from an option to raise
> > > > > the priority of their threads to avoid being preemted by other
> > > > > threads on the system. If there are issues with realtime
> > > > > priority on some of the platforms, maybe we can add a warning
> > > > > for the user to make them aware of possible crashes as Stephen
> > > > > H. suggested some time ago. Note that this patch doesn't change the priority of EAL threads, enabling the higher priority will be done through a command line option when starting the application.
> > > > > Maybe we can explore raising the priority but not to the realtime level.
> > >
> > > > Let me put it more succulently.
> > > > Almost all DPDK applications have threads that are a 100% CPU doing polling.
> > > > Putting those thread as real-time thread breaks Linux badly because the kernel can and will try and run work on those CPU's and the system is broken/unstable/dead at that point.
> > >
> > > The suggestion is that when running on Windows it should be possible for the application to be configured to use real-time threads, there is no implication that it will force real-time priority on Linux. If it doesn't make sense for it to be configured on Linux then don't configure it. But saying it shall not be configurable for any platform just because one platform can't make use of the configuration and those platforms have to run compromised makes little sense. Linux administrators are (or should be) knowledgeable enough to know what configuration to use.
> > >
> >
> > Why not just make it always return an error when real-time is requested on Linux from a DPDK thread.
> >
> I would tend to agree with this suggestion, that we just return ENOTSUP error code for Linux. It's too easy to lock up a linux system with realtime DPDK threads. If a user really knows what they are doing and they need realtime priority on linux, they can use the linux scheduler APIs directly.
This sounds reasonable to me. It doesn't compromise the Linux platform and allows the Windows platform to reach potential.
> However, I am ok with having such a function supported on Windows if it's needed. Unfortunately, I don't know for sure about BSD, but it probably should follow the linux approach initially unless proved safe.
Agreed, probably true for all POSIX platforms that support RT extensions.
@@ -9,6 +9,7 @@
#include <string.h>
#include <rte_common.h>
+#include <rte_debug.h>
#include <rte_errno.h>
#include <rte_log.h>
#include <rte_thread.h>
@@ -33,6 +34,51 @@ rte_thread_equal(rte_thread_t t1, rte_thread_t t2)
return pthread_equal((pthread_t)t1.opaque_id, (pthread_t)t2.opaque_id);
}
+int
+rte_thread_attr_init(rte_thread_attr_t *attr)
+{
+ RTE_VERIFY(attr != NULL);
+
+ CPU_ZERO(&attr->cpuset);
+ attr->priority = RTE_THREAD_PRIORITY_NORMAL;
+
+ return 0;
+}
+
+int
+rte_thread_attr_set_affinity(rte_thread_attr_t *thread_attr,
+ rte_cpuset_t *cpuset)
+{
+ RTE_VERIFY(thread_attr != NULL);
+ RTE_VERIFY(cpuset != NULL);
+
+ thread_attr->cpuset = *cpuset;
+
+ return 0;
+}
+
+int
+rte_thread_attr_get_affinity(rte_thread_attr_t *thread_attr,
+ rte_cpuset_t *cpuset)
+{
+ RTE_VERIFY(thread_attr != NULL);
+ RTE_VERIFY(cpuset != NULL);
+
+ *cpuset = thread_attr->cpuset;
+
+ return 0;
+}
+
+int
+rte_thread_attr_set_priority(rte_thread_attr_t *thread_attr,
+ enum rte_thread_priority priority)
+{
+ RTE_VERIFY(thread_attr != NULL);
+
+ thread_attr->priority = priority;
+ return 0;
+}
+
int
rte_thread_key_create(rte_thread_key *key, void (*destructor)(void *))
{
@@ -31,6 +31,28 @@ typedef struct rte_thread_tag {
uintptr_t opaque_id; /**< thread identifier */
} rte_thread_t;
+/**
+ * Thread priority values.
+ */
+enum rte_thread_priority {
+ RTE_THREAD_PRIORITY_NORMAL = 0,
+ /**< normal thread priority, the default */
+ RTE_THREAD_PRIORITY_REALTIME_CRITICAL = 1,
+ /**< highest thread priority allowed */
+};
+
+#ifdef RTE_HAS_CPUSET
+
+/**
+ * Representation for thread attributes.
+ */
+typedef struct {
+ enum rte_thread_priority priority; /**< thread priority */
+ rte_cpuset_t cpuset; /**< thread affinity */
+} rte_thread_attr_t;
+
+#endif /* RTE_HAS_CPUSET */
+
/**
* TLS key type, an opaque pointer.
*/
@@ -63,6 +85,75 @@ int rte_thread_equal(rte_thread_t t1, rte_thread_t t2);
#ifdef RTE_HAS_CPUSET
+/**
+ * Initialize the attributes of a thread.
+ * These attributes can be passed to the rte_thread_create() function
+ * that will create a new thread and set its attributes according to attr.
+ *
+ * @param attr
+ * Thread attributes to initialize.
+ *
+ * @return
+ * On success, return 0.
+ * On failure, return a positive errno-style error number.
+ */
+__rte_experimental
+int rte_thread_attr_init(rte_thread_attr_t *attr);
+
+/**
+ * Set the CPU affinity value in the thread attributes pointed to
+ * by 'thread_attr'.
+ *
+ * @param thread_attr
+ * Points to the thread attributes in which affinity will be updated.
+ *
+ * @param cpuset
+ * Points to the value of the affinity to be set.
+ *
+ * @return
+ * On success, return 0.
+ * On failure, return a positive errno-style error number.
+ */
+__rte_experimental
+int rte_thread_attr_set_affinity(rte_thread_attr_t *thread_attr,
+ rte_cpuset_t *cpuset);
+
+/**
+ * Get the value of CPU affinity that is set in the thread attributes pointed
+ * to by 'thread_attr'.
+ *
+ * @param thread_attr
+ * Points to the thread attributes from which affinity will be retrieved.
+ *
+ * @param cpuset
+ * Pointer to the memory that will store the affinity.
+ *
+ * @return
+ * On success, return 0.
+ * On failure, return a positive errno-style error number.
+ */
+__rte_experimental
+int rte_thread_attr_get_affinity(rte_thread_attr_t *thread_attr,
+ rte_cpuset_t *cpuset);
+
+/**
+ * Set the thread priority value in the thread attributes pointed to
+ * by 'thread_attr'.
+ *
+ * @param thread_attr
+ * Points to the thread attributes in which priority will be updated.
+ *
+ * @param priority
+ * Points to the value of the priority to be set.
+ *
+ * @return
+ * On success, return 0.
+ * On failure, return a positive errno-style error number.
+ */
+__rte_experimental
+int rte_thread_attr_set_priority(rte_thread_attr_t *thread_attr,
+ enum rte_thread_priority priority);
+
/**
* Set core affinity of the current thread.
* Support both EAL and non-EAL thread and update TLS.
@@ -423,6 +423,10 @@ EXPERIMENTAL {
rte_thread_self;
rte_thread_equal;
+ rte_thread_attr_init;
+ rte_thread_attr_get_affinity;
+ rte_thread_attr_set_affinity;
+ rte_thread_attr_set_priority;
};
INTERNAL {
@@ -4,6 +4,7 @@
*/
#include <rte_common.h>
+#include <rte_debug.h>
#include <rte_errno.h>
#include <rte_thread.h>
#include <rte_windows.h>
@@ -28,6 +29,49 @@ rte_thread_equal(rte_thread_t t1, rte_thread_t t2)
return t1.opaque_id == t2.opaque_id;
}
+int
+rte_thread_attr_init(rte_thread_attr_t *attr)
+{
+ RTE_VERIFY(attr != NULL);
+
+ attr->priority = RTE_THREAD_PRIORITY_NORMAL;
+ CPU_ZERO(&attr->cpuset);
+
+ return 0;
+}
+
+int
+rte_thread_attr_set_affinity(rte_thread_attr_t *thread_attr,
+ rte_cpuset_t *cpuset)
+{
+ RTE_VERIFY(thread_attr != NULL);
+ thread_attr->cpuset = *cpuset;
+
+ return 0;
+}
+
+int
+rte_thread_attr_get_affinity(rte_thread_attr_t *thread_attr,
+ rte_cpuset_t *cpuset)
+{
+ RTE_VERIFY(thread_attr != NULL);
+
+ *cpuset = thread_attr->cpuset;
+
+ return 0;
+}
+
+int
+rte_thread_attr_set_priority(rte_thread_attr_t *thread_attr,
+ enum rte_thread_priority priority)
+{
+ RTE_VERIFY(thread_attr != NULL);
+
+ thread_attr->priority = priority;
+
+ return 0;
+}
+
int
rte_thread_key_create(rte_thread_key *key,
__rte_unused void (*destructor)(void *))