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 9263DA04B2; Mon, 4 May 2020 19:19:26 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id F01C41D172; Mon, 4 May 2020 19:19:25 +0200 (CEST) Received: from mail-il1-f193.google.com (mail-il1-f193.google.com [209.85.166.193]) by dpdk.org (Postfix) with ESMTP id 5E1521D16B for ; Mon, 4 May 2020 19:19:24 +0200 (CEST) Received: by mail-il1-f193.google.com with SMTP id r2so12017949ilo.6 for ; Mon, 04 May 2020 10:19:24 -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=4ysfXHjA0UQMwyC52nTGG1oDptXrSzHMWFHcv4xw1fk=; b=MHGNLadAh9Rc5Nw5mSyLq8yUzXlgDDxc9NFTs2Amd6q8EPF6gvxaQfNBMHleA8vXkX 2mpwEaOIk3FL85+cX1d5azjTtAKP/12/Eb+jeWj9P4i9+Eu9cO4cSceSknQd4qEdQrn9 Fcvaid5/gFAJ//3+IJHGdM7YlxUNFRrtytiZERlnOEv8murjInQuoy1OFn/DybCFW9GI IFfSHQ6xLLtatsHvIsUIzzCAs7BOuggF+ADhzy3egP4Qm/vB1r5jZYkAlpbrK/WQU672 4eYzF5Jl2TZcgLHHwWijYOHh/RG1kFeNrfVFmK1L4G2Rhbj8IIM0oL2O0fhLHhh5PlvI B3qQ== 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=4ysfXHjA0UQMwyC52nTGG1oDptXrSzHMWFHcv4xw1fk=; b=batKur0oib3tuJW/jNsfr5kUpledDccuNJGvgm9OtVXh+bdqqFiW4FNFWhmcDWHbv5 gClgZyRvkgVShgUjs65lqSybPoAdCJSg8RLiVTmdUGa46jO+crY3XFfEGqHn2/S2N35g aUz1esL7SiyiMr6ADxuRqOlKxdgJpk9a0h7wPgah6RsFCY08qF3bsou3QOJ2Xv2cLDkn OV/cU0vjoYbk/ByhelwEwhYv3e5ArMy4tC8gsxWzyS05azj/rodcHs61UIq1xdFG2V+j t8FDlf9BXmtZoX2qV1x83PInjlWtbf4T2cdK5slNfiPqX8uOsocI4vAjX2a2rR07uVb+ UrCg== X-Gm-Message-State: AGi0PuYfEMRH5jahN7xadJhnSw1uExY88Y5NyquPekZ1jUg6OoBtXQkf hUhJL7PNtBDffyDW1S1556jZPtwoPYgcR1+qjBQ= X-Google-Smtp-Source: APiQypIWnyoR6LYlMsOYsYEekJjIID24dtYKSzqpIqOF+iRBdOVsLaK+sHEBDDZyuk+JQT5QKWMd93FZEdXrWV/RSjA= X-Received: by 2002:a92:d341:: with SMTP id a1mr4648368ilh.130.1588612763480; Mon, 04 May 2020 10:19:23 -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 22:49:07 +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 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_INIT(otx2_log_init); static void otx2_log_init(void) { otx2_logtype_base = rte_log_register("pmd.octeontx2.base"); if (otx2_logtype_base >= 0) rte_log_set_level(otx2_logtype_base, RTE_LOG_NOTICE); otx2_logtype_mbox = rte_log_register("pmd.octeontx2.mbox"); if (otx2_logtype_mbox >= 0) rte_log_set_level(otx2_logtype_mbox, RTE_LOG_NOTICE); otx2_logtype_npa = rte_log_register("pmd.mempool.octeontx2"); if (otx2_logtype_npa >= 0) rte_log_set_level(otx2_logtype_npa, RTE_LOG_NOTICE); otx2_logtype_nix = rte_log_register("pmd.net.octeontx2"); if (otx2_logtype_nix >= 0) rte_log_set_level(otx2_logtype_nix, RTE_LOG_NOTICE); otx2_logtype_npc = rte_log_register("pmd.net.octeontx2.flow"); if (otx2_logtype_npc >= 0) rte_log_set_level(otx2_logtype_npc, RTE_LOG_NOTICE); otx2_logtype_tm = rte_log_register("pmd.net.octeontx2.tm"); if (otx2_logtype_tm >= 0) rte_log_set_level(otx2_logtype_tm, RTE_LOG_NOTICE); otx2_logtype_sso = rte_log_register("pmd.event.octeontx2"); if (otx2_logtype_sso >= 0) rte_log_set_level(otx2_logtype_sso, RTE_LOG_NOTICE); otx2_logtype_tim = rte_log_register("pmd.event.octeontx2.timer"); if (otx2_logtype_tim >= 0) rte_log_set_level(otx2_logtype_tim, RTE_LOG_NOTICE); otx2_logtype_dpi = rte_log_register("pmd.raw.octeontx2.dpi"); if (otx2_logtype_dpi >= 0) rte_log_set_level(otx2_logtype_dpi, RTE_LOG_NOTICE); otx2_logtype_ep = rte_log_register("pmd.raw.octeontx2.ep"); if (otx2_logtype_ep >= 0) rte_log_set_level(otx2_logtype_ep, RTE_LOG_NOTICE); } > > > > > > 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. > > > -- > David Marchand >