From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 ; 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: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvddtkedgleegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtqhertddttdejnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepkeethedtieevhfeigeejleegudefjeehkeekteeuveeiuedvveeu tdejveehveetnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 12 Oct 2021 12:07:09 -0400 (EDT) From: Thomas Monjalon To: Narcisa Ana Maria Vasile 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 09/10/2021 09:41, Narcisa Ana Maria Vasile: > From: Narcisa Vasile >=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.)