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 66E77A00C4; Fri, 30 Sep 2022 22:49:32 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0A4DC40684; Fri, 30 Sep 2022 22:49:32 +0200 (CEST) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mails.dpdk.org (Postfix) with ESMTP id B059B4003F for ; Fri, 30 Sep 2022 22:49:30 +0200 (CEST) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 6042A60AA for ; Fri, 30 Sep 2022 22:49:30 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 5EF5E61A8; Fri, 30 Sep 2022 22:49:30 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on hermod.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=ALL_TRUSTED, AWL, NICE_REPLY_A autolearn=disabled version=3.4.6 X-Spam-Score: -1.8 Received: from [192.168.1.59] (h-62-63-215-114.A163.priv.bahnhof.se [62.63.215.114]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id D0BE06135; Fri, 30 Sep 2022 22:49:29 +0200 (CEST) Message-ID: Date: Fri, 30 Sep 2022 22:49:28 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: EAL threads Content-Language: en-US To: Bruce Richardson Cc: "dev@dpdk.org" , =?UTF-8?Q?Mattias_R=c3=b6nnblom?= References: <2af5b047-f5fb-3074-9d8e-8dd7b01ce3c1@lysator.liu.se> From: =?UTF-8?Q?Mattias_R=c3=b6nnblom?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP 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 On 2022-09-21 11:05, Bruce Richardson wrote: > On Wed, Sep 21, 2022 at 10:39:15AM +0200, Mattias Rönnblom 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? > > 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. > > Personally, I would suggest terms like: > * dataplane threads > * background eal threads > * app threads > > for clarity, since I think the term EAL thread is ambiguous. However, > you or others might have been ideas for terms. > It's confusing to have something called an EAL thread to have a lcore id and generally being referred to as "a lcore", when it is in fact not necessarily tied to a logical core (in the generic hardware sense of the word). What's important to various DPDK code (PMDs, libraries) is a) If the calling thread has a lcore id, and thus can be trusted to have its own, per-lcore data structure. b) Whether or not the thread may be (involuntarily) preempted, in particular by other threads which it might be communicating/synchronizing-with. As of now, an EAL thread qualifies for a), and usually, but not always, for b) (not in a strict sense, but it's rarely interrupted and if so, only by threads or ISRs outside the DPDK process). A lot of things in DPDK assumes b) from EAL threads. Any library or PMD that uses spinlocks, the default rings, etc. There might be more subtle issues as well, I'm guessing. Just take the new busyness-patch set. If a thread which is in a busy state it's being interrupted, it will be considered busy even when it's not running, but some other thread is. If this other thread is also an EAL thread, that does work and is considered busy, the telemetry data might be wildly inaccurate and even suggest that the system spends more CPU cycles than are actually available. DSW port load measurement, using the same scheme, will also fall into this trap, when being used by preemptable EAL threads. Thanks for your answer. >> >> 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? > > Probably, but it's not mandatory.