Re: [dpdk-dev] [PATCH v16 0/9] eal: Add EAL API for threading

On Tue, Oct 12, 2021 at 06:07:06PM +0200, Thomas Monjalon wrote:

09/10/2021 09:41, Narcisa Ana Maria Vasile:

quoted

From: Narcisa Vasile <redacted>

EAL thread API

**Problem Statement**
DPDK currently uses the pthread interface to create and manage threads.
Windows does not support the POSIX thread programming model,
so it currently
relies on a header file that hides the Windows calls under
pthread matched interfaces. Given that EAL should isolate the environment
specifics from the applications and libraries and mediate
all the communication with the operating systems, a new EAL interface
is needed for thread management.

**Goals**
* Introduce a generic EAL API for threading support that will remove
  the current Windows pthread.h shim.
* Replace references to pthread_* across the DPDK codebase with the new
  RTE_THREAD_* API.
* Allow users to choose between using the RTE_THREAD_* API or a
  3rd party thread library through a configuration option.

**Design plan**
New API main files:
* rte_thread.h (librte_eal/include)
* rte_thread.c (librte_eal/windows)
* rte_thread.c (librte_eal/common)

Why this file is not in lib/eal/unix/ ?

  
  Thank you Thomas for reviewing these patches!
  Your guidance is very much appreciated as I want to bring this patchset on the
  good path towards merging.
  Based on community meeting discussions, multiple users have requested an option
  to allow them to use a 3rd party thread library. At the same time, we want to remove
  the Windows shim that we currently use for threading in DPDK,
  so we decided to do the following:
  
  A new rte_thread_* API is introduced, which will be used uniformly across DPDK.
	  - for unix-based platforms, the code in eal/common will be compiled
	  - for windows, the code in eal/windows will be compiled.
  For all cases when a 3rd party library is needed, the code from eal/common will be
  used. For example, if winpthreads or pthreads4w are used, at build time the code from
  'eal/common' will be selected and the rte_thread_* API will point to pthread_*
  functions described by the "pthread.h" header file provided by the 3rd party library.
 
  Using a 3rd party library will not require any changes in the DPDK code,
  except for adding an option in the meson files. 
  Therefore code from common will work both on unix and windows.
  Nick explains even better in his RFC from that time: [RFC] pthread on Windows - Patchwork (dpdk.org).
  
  I will improve the cover letter and the commit messages to better explain this.

quoted

**A schematic example of the design**
--------------------------------------------------
lib/librte_eal/include/rte_thread.h
int rte_thread_create();

lib/librte_eal/common/rte_thread.c
int rte_thread_create() 
{
	return pthread_create();
}

lib/librte_eal/windows/rte_thread.c
int rte_thread_create() 
{
	return CreateThread();
}
-----------------------------------------------------

We must have the same error code, no matter the underlying implementation.
So you cannot return directly pthread or win32 error codes.

  The approach here is to translate the Windows errors to POSIX-style ones to have
  uniformity across the entire threading module.

quoted

**Thread attributes**

When or after a thread is created, specific characteristics of the thread
can be adjusted. Given that the thread characteristics that are of interest
for DPDK applications are affinity and priority, the following structure
that represents thread attributes has been defined:

typedef struct
{
	enum rte_thread_priority priority;
	rte_cpuset_t cpuset;
} rte_thread_attr_t;

The *rte_thread_create()* function can optionally receive
an rte_thread_attr_t
object that will cause the thread to be created with the
affinity and priority
described by the attributes object. If no rte_thread_attr_t is passed
(parameter is NULL), the default affinity and priority are used.
An rte_thread_attr_t object can also be set to the default values
by calling *rte_thread_attr_init()*.

*Priority* is represented through an enum that currently advertises
two values for priority:
	- RTE_THREAD_PRIORITY_NORMAL
	- RTE_THREAD_PRIORITY_REALTIME_CRITICAL

The priority level realtime should never used.

I am not sure about handling the priority so precisely.
I think we can abstract the priority need through different functions.
We already have the function rte_ctrl_thread_create() where priority
should be fixed.
I think we have only 2 types of threads:
	- control thread (interrupt, timer, IPC)
	- datapath lcore (created in rte_eal_init, including service cores)
It means we need only one new function for datapath thread creation.

I'll explain better the intent here on you other comment in patch 2. 

quoted

The enum can be extended to allow for multiple priority levels.
rte_thread_set_priority      - sets the priority of a thread
rte_thread_get_priority      - retrieves the priority of a thread
                               from the OS
rte_thread_attr_set_priority - updates an rte_thread_attr_t object
                               with a new value for priority

The user can choose thread priority through an EAL parameter,
when starting an application.  If EAL parameter is not used,
the per-platform default value for thread priority is used.
Otherwise administrator has an option to set one of available options:
 --thread-prio normal
 --thread-prio realtime

I don't think we need such feature.
Anyway, it is a new feature, so it is beyond the initial replacement goal.

  True, this is not part of this patchset, I will correct the cover letter.
  

quoted

Example:
./dpdk-l2fwd -l 0-3 -n 4 –thread-prio normal -- -q 8 -p ffff

*Affinity* is described by the already known “rte_cpuset_t” type.
rte_thread_attr_set/get_affinity - sets/gets the affinity field in a
                                   rte_thread_attr_t object
rte_thread_set/get_affinity      – sets/gets the affinity of a thread

**Errors**
A translation function that maps Windows error codes to errno-style
error codes is provided. 

**Future work**
The long term plan is for EAL to provide full threading support:
* Add support for conditional variables
* Additional functionality offered by pthread_*
  (such as pthread_setname_np, etc.)