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 C05ACA0597; Thu, 9 Apr 2020 14:49:56 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 9AA491C1F7; Thu, 9 Apr 2020 14:49:56 +0200 (CEST) Received: from mail-il1-f194.google.com (mail-il1-f194.google.com [209.85.166.194]) by dpdk.org (Postfix) with ESMTP id 4DAC41C19F for ; Thu, 9 Apr 2020 14:49:54 +0200 (CEST) Received: by mail-il1-f194.google.com with SMTP id p13so10068113ilp.3 for ; Thu, 09 Apr 2020 05:49:54 -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=dvWr6aeKcjqc/2neNkMh6qWqrqGJeYIl/2aK6cu/z8s=; b=gTc+rMfKSV0/87eDFUeGh0CyyKek8iKIgYI7bVIPxszsinp3YqDvLBObVaCDZCiIP6 u21UJTxnMR5hYyHCE9ddA1u59Q0v5tjxAIZWJdO42CKTb+J/FnSoQ+6gVcbHiaBg5gI+ AgJrSNSZX7+eUqm1vdpbK+OreO2jg0nLydb8BgMu8lR7cdGOR0WieJ/1kmDUWjXB0GXx JhqlZ/0+5gArLYgD6UyFOf2u/OgUWaJYgDFLu54Nmh1IZGHlgJILGKSD/vCwLTijXWpG C8Wmwv3VSN/GS1sI7cHFR9yijB5KTZ5YsaxDSYYheEPwWin5cuUAKZxGI22VQYYAitld 0jkg== 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=dvWr6aeKcjqc/2neNkMh6qWqrqGJeYIl/2aK6cu/z8s=; b=kbVRd5ubY8JH921fTeuhQPxEmc2hIywkyddUF6PIBwyTSEcCYKo+qdvPJ9+1mKcta9 VnQS/b1nTulBRHsLCMZU98HxmsS4wMha0tVljY3gg2pbFZVeEPbEmQyNaehaMYJWfmJN f+I+4ckVyndU4CVGBceY3sjc2wuwslirWFATj3VImaY4Qth39tLkRX5aJsHaeuGIZWGC V6pmgG6Hnu1r1cq8g8zwn7oOdcvSaYOVLcZu3m+ncghLdkJlqgFqhSRfwW4uhQnBlv+w mvz0lIrbrbMf3Y2gfPbXjgBzXfuxcifiAj5y2TXnhzndM6cAAQFkUnv0+DEtvd8pfGle sJtA== X-Gm-Message-State: AGi0PuYhwsM5W12oSatEQpRV9xZbBmdmYJ06ntELvIi9VYh1wtOpukdZ 3/wf7nLQYjjDTuyHZvabeqR2lBW4lQV303AFCEc= X-Google-Smtp-Source: APiQypKaw0fKSNXH8RC32OGce9cJJy3GCrGUIj9cP/OM9USegBo9I4QBDc7fPJKZIkGnAWWFTPXf7pTaWxaEdGWajqw= X-Received: by 2002:a92:9e4b:: with SMTP id q72mr1727493ili.60.1586436593516; Thu, 09 Apr 2020 05:49:53 -0700 (PDT) MIME-Version: 1.0 References: <1561553317-16777-1-git-send-email-viacheslavo@mellanox.com> <1584625851-10291-1-git-send-email-viacheslavo@mellanox.com> <1584625851-10291-4-git-send-email-viacheslavo@mellanox.com> In-Reply-To: From: Jerin Jacob Date: Thu, 9 Apr 2020 18:19:37 +0530 Message-ID: To: Ferruh Yigit Cc: Viacheslav Ovsiienko , dpdk-dev , Thomas Monjalon , Bernard Iremonger Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v2 3/3] app/testpmd: qualify profiling statistics on burst size 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 Thu, Apr 9, 2020 at 5:16 PM Ferruh Yigit wrote: > > On 3/20/2020 6:13 AM, Jerin Jacob wrote: > > On Thu, Mar 19, 2020 at 7:21 PM Viacheslav Ovsiienko > > wrote: > >> > >> The execution time of rx/tx burst routine depends on the burst size. > >> It would be meaningful to research this dependency, the patch > >> provides an extra profiling data per rx/tx burst size. > >> > >> Signed-off-by: Viacheslav Ovsiienko > > > >> +#ifdef RTE_TEST_PMD_RECORD_CORE_CYCLES > >> + if (!(fwdprof_flags & (nrx_tx ? RECORD_CORE_CYCLES_TX > >> + : RECORD_CORE_CYCLES_RX))) > >> + return; > >> + for (nb_pkt = 0; nb_pkt < MAX_PKT_BURST; nb_pkt++) { > >> + nb_burst = nrx_tx ? pbs->pkt_retry_spread[nb_pkt] > >> + : pbs->pkt_burst_spread[nb_pkt]; > >> + if (nb_burst == 0) > >> + continue; > >> + printf(" CPU cycles/%u packet burst=%u (total cycles=" > >> + "%"PRIu64" / total %s bursts=%u)\n", > >> + (unsigned int)nb_pkt, > >> + (unsigned int)(pbs->pkt_ticks_spread[nb_pkt] / nb_burst), > >> + pbs->pkt_ticks_spread[nb_pkt], > >> + nrx_tx ? "TX" : "RX", nb_burst); > >> + } > >> +#endif > > > > > > # Thanks for this feature, IMO, It worth to mention in release notes. > > > > # I see a lot of code get added under RTE_TEST_PMD_RECORD_CORE_CYCLES. > > I agree that it should be under RTE_TEST_PMD_RECORD_CORE_CYCLES. Since > > this flag is not > > by default, there is a risk of compilation issue when this flag is get enabled. > > IMO, it is better to move to _if (0)_ semantics to enable > > - performance when compiler opt-out the code. > > - It forces the compiler to check the compilation errors irrespective > > of the RTE_TEST_PMD_RECORD_CORE_CYCLES state. > > > > Something like below, > > > > static __rte_always_inline int > > testpmd_has_stats_feature(void) > > { > > #ifdef RTE_TEST_PMD_RECORD_CORE_CYCLES > > return RTE_TEST_PMD_RECORD_CORE_CYCLES ; > > #else > > return 0; > > #endif > > } > > > > > > if (testpmd_has_stats_feature()) { > > > > } > > > > Hi Jerin, Hi Ferruh, > In this usage, compiler will removed the "if (0) { }" block, right? Yes. > I think this is good idea, we can use it other places too, including this one. Yes.