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 2F152A0540; Wed, 21 Sep 2022 12:36:10 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C17B64067C; Wed, 21 Sep 2022 12:36:09 +0200 (CEST) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id A5D3E4014F for ; Wed, 21 Sep 2022 12:36:08 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: EAL threads Date: Wed, 21 Sep 2022 12:36:07 +0200 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D8733A@smartserver.smartshare.dk> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: EAL threads Thread-Index: AdjNmV7oGI7+jlZlSDyDhw+nl4H+EwAByK8g References: <2af5b047-f5fb-3074-9d8e-8dd7b01ce3c1@lysator.liu.se> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Bruce Richardson" , =?iso-8859-1?Q?Mattias_R=F6nnblom?= Cc: 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 > From: Bruce Richardson [mailto:bruce.richardson@intel.com] > Sent: Wednesday, 21 September 2022 11.06 >=20 > On Wed, Sep 21, 2022 at 10:39:15AM +0200, Mattias R=F6nnblom wrote: > > I have some lcore-related questions: > > > > The documentation make use of the term "non-EAL thread". Is a = non-EAL > thread > > the same thing as a non-lcore thread? I.e., are there EAL threads > that are > > not lcore threads? >=20 > Yes, there are some threads created by EAL which are not lcore = threads. > These are generally for background tasks, such as interrupts or > telemetry, > and are given a coremask to be kept away from the dataplane lcore > threads. > Therefore, I think you are right to try and get clear terminology for > the > threads. In most cases, I think non-EAL thread is referring to threads > created by the app itself, but it may in some cases refer to the 'non- > lcore > threads' as you call them. >=20 > Personally, I would suggest terms like: > * dataplane threads > * background eal threads > * app threads Assuming that "app threads" are not performing any dataplane packet = processing, I think "control plane threads" might be a better name. = Consider this: The purpose of a DPDK application is to perform dataplane = tasks, so "app threads" might easily be confused with "dataplane = threads". >=20 > for clarity, since I think the term EAL thread is ambiguous. However, > you or others might have been ideas for terms. >=20 > > > > I also have a question related to rte_register_thread(): shouldn't > the > > documentation say the user is assumed to pin the calling thread to > some > > core? That is the expectation, correct? >=20 > Probably, but it's not mandatory. For this terminology, I think both pinning and isolation of lcores = should be considered. Unfortunately, the confusion is much broader... Most of the DPDK documentation is based on the architecture before the = introduction of various mechanisms for cooperative time sharing of = lcores, such as Service Cores and Graphs. This also goes for the names of DPDK types, functions and macros. E.g. = RTE_PER_LCORE [1] actually means per thread, regardless which lcore runs = the thread (perhaps even multiple lcores may be scheduled from time to = time to run the thread). And why aren't there similar RTE_PER_SEVICE and = RTE_PER_NODE macros for Services and Graph nodes... It would be nice settling on an expanded set of well defined terms, and = cleaning up the documentation (and type/function/macro names) = accordingly. [1]: https://doc.dpdk.org/api/rte__per__lcore_8h.html