From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
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 <dev@dpdk.org>; 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 <dev@dpdk.org>; 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 <david.marchand@redhat.com>
Date: Wed, 1 Apr 2020 10:18:48 +0200
Message-ID: <CAJFAV8zJrXvrR0epT-rbHRT0Cd319fLQcxT9AmEiUKGm4tX0Pw@mail.gmail.com>
To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
Cc: dev <dev@dpdk.org>, Thomas Monjalon <thomas@monjalon.net>, 
 Bruce Richardson <bruce.richardson@intel.com>, 
 =?UTF-8?Q?Mattias_R=C3=B6nnblom?= <mattias.ronnblom@ericsson.com>, 
 Sunil Kumar Kori <skori@marvell.com>, "Yigit, Ferruh" <ferruh.yigit@intel.com>,
 Andrew Rybchenko <arybchenko@solarflare.com>,
 Declan Doherty <declan.doherty@intel.com>, 
 Olivier Matz <olivier.matz@6wind.com>, Neil Horman <nhorman@tuxdriver.com>
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

Hello Jerin,

On Sun, Mar 29, 2020 at 4:43 PM <jerinj@marvell.com> 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 <jerinj@marvell.com>
M: Sunil Kumar Kori <skori@marvell.com>
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