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 9E7A6A04AE; Mon, 4 May 2020 19:54:59 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B759A1D528; Mon, 4 May 2020 19:54:58 +0200 (CEST) Received: from mail-io1-f66.google.com (mail-io1-f66.google.com [209.85.166.66]) by dpdk.org (Postfix) with ESMTP id A14F71D525 for ; Mon, 4 May 2020 19:54:57 +0200 (CEST) Received: by mail-io1-f66.google.com with SMTP id c2so13281299iow.7 for ; Mon, 04 May 2020 10:54:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=z+r5SxejDoNlD9Gujt2cAfeweDN3afIWiJXQ730k6R0=; b=NI94a1sC1HrJRdf0fUM2znEuxcq73OAq37IaiwbfnPZ5h7Cyfep+CK2YHfRd6pmTL4 A2+r6qCNdoa1tdSCCCGCmk+lNEcboLvnRA+VmgGBNeuypjxMydF+D+qNOHWKlGJTx+Y+ bIIfv+Vv15ryXIFpEgvEx3vj4+zKgMJXO43a5vcZ9zcUEldPo56tXcmbgEOnCgZNnm71 kor5zrPqIVqaTvQqWaqBcmcfEYg/bJsXLemRnZR9ZXSsgZKYRCpCOLL24i/rGDkrhuKD V91D3tThaQ47XjkQ/JgGVKnj1YRQiUgSMlpjJz/Kp4YjAivlM1nXdaWTBHnjBMhZQXlg NLqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=z+r5SxejDoNlD9Gujt2cAfeweDN3afIWiJXQ730k6R0=; b=nE3KgFJFt9ZsyNoJbVE2rG915jMz3adyKNbMnSSyiiOBMll+sSF0MgDaq35K1/k8q9 nyVcP1SzkZxa6+xOCoeTqLTBVwfxBzMsGyQG+k3uozIv5dOih9ynIc2tAeBJpdnsUwLJ mWqkdBcqN3mah11f1jq1z6UsjYtBFG2vGket0eJNoF+HZ/Rnu2OPKZqlsbBdx299MZ2u 143Pma4UnozChNPLW/xz+1WJE7+1vt6wV0o5Br7uDvSCk81Faq/97rz7qRKqJKHteFdU cDVYW1Wux/CGNp8FeXTpQezXUu2NaDd7G/nHxsI3qXtrxyyXwY5FE8XZ3HncFmHmlLSf jtgg== X-Gm-Message-State: AGi0PuZ5erla8L9RbMYRPTEHJsPdUd3a0HAqszayX8Lz9OsjsclLg13Q a4dsa5aJrLjWmBKoe9nf9C03j5oHLm4JYBWUaCk= X-Google-Smtp-Source: APiQypIMl3jWisBMOT8xHh4oTzqNqRKkFGKANkcrUrjnzFiUNeqmN03nUdtExO9T9NCXbD7GBShbhkEkrGB8dmmHMFs= X-Received: by 2002:a05:6638:2a2:: with SMTP id d2mr16620362jaq.104.1588614896731; Mon, 04 May 2020 10:54:56 -0700 (PDT) MIME-Version: 1.0 References: <20200503203135.6493-1-david.marchand@redhat.com> <20200503203135.6493-3-david.marchand@redhat.com> In-Reply-To: From: Jerin Jacob Date: Mon, 4 May 2020 23:24:40 +0530 Message-ID: To: David Marchand Cc: dpdk-dev , Thomas Monjalon , Jerin Jacob , Sunil Kumar Kori , John McNamara , Marko Kovacevic , Declan Doherty , Ferruh Yigit , Andrew Rybchenko , Olivier Matz Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH 2/8] trace: simplify trace point registration 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 Mon, May 4, 2020 at 11:10 PM David Marchand wrote: > > On Mon, May 4, 2020 at 7:19 PM Jerin Jacob wrote: > > > > On Mon, May 4, 2020 at 10:38 PM David Marchand > > wrote: > > > > > > On Mon, May 4, 2020 at 4:39 PM Jerin Jacob wrote: > > > > > > > > On Mon, May 4, 2020 at 7:34 PM David Marchand wrote: > > > > > > > > > > On Mon, May 4, 2020 at 4:47 AM Jerin Jacob wrote: > > > > > > > > > > > > On Mon, May 4, 2020 at 2:02 AM David Marchand wrote: > > > > > > > > > > > > > > RTE_TRACE_POINT_DEFINE and RTE_TRACE_POINT_REGISTER must come in pairs. > > > > > > > Merge them and let RTE_TRACE_POINT_REGISTER handle the constructor part. > > > > > > > > > > > > > > > > > > Initially, I thought of doing the same. But, later I realized that > > > > > > this largely grows the number of constructors been called. > > > > > > I had concerns about the boot time of the application and/or loading > > > > > > the shared library, that the reason why spitting > > > > > > as two so that constructor registers a burst of traces like rte_log. > > > > > > > > > > I am a bit skeptical. > > > > > In terms of cycles and looking at __rte_trace_point_register() (which > > > > > calls malloc), the cost of calling multiple constructors instead of > > > > > one is negligible. > > > > > > > > We will have a lot tracepoints latter, each one translates to the > > > > constructor may not be a good > > > > improvement. The scope is limited only to register function so IMO it > > > > is okay to have split > > > > just like rte_log. I don't see any reason why it has to be a different > > > > than rte_log. > > > > > > What is similar to rte_log? > > > There is neither RTE_LOG_REGISTER macro, nor two-steps declaration of > > > dynamic logtypes. > > > > > > Here is an example of rte_log registration. Which has _one_ > > constructor and N number of > > rte_log_register() underneath. > > rte_log is one thing, rte_trace is already different. > > There is _no macro_ in rte_log for registration. > The reason being in that a rte_log logtype is a simple integer without > any special declaration requiring a macro. I just wrapped in macro for convincing, but it has the same semantics. global variable and API/macro to register. > > For tracepoints, we have a special two steps thing: the tracepoint > handle must be derived from the tracepoint name. > Then this handle must be registered. > What I proposed is to make life easier for developers that want to add > tracepoints and I suppose you noticed patch 1 of this series. To reduce the constructors. I don't want trace libraries to add lot of constructors. I don't think it simplifies a lot as the scope of only for registration. > > > > > > One of the thought process is, we probably remove the constructor > > > > scheme to all other with DPDK > > > > and replace it with a more register scheme. In such a case, we can > > > > skip calling the constructor all tother > > > > when trace is disabled. > > > > > > Sorry, but I have a hard time understanding your point. > > > Are you talking about application boot time? > > > > Yes. The optimization of application boottime time in case of static > > binary and/or shared library(.so) load time. > > As Thomas mentioned, do you have numbers? No. But I know, it is obvious that current code is better in terms of boot time than the proposed one. I would like to not add a lot of constructor for trace as the FIRST module in DPDK. > > > -- > David Marchand >