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 0D51E4238D; Fri, 13 Jan 2023 19:56:10 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id EC440410EF; Fri, 13 Jan 2023 19:56:09 +0100 (CET) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id 02C6440E03 for ; Fri, 13 Jan 2023 19:56:09 +0100 (CET) Received: by linux.microsoft.com (Postfix, from userid 1086) id 4F67A20DED6B; Fri, 13 Jan 2023 10:56:08 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 4F67A20DED6B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1673636168; bh=BYOA7VvfqGhyEzqdyO2VEZ7oKWi41QntaKmxH25LNIQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Rrlttu9t1oo2WPPd3DexjJMhUwfbo1gSFXwMLn/iIS0RJBSGw4c6SYA3YqvQCYN02 YdzfoAGLFjRpMDXvWHp1qmozc7J5FTpB7vHZkIQoPttZHT1d5lVRjb+5RsGycwSHG3 CSxgI/nY/2bSFrOa3gdvnLKhJfbH0FHNFcrE8RZE= Date: Fri, 13 Jan 2023 10:56:08 -0800 From: Tyler Retzlaff To: Jerin Jacob , david.marchand@redhat.com Cc: Jerin Jacob Kollanukkaran , Sunil Kumar Kori , dev@dpdk.org, thomas@monjalon.net, olivier.matz@6wind.com, stephen@networkplumber.org, mb@smartsharesystems.com Subject: Re: [PATCH v2 1/4] eal: add thread set name API operating on rte thread Message-ID: <20230113185608.GA11082@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <1670439617-9054-1-git-send-email-roretzla@linux.microsoft.com> <1671036441-10234-1-git-send-email-roretzla@linux.microsoft.com> <1671036441-10234-2-git-send-email-roretzla@linux.microsoft.com> <20230113170921.GA28592@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230113170921.GA28592@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> User-Agent: Mutt/1.5.21 (2010-09-15) 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 Fri, Jan 13, 2023 at 09:09:21AM -0800, Tyler Retzlaff wrote: > On Fri, Jan 13, 2023 at 10:06:44AM +0530, Jerin Jacob wrote: > > On Wed, Jan 11, 2023 at 9:39 PM David Marchand > > wrote: > > > > > > On Wed, Dec 14, 2022 at 5:47 PM Tyler Retzlaff > > > wrote: > > > > diff --git a/lib/eal/common/eal_common_trace.c b/lib/eal/common/eal_common_trace.c > > > > index 5caaac8..89522dc 100644 > > > > --- a/lib/eal/common/eal_common_trace.c > > > > +++ b/lib/eal/common/eal_common_trace.c > > > > @@ -356,8 +356,6 @@ rte_trace_mode rte_trace_mode_get(void) > > > > /* Store the thread name */ > > > > char *name = header->stream_header.thread_name; > > > > memset(name, 0, __RTE_TRACE_EMIT_STRING_LEN_MAX); > > > > - rte_thread_getname(pthread_self(), name, > > > > - __RTE_TRACE_EMIT_STRING_LEN_MAX); > > > > > > > > trace->lcore_meta[count].mem = header; > > > > trace->nb_trace_mem_list++; > > > > > > Note, this belongs to patch 2. > > > > > > I understand we can drop the thread name retrieval helper from public > > > API, but at least for the trace framework it added some info in the > > > traces. > > > Jerin, Sunil, what do you think? Should we keep this helper internally? > > > > > > Good catch @David Marchand. Yes, we should be it as internal helper > > API use it here. > > For trace, It will be difficult to make sense without thread name. > > is the name what is really valuable here because it will only appear in > traces for linux with a new enough glibc, i.e. freebsd and windows it > will always be empty. > > we could just provide the thread id and that is available on all > platforms, i'd like to see consistency for all platforms if possible > here but i'm not pushing too hard since we don't declare our tracing > output to be a compatibility surface. > > can we just provide the thread id? as a compromise i have submitted a new version for the series that curtails the scope of the original rte_thread_getname and allowing it at this single callsite. going forward however i would suggest we do not allow further internal use. thanks!