From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
by inbox.dpdk.org (Postfix) with ESMTP id 69987A0C47;
Tue, 12 Oct 2021 18:07:13 +0200 (CEST)
Received: from [217.70.189.124] (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id 57B0241103;
Tue, 12 Oct 2021 18:07:13 +0200 (CEST)
Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com
[66.111.4.221]) by mails.dpdk.org (Postfix) with ESMTP id CAB0741100
for <dev@dpdk.org>; Tue, 12 Oct 2021 18:07:12 +0200 (CEST)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44])
by mailnew.nyi.internal (Postfix) with ESMTP id 31BAB5809C6;
Tue, 12 Oct 2021 12:07:12 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
by compute4.internal (MEProxy); Tue, 12 Oct 2021 12:07:12 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h=
from:to:cc:subject:date:message-id:in-reply-to:references
:mime-version:content-transfer-encoding:content-type; s=fm2; bh=
EbydM414okSwO9tYC8JAw+dYsjfMKWGTKU+D+xr1QQ0=; b=NyuQBqiKtq/kWLD3
PwgDI/2kQhHFfwAbTrdGcuOrrsVRZrbGrAxmlVt6iDPWhTx6xfLdob9+qKc+2bhG
18FrgEki4KwvdtvbZiyiyoeT+S0YNBEb3LwXaBly6S3MJ634YMN4CuaSyNOtwRka
CpyKIJZie0DzAJ8hULTo0We0oCjesjBGZLkOha5WAAMnvj97ZdzmZoaZUJMN3yGn
HLSqoI+SreDjmsTx6z7EtXEgxrpxtuPNTm8YGvl9aQVBOpAt6wwmSsZ2CdwOuSac
7gKFCB1A8oFU32PA3UfgqvcQJ8qf4x2IJiLyCcGQtTscwmJ5k+QNaRGS8yIvahB6
f/j5ww==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=cc:content-transfer-encoding:content-type
:date:from:in-reply-to:message-id:mime-version:references
:subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender
:x-sasl-enc; s=fm1; bh=EbydM414okSwO9tYC8JAw+dYsjfMKWGTKU+D+xr1Q
Q0=; b=F7qOc9+Jm+LGik1mI3aYooPs1vezMmv5EJ4+9ATzItAHEvranP/SUAOja
EI6RsUPMXSi1d2qeUjIRtjyJCOrCI1bJ57kgOEz3bFxOzuzmpVOKMdBaTCf1Injj
kpYg7BWVRdEDyyM09FJpmExo4yDvGmfYiVCdwYTiIntViZzEOybmsH+WdP3wpiwJ
/2ECbYzOoxOCBKK+ibj9FbmCCbEhsSg/V28R0JIZxsoA8+uDEZjQMhFcUq1uBQ6l
9NZqCt3NpmWJnTT74873mIsz2eCO85yw+nmaPI3O3vgItR4pYSVLAdP+9jncK1Rb
RqJN+t4P6b12OQB/HPhLnBIA2LNmQ==
X-ME-Sender: <xms:r7JlYeXq3Ea7IaWk9Zq3IdgPGJtQcrSr18hvQ2sK0HTmbRWP4WDP9Q>
<xme:r7JlYandKxCSe1Y_V6iA_VIOs-IZ_OWHwGUXWgghgFB4dXKmm9rBaO-d8viuBnSAE
vemiOisBi4GPSiabg>
X-ME-Received: <xmr:r7JlYSaP_yieRl2qro6svL49DxfnbF4Dy52ObGmPGYHXk7obkss39VolXD5quT3FGcWvAs3BzXen7ZeG087rzNIducGJbEvgvyT4I7NA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvddtkedgleegucetufdoteggodetrfdotf
fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
cujfgurhephffvufffkfgjfhgggfgtsehtqhertddttdejnecuhfhrohhmpefvhhhomhgr
shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg
ftrfgrthhtvghrnhepkeethedtieevhfeigeejleegudefjeehkeekteeuveeiuedvveeu
tdejveehveetnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh
homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth
X-ME-Proxy: <xmx:r7JlYVWDVz-n1cKqmfspbLdMRFZV0iKokZ2meKZbmUSPc7lBSj12ow>
<xmx:r7JlYYkN4ZwDUvLFW4_mtc88Rk7SorWjmmm4_mMR_vejUU_G6idOIw>
<xmx:r7JlYad1LscSip6dHOmLfHWmW5gijA0-cD-VjIRX1lqPbNnm6MYqwg>
<xmx:sLJlYVgj2EMKw90-ldn0UWfKjXpnq6kK1kvYhFfaq0d0bdtlQf_MRA>
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
12 Oct 2021 12:07:09 -0400 (EDT)
From: Thomas Monjalon <thomas@monjalon.net>
To: Narcisa Ana Maria Vasile <navasile@linux.microsoft.com>
Cc: dev@dpdk.org, dmitry.kozliuk@gmail.com, khot@microsoft.com,
dmitrym@microsoft.com, roretzla@microsoft.com, talshn@nvidia.com,
ocardona@microsoft.com, bruce.richardson@intel.com, david.marchand@redhat.com,
pallavi.kadam@intel.com
Date: Tue, 12 Oct 2021 18:07:06 +0200
Message-ID: <2222415.sAQYqxUYF4@thomas>
In-Reply-To: <1633765318-28356-1-git-send-email-navasile@linux.microsoft.com>
References: <1633732841-17873-1-git-send-email-navasile@linux.microsoft.com>
<1633765318-28356-1-git-send-email-navasile@linux.microsoft.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [dpdk-dev] [PATCH v16 0/9] eal: Add EAL API for threading
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>
09/10/2021 09:41, Narcisa Ana Maria Vasile:
> From: Narcisa Vasile <navasile@microsoft.com>
>=20
> EAL thread API
>=20
> **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.
>=20
> **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.
>=20
> **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/ ?
> **A schematic example of the design**
> --------------------------------------------------
> lib/librte_eal/include/rte_thread.h
> int rte_thread_create();
>=20
> lib/librte_eal/common/rte_thread.c
> int rte_thread_create()=20
> {
> return pthread_create();
> }
>=20
> lib/librte_eal/windows/rte_thread.c
> int rte_thread_create()=20
> {
> return CreateThread();
> }
> -----------------------------------------------------
We must have the same error code, no matter the underlying implementation.
So you cannot return directly pthread or win32 error codes.
> **Thread attributes**
>=20
> When or after a thread is created, specific characteristics of the thread
> can be adjusted. Given that the thread characteristics that are of intere=
st
> for DPDK applications are affinity and priority, the following structure
> that represents thread attributes has been defined:
>=20
> typedef struct
> {
> enum rte_thread_priority priority;
> rte_cpuset_t cpuset;
> } rte_thread_attr_t;
>=20
> 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()*.
>=20
> *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.
> 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
>=20
> 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.
> Example:
> ./dpdk-l2fwd -l 0-3 -n 4 =E2=80=93thread-prio normal -- -q 8 -p ffff
>=20
> *Affinity* is described by the already known =E2=80=9Crte_cpuset_t=E2=80=
=9D type.
> rte_thread_attr_set/get_affinity - sets/gets the affinity field in a
> rte_thread_attr_t object
> rte_thread_set/get_affinity =E2=80=93 sets/gets the affinity of a th=
read
>=20
> **Errors**
> A translation function that maps Windows error codes to errno-style
> error codes is provided.=20
>=20
> **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.)