From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id E53B3A0548; Wed, 15 Jul 2020 18:21:32 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id AA0CF4C7B; Wed, 15 Jul 2020 18:21:31 +0200 (CEST) Received: from mail-pl1-f196.google.com (mail-pl1-f196.google.com [209.85.214.196]) by dpdk.org (Postfix) with ESMTP id 24E7E2C58 for ; Wed, 15 Jul 2020 18:21:29 +0200 (CEST) Received: by mail-pl1-f196.google.com with SMTP id x8so2582766plm.10 for ; Wed, 15 Jul 2020 09:21:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=vE+MhrCxEzQ/98zV7MMzx4bvqftlVrJgE0WHpSWJaYk=; b=X2soKIfdOA09zyBPT5lsXq7qRrWeAoOrDuaOtyWpCSBGj7gqHlJXdX15CFkozIdfOL VIMAPTvLR8JoxyfYdzCvqZjm3i0pNlX84Ksu6fooupbWJ/8vRUfy6HFH1JkjTFW9HSPD 2/+6ZV80epFVNeo+wJfNsvfLn10NcOfjZWr8csS9GHqD1Y6JTTFLAhdj0Xax0W/RXfb6 qgccvKWrhMA0MHCgLjmsw1ZiUN/u75XdPkmROnsNIOoQjzrdzKH2SvvA94gKJzSMG8Zz NrX81D8rxhacThBGE4hDGCQp1wmz7MBVMiaH+7dx9j47ZIlJp0iP8ck192t9dvG9LlhL Mi0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=vE+MhrCxEzQ/98zV7MMzx4bvqftlVrJgE0WHpSWJaYk=; b=NrbTRoyFusedwjGMHOKt9ZM2wnxtwNk98y2ieZLhZCEzNU5vBUcBemnxZzSS/q5H9i mt+5xxb4ZsdF0zzX1Ux6yTRh78qsNdNU7Lzua8lO6KORCkJxcf31NYKNxgsIr/hpwibz v1TLVKuJm/qRNyJD0uzOZh7KPATyDr+IqEIAePWRbhpMekkmkYLJYnZfvyaJE1kUdgAs kGFKMgHxmKJ2ZKjT7ad6LW/HL6ZAJj3LnBOzkghKfdbiFKyxhudXeaK5iLZL+jKL0Z9b S1LY6X39BNWRN+6ifXulX8hRQEWo8nMwtTjaiWV0XztXqNI4soqKoKU2fYnokA8YtfHl +wAw== X-Gm-Message-State: AOAM530AgSOEYB7paDvMTDhd3MDqonqoARZae2+/bys5NKJDkqnMZOkv sdr1JZNLTqVzx40zpLvFJY+GUg== X-Google-Smtp-Source: ABdhPJxCb0AiNwlJsgYg24ASfSDGj6zYNEk9o/9h1LDPuPqNHWLa+RjtUGoJCsi/yWLkUzaMdtsy1Q== X-Received: by 2002:a17:90a:1a02:: with SMTP id 2mr408153pjk.150.1594830088924; Wed, 15 Jul 2020 09:21:28 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id e20sm2461580pfl.212.2020.07.15.09.21.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Jul 2020 09:21:28 -0700 (PDT) Date: Wed, 15 Jul 2020 09:21:20 -0700 From: Stephen Hemminger To: Mattias =?UTF-8?B?UsO2bm5ibG9t?= Cc: Honnappa Nagarahalli , "Van Haaren, Harry" , dpdk-dev , Tomasz Piatkowski , nd Message-ID: <20200715092120.67e28eae@hermes.lan> In-Reply-To: <973a2a40-4ff2-96b8-c5e0-17992c40b5d8@ericsson.com> References: <20200714135138.136f2a56@hermes.lan> <973a2a40-4ff2-96b8-c5e0-17992c40b5d8@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] Retrieving lcore worker thread id X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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" On Wed, 15 Jul 2020 10:17:09 +0000 Mattias R=C3=B6nnblom wrote: > On 2020-07-14 22:51, Stephen Hemminger wrote: > > On Tue, 14 Jul 2020 18:59:59 +0000 > > Honnappa Nagarahalli wrote: > > =20 > >> > >> =20 > >>>> Hi. =20 > >>> Hey, > >>> =20 > >>>> In DPDK 19.11, the lcore_config struct of is made > >>>> private, and with it the possibility to look up the thread id of the > >>>> lcore worker threads disappears. > >>>> > >>>> One use case is an application with a monitoring function (on some > >>>> control plane thread), which uses the thread ids to make sure the > >>>> worker threads gets the CPU runtime they should, and thus is able to > >>>> detect stalls. =20 > >> This sounds similar to 'keep alive' functionality. > >> =20 > >>>> Is there some other way of finding out the thread_id of a lcore work= er > >>>> thread? All I can think of are hacks like using a temporary service > >>>> function for service cores, in combination with requiring launched > >>>> application threads also to store their thread id in some global > >>>> structure (index by lcore_id). =20 > >>> -1 for the service cores idea. I like the creative solution thinking,= but not as a > >>> long-term solution. > >>> =20 > >>>> Is there some cleaner way? If not, would adding something like a > >>>> rte_lcore_thread_id() function make sense? =20 > >> I guess here you mean the OS provided thread ID. Are there OS calls th= at provide the CPU runtime? =20 > > This might be difficult sinc thread id in Linux/glibc is intentionally = and opaque value. > > According to Posix the only valid way to look at it is to use return va= lue from > > pthread_create() and pthread_self(). > > =20 >=20 > The rte_lcore_thread_id() would return this value, which could=20 > subsequently be used in the application, calling pthread_getcpuclockid()= =20 > and clock_gettime() to retrieve the run time for the lcore worker=20 > thread. No need to break the opacity in this case, although the Linux=20 > thread id (i.e. the result of a gettid()) would be useful in case you=20 > would want to dig around in /proc for other scheduler statistics. >=20 >=20 > Regards, >=20 > =C2=A0=C2=A0=C2=A0 Mattias >=20 The issue is glibc doesn't want to allow gettid() there is no wrapper, the only way to get it is using syscall()