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 01161A0540; Tue, 14 Jul 2020 22:51:49 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id BB13A1C198; Tue, 14 Jul 2020 22:51:48 +0200 (CEST) Received: from mail-pl1-f195.google.com (mail-pl1-f195.google.com [209.85.214.195]) by dpdk.org (Postfix) with ESMTP id F0E0F1C118 for ; Tue, 14 Jul 2020 22:51:47 +0200 (CEST) Received: by mail-pl1-f195.google.com with SMTP id d1so2311121plr.8 for ; Tue, 14 Jul 2020 13:51:47 -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=8Qbsqaf2J366Lthxb/fnEY6NpY1QXDPAobLbk/s2Png=; b=iK0aBIvrRCnqGxBt/VWsXKbrovhWdLnFkbM/uZ71sGTbdZkIyk906PlE6GnVaKXKBE hRwzmAvbGlmi7wYdguePZKu5o2LOvBN59pAkxQ2cQCceOpz4+GzU/VfGEAkweJ/yVVwf hId3l8GseST7A0QS2shN1mhWXZ4RGZfJUQtfaJ6kQLzV5mhgeT04evYPWDAmRcEdDdaG 9wRTwjwxPoVYhdaXvTpFgqmPIaRGmBxkopSfjSN1bIaLU80IEFhOK5Wa8+xFPEXgpocy omoEvmTfBnr6RGr/T9HnCTBrZqNPG2Ygix0RhV06czmLHme+V/cA1NKQZ8SlSi4XEcZr 5HXg== 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=8Qbsqaf2J366Lthxb/fnEY6NpY1QXDPAobLbk/s2Png=; b=d6/fyl8BzIUW7o/w1XNZvzUA5lqtVibrG0pHGXk4ryksNp7TtRXge1FIBitrlF20f4 MfiVAuzkw+RkohNy2r6tJrHnTukKaIsQQBQdz+V2ONIt/ItOG/3Tk2yjGC2c2w0daB4H kuLbE5lAILCzpa5bfTa0jAAOhLRXLIGxAwhy8NXxt85ECVcLYtdPAd4MHYdAoUlG+hWv Au6z52kOTL6cg4Tv0rABNR92FTXjjk8s3eXSgP7GUgYbu5WalEqyyyti+lYyVif8T6MH +vrxd47pA79XnXHWkbxyX3FmyYWeFWG/FVAd6uHPtJoByE5FVA/TPCO+4usjGO5hw2YB tW8w== X-Gm-Message-State: AOAM531JPL47fvV9XZOaRU9mPh9WukcBVUi9gyCRpvHwW7gNxO1DR9gA SOoUJTlTPUHejQseFyWDAk+yXQ== X-Google-Smtp-Source: ABdhPJx0+7upFP0qx3lDRNgX63nO+WNczrvDmxp8iCjn5eoEGYnK7JVhKH4pRxUGSGsX1kho+OPyWA== X-Received: by 2002:a17:90a:e7cd:: with SMTP id kb13mr6438211pjb.138.1594759906834; Tue, 14 Jul 2020 13:51:46 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id g28sm80666pfr.70.2020.07.14.13.51.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Jul 2020 13:51:46 -0700 (PDT) Date: Tue, 14 Jul 2020 13:51:38 -0700 From: Stephen Hemminger To: Honnappa Nagarahalli Cc: "Van Haaren, Harry" , Mattias =?UTF-8?B?UsO2bm5ibG9t?= , dpdk-dev , Tomasz Piatkowski , nd Message-ID: <20200714135138.136f2a56@hermes.lan> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 Tue, 14 Jul 2020 18:59:59 +0000 Honnappa Nagarahalli wrote: > > > > > > > > Hi. > > > > Hey, > > > > > 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. > This sounds similar to 'keep alive' functionality. > > > > > > > Is there some other way of finding out the thread_id of a lcore worker > > > 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). > > > > -1 for the service cores idea. I like the creative solution thinking, but not as a > > long-term solution. > > > > > Is there some cleaner way? If not, would adding something like a > > > rte_lcore_thread_id() function make sense? > I guess here you mean the OS provided thread ID. Are there OS calls that provide the CPU runtime? 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 value from pthread_create() and pthread_self().