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 2D02EA057B; Wed, 1 Apr 2020 10:19:09 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 7E07D1BEA8; Wed, 1 Apr 2020 10:19:08 +0200 (CEST) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [205.139.110.61]) by dpdk.org (Postfix) with ESMTP id 5EB1D1BEA6 for ; Wed, 1 Apr 2020 10:19:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1585729145; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8DfcMDTtFSvoVTZSzu+Ee+eP0tFsbwKcrgCNE01ytQk=; b=URsZuiL6CyZsN9O6b3iuLd23jBksWyxK/9CwXFOKeZDkqIdnUYIwl3XoaHLpjuKODIb4ga fdORCh4vS3aSd5NZs8TedzLtJDtbzxwZq9U9RId2W+y1QM6+Z3k6k/Yo0hko0mTifM34M5 Tuesp/DIrUj0g4QrE6/E4qwruz/OFWk= Received: from mail-vs1-f71.google.com (mail-vs1-f71.google.com [209.85.217.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-438-thsRhl1DO3CZbPRf9bwUiA-1; Wed, 01 Apr 2020 04:19:00 -0400 X-MC-Unique: thsRhl1DO3CZbPRf9bwUiA-1 Received: by mail-vs1-f71.google.com with SMTP id o4so5929227vsq.9 for ; Wed, 01 Apr 2020 01:19:00 -0700 (PDT) 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=m+Ws0SeZCYUXduCoLaNcwMxPZ1sXhMRQHC/ri/poeGs=; b=jhsWx0eRF23GT2Z/43c5u/9ZYY0eXGopIISf6Ea/GHEF+6YQPlpV7lo1onnk7WfUsh g6GqOGyeoFDF32+MYGgVtcm8Om3EoZxT8XvRk0X0hdJsls4Gyhoi14vFKV2VhwAp4bIP p55eGeUX4gFmuGTOmYAAy7szsRuTpqjB56rEuitxpiicZLzuNDECrRRau294F9lEr/Ki tVwlcmzKeuS03VG0PkNFd/yhgFOMuX8N9HdrQ2bRslan8RIjcs8LXPjeIbgs7N+5qSfw 72nP2vHGZfATmdkGusP1QBduVcgDGWha67yLMeMSbFJGzVvhBD7ckDPHz/IzFTO+geXA zA7Q== X-Gm-Message-State: AGi0PuZ3JXC7VXu59PtpFInEtSG2NhHLr0MipibXJZiECM3RxQfD85BK y8Ny3tChi0+EOWSUBMjQkFgygzbcfr1+eXv/X2UZ4up+DVn8Y0AEEBK8als4hPdvD8UN69HeWK8 quaPkxzUGZheVKUvaGSk= X-Received: by 2002:a67:26c2:: with SMTP id m185mr15820970vsm.180.1585729139800; Wed, 01 Apr 2020 01:18:59 -0700 (PDT) X-Google-Smtp-Source: APiQypJINYIeisvUBsJm8g4VBdHfPxtiOP51GuZoRIAZ0HX4UfwUY9Dm9AZz8rNct0hIQOZKpaZ2KUl0tDeAoDlCd3s= X-Received: by 2002:a67:26c2:: with SMTP id m185mr15820952vsm.180.1585729139456; Wed, 01 Apr 2020 01:18:59 -0700 (PDT) MIME-Version: 1.0 References: <20200325211603.240288-1-jerinj@marvell.com> <20200329144342.1543749-1-jerinj@marvell.com> In-Reply-To: <20200329144342.1543749-1-jerinj@marvell.com> From: David Marchand Date: Wed, 1 Apr 2020 10:18:48 +0200 Message-ID: To: Jerin Jacob Kollanukkaran Cc: dev , Thomas Monjalon , Bruce Richardson , =?UTF-8?Q?Mattias_R=C3=B6nnblom?= , Sunil Kumar Kori , "Yigit, Ferruh" , Andrew Rybchenko , Declan Doherty , Olivier Matz , Neil Horman X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH v3 00/33] DPDK Trace support 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" Hello Jerin, On Sun, Mar 29, 2020 at 4:43 PM wrote: > Items that needs to be sort it out > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > # Makefile and meson.build are updated to allow experimental APIs. > > As multiple EXPERIMENTAL symbols, exported by trace library, are > used in various drivers, lib, app and examples. So to fix compilation > warning/error, Makefile and meson.build are updated for all required > components to support EXPERIMENTAL APIs. > It results same code changes at multiple components as well as > increases source code line changes in patchset too. > Suggestions are welcome to resolve this issue with lesser code changes. - Regardless of the trace framework, the ALLOW_EXPERIMENTAL_API flag gates access to APIs so that external users are aware of their status. I have been considering setting this flag unconditionally for internal users in the top Makefile/meson for app/ lib/ and drivers/. I could look at this and prepare a patch about this, but this is not enough here. With the trace framework, we add experimental symbols in mempool or ethdev inlines, which then inherit the experimental check. This would break compilation of external code. Users are then forced to enable experimental API. How about: * we introduce a global config switch that enables/disables the trace framework (off by default): the people who want to test it and help stabilize it will have to deal with the experimental flag for now, * in 20.11, the trace points are put into the stable ABI, and the option is removed, - With the patchset rebased on the current master (could be my fault, so take it with a grain of salt), the ALLOW_EXPERIMENTAL_API flag is not passed when compiling the l3fwd example against an installed dpdk. - On the MAINTAINERS update: Trace M: Jerin Jacob M: Sunil Kumar Kori F: lib/librte_eal/include/rte_trace*.h F: lib/librte_eal/common/eal_common_trace*.c F: lib/librte_eal/common/eal_trace.h F: lib/librte_ethdev/ethdev_trace_points.c F: lib/librte_ethdev/rte_trace_ethdev*.h F: lib/librte_eventdev/eventdev_trace_points.c F: lib/librte_eventdev/rte_trace_eventdev*.h F: lib/librte_cryptodev/cryptodev_trace_points.c F: lib/librte_cryptodev/rte_trace_cryptodev*.h F: lib/librte_mempool/mempool_trace_points.c F: lib/librte_mempool/rte_trace_mempool*.h Once we exclude the trace framework, the trace points themselves should be the responsibility of the component (ethdev, eventdev...) maintainers (copied them). - I had something more dynamic in mind for gathering traces: like enabling/disabling trace points in a running process and getting the traces on the fly. But I suppose the current framework is enough and we can work on this later= . > > More details: > ~~~~~~~~~~~~~ > > # The Native DPDK CTF trace support does not have any dependency on > third-party library. > The generated output file is compatible with LTTng as both are using > CTF trace format. > > The performance gain comes from: > 1) exploit dpdk worker thread usage model to avoid atomics and use per > core variables > 2) use hugepage, > 3) avoid a lot function pointers in fast-path etc > 4) avoid unaligned store for arm64 etc > > Features: > ~~~~~~~~~ > - APIs and Features are similar to rte_log dynamic framework > API(expect log prints on stdout vs it dumps on trace file) I am not sure about the global and per tracepoint levels. We must enable each tracepoint anyway, the level is just a commodity. I don't have strong arguments against it, but it feels odd to copy/paste the rte_log framework. --=20 David Marchand