From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 909B3423B5;
	Thu, 12 Jan 2023 10:43:41 +0100 (CET)
Received: from mails.dpdk.org (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id 3B25E40156;
	Thu, 12 Jan 2023 10:43:41 +0100 (CET)
Received: from smartserver.smartsharesystems.com
 (smartserver.smartsharesystems.com [77.243.40.215])
 by mails.dpdk.org (Postfix) with ESMTP id C21D6400EF
 for <dev@dpdk.org>; Thu, 12 Jan 2023 10:43:39 +0100 (CET)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: trace point symbols
Date: Thu, 12 Jan 2023 10:43:38 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D87666@smartserver.smartshare.dk>
In-Reply-To: <2036238.VLH7GnMWUR@thomas>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: trace point symbols
Thread-Index: AdkmZc0Jo+59rZT0TtGhhiCY4BgiXQAAf/SQ
References: <20220929102936.5490-1-adwivedi@marvell.com>
 <7a06cfd9-f9de-2df5-d172-44aef97b7529@amd.com>
 <CALBAE1PUrWvOAHvsk1Qy6xEqwdWjgLUROBcFes8ddZmPyTqMVg@mail.gmail.com>
 <2036238.VLH7GnMWUR@thomas>
From: =?iso-8859-1?Q?Morten_Br=F8rup?= <mb@smartsharesystems.com>
To: "Thomas Monjalon" <thomas@monjalon.net>,
 "Ferruh Yigit" <ferruh.yigit@amd.com>,
 "Jerin Jacob" <jerinjacobk@gmail.com>, <jerinj@marvell.com>,
 <bruce.richardson@intel.com>
Cc: <dev@dpdk.org>, "Ankur Dwivedi" <adwivedi@marvell.com>, <orika@nvidia.com>,
 <ferruh.yigit@xilinx.com>, <chas3@att.com>, <humin29@huawei.com>,
 <linville@tuxdriver.com>, <ciara.loftus@intel.com>, <qi.z.zhang@intel.com>,
 <mw@semihalf.com>, <mk@semihalf.com>, <shaibran@amazon.com>,
 <evgenys@amazon.com>, <igorch@amazon.com>, <chandu@amd.com>,
 <irusskikh@marvell.com>, <shepard.siegel@atomicrules.com>,
 <ed.czeck@atomicrules.com>, <john.miller@atomicrules.com>,
 <ajit.khaparde@broadcom.com>, <somnath.kotur@broadcom.com>,
 <jerinj@marvell.com>, <mczekaj@marvell.com>, <sthotton@marvell.com>,
 <srinivasan@marvell.com>, <hkalra@marvell.com>,
 <rahul.lakkireddy@chelsio.com>, <johndale@cisco.com>, <hyonkim@cisco.com>,
 <liudongdong3@huawei.com>, <yisen.zhuang@huawei.com>,
 <xuanziyang2@huawei.com>, <cloud.wangxiaoyun@huawei.com>,
 <zhouguoyang@huawei.com>, <simei.su@intel.com>, <wenjun1.wu@intel.com>,
 <qiming.yang@intel.com>, <Yuying.Zhang@intel.com>, <beilei.xing@intel.com>,
 <xiao.w.wang@intel.com>, <jingjing.wu@intel.com>, <junfeng.guo@intel.com>,
 <rosen.xu@intel.com>, <ndabilpuram@marvell.com>, <kirankumark@marvell.com>,
 <skori@marvell.com>, <skoteshwar@marvell.com>, <lironh@marvell.com>,
 <zr@semihalf.com>, <radhac@marvell.com>, <vburru@marvell.com>,
 <sedara@marvell.com>, <matan@nvidia.com>, <viacheslavo@nvidia.com>,
 <sthemmin@microsoft.com>, <longli@microsoft.com>, <spinler@cesnet.cz>,
 <chaoyong.he@corigine.com>, <niklas.soderlund@corigine.com>,
 <hemant.agrawal@nxp.com>, <sachin.saxena@oss.nxp.com>, <g.singh@nxp.com>,
 <apeksha.gupta@nxp.com>, <sachin.saxena@nxp.com>, <aboyer@pensando.io>,
 <rmody@marvell.com>, <shshaikh@marvell.com>, <dsinghrawat@marvell.com>,
 <andrew.rybchenko@oktetlabs.ru>, <jiawenwu@trustnetic.com>,
 <jianwang@trustnetic.com>, <jbehrens@vmware.com>,
 <maxime.coquelin@redhat.com>, <chenbo.xia@intel.com>,
 <steven.webster@windriver.com>, <matt.peters@windriver.com>,
 <bruce.richardson@intel.com>, <mtetsuyah@gmail.com>, <grive@u256.net>,
 <jasvinder.singh@intel.com>, <cristian.dumitrescu@intel.com>,
 <jgrajcia@cisco.com>, <david.marchand@redhat.com>
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
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

> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Thursday, 12 January 2023 10.11
>=20
> 15/12/2022 07:49, Jerin Jacob:
> > On Wed, Dec 14, 2022 at 5:40 PM Ferruh Yigit <ferruh.yigit@amd.com>
> wrote:
> > >
> > > On 12/14/2022 10:40 AM, Jerin Jacob wrote:
> > > > On Wed, Dec 14, 2022 at 1:37 AM Ferruh Yigit
> <ferruh.yigit@amd.com> wrote:
> > > >> 4) Why we need to export trace point variables in the .map
> files,
> > > >> like '__rte_eth_trace_allmulticast_disable' one...
> > > >
> > > > If you see app/test/test_trace.c example
> > > >
> > > > There are two-way to operate on trace point, We need to export
> symbol
> > > > iff we need option 1
> > > >
> > > > option1:
> > > > rte_trace_point_enable(&__app_dpdk_test_tp);
> > > >
> > > > option2:
> > > > rte_trace_point_t *trace =3D
> rte_trace_point_lookup("app.dpdk.test.tp");
> > > > rte_trace_point_enable(trace);

rte_trace_point_enable() allows passing a NULL pointer, so enabling a =
trace point can still be a one-liner:

rte_trace_point_enable(rte_trace_point_lookup("app.dpdk.test.tp"));

With option2, we lose the build-time error if trying to enable a =
non-existing trace point. But it's an acceptable tradeoff.

> > > >
> > >
> > > got it, do we really need direct access to trace point (option 1),
> I
> > > would be OK to remove that option to not expose all these trace
> point
> > > objects.
> >
> > Looks good to me.
>=20
> I would like to see a policy regarding trace symbols.
> If we decide option 1 is not so useful,
> then we should not export trace symbols at all and document this
> policy.
> Also there are some trace symbols which could be cleaned up.

+1 for not exposing trace point symbols at all.

The trace point symbols are only used internally by DPDK, so they should =
not be part of DPDK's public API.

It might also make it easier for Bruce to move the trace library out of =
EAL.

I'm not familiar with the CTF format, but I assume that if we don't =
expose the trace point symbols, the trace points can still be identified =
when parsing the trace file.