From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id D2DA843244 for ; Mon, 30 Oct 2023 16:40:11 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8DFA840285; Mon, 30 Oct 2023 16:40:11 +0100 (CET) Received: from mail-il1-f169.google.com (mail-il1-f169.google.com [209.85.166.169]) by mails.dpdk.org (Postfix) with ESMTP id 166324025F for ; Fri, 27 Oct 2023 20:43:05 +0200 (CEST) Received: by mail-il1-f169.google.com with SMTP id e9e14a558f8ab-3574f99d260so7595015ab.3 for ; Fri, 27 Oct 2023 11:43:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aviznetworks-com.20230601.gappssmtp.com; s=20230601; t=1698432184; x=1699036984; darn=dpdk.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=4hVsrkc/hLlA8MY6X0n1vJ2R5MjCYbeNxrylelWAzkU=; b=HiWb/d1CrROyCs4xQqMmjiGYnj/l66yjZit2MBDM9I64lvIXQiY885BDi5G53fkySf 711osfcppwWLkVgbgDuhe8yPWfRm2qygmPwzoWcny84+SN1HpCReI43LYnPg48XtKNsT NtOVVt8troLxcfnw/wAucpr3tZnmUJgTKXKT9+0UbRB0hCdvIDHjZZMeCt39c7hBuRrp KyJynkK2Yt18WRYC2+kHZL5fBWutJQBTuAPxayMiFzdShnjgGuukQzhrl2+kDEfqKXSB 2aLWJ72rioTjmbIF9A33H6ZXC7WnDPV06rem5L5V/a308LDO/8LBG/hzZjFWQN4xgJkY zgRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698432184; x=1699036984; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=4hVsrkc/hLlA8MY6X0n1vJ2R5MjCYbeNxrylelWAzkU=; b=rCu6R6x/8gJkobtapKSVgTzXab9Ybayz1evWgMV5jkKdYh8yXi3kC2vT7AZ1kIbhnD SvEbze1PUA//l5sB1P9UHHj7xKrUCzp3do33oCigmeVjxHOKHWDTOuP/WDFiVURufNp3 olJyaxNfvMrom5FkSWlnqlAu72FVTpNoJCC60rUykSKKRver/nBknp6pkwwmua37FiV5 veWwYPHsOXP4qpaIvXNlv2lwAagy90kUlYO/uZagGteFcL++5wTDFnEMDHD/ZGkX4EcE 0DljVz4q2Nd3n+UStiMBmIwjwHrvdlZ5yRa43JRc3AjDj837srvGDp3ugzc5vpGmSByb OfYg== X-Gm-Message-State: AOJu0Yybv+kFYBIBkzEqfJmDJu55pHRPylMjXfnCL9YCZI8UzSgW0Tze NUJtqa+xrhtqSZMTjsi09kpst4s1n0BxlpNtC/hs6g== X-Google-Smtp-Source: AGHT+IFBWNy4kli411B21W5FWf9aB0phfDnnO7xPmksAw5GnaO4Kf7B7EUf0Em2hXKrPjHU3kRuDcULplEOMxWdZh6o= X-Received: by 2002:a05:6e02:188d:b0:34c:e16d:6793 with SMTP id o13-20020a056e02188d00b0034ce16d6793mr4273620ilu.14.1698432184321; Fri, 27 Oct 2023 11:43:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Sanjit Kumar Date: Fri, 27 Oct 2023 11:42:53 -0700 Message-ID: Subject: Re: [dpdk-users] Unable to see traces from a user defined DPDK Tracepoint To: David Marchand Cc: users@dpdk.org, "utkarshece80587@gmail.com" , "4plague@gmail.com" <4plague@gmail.com>, Jerin Jacob Kollanukkaran , Sunil Kumar Kori , Harrish SJ Content-Type: multipart/alternative; boundary="00000000000005a9a70608b70f38" X-Mailman-Approved-At: Mon, 30 Oct 2023 16:40:10 +0100 X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org --00000000000005a9a70608b70f38 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Thank you for your email. I am already compiling the application that has the tracepoint register code with -DALLOW_EXPERIMENTAL_API but still am running into this issue. Are there any other possible causes for this behaviour? Thanks again. Regards, Sanjit Kumar On Fri, Oct 27, 2023 at 1:11=E2=80=AFAM David Marchand wrote: > Hello, > > Copying trace framework maintainers. > > On Fri, Oct 27, 2023 at 9:48=E2=80=AFAM Sanjit Kumar > wrote: > > I am trying to test the usage of the DPDK trace library. I have run int= o > the same issue as recounted here - > https://mails.dpdk.org/archives/users/2020-December/005266.html - where > I am able to build and run my DPDK application where I have created and > registered my custom trace point (verified via rte_trace_dump(stdout) whi= ch > says my traces are 'enabled' - i see the right trace buffer size, trace > file destination etc). The trace point creation and registration are > identical to what is mentioned in the program guide using RTE_TRACE_POINT > in a header file and registering it in my dpdk application via > RTE_TRACE_POINT_REGISTER macro. > > > > What I notice are as follows: > > > > 1. The program builds and runs as intended. > > 2. The trace files are generated in the correct destination directory. > > 3. On using trace=3D.* ----> I see a huge list of traces on viewing th= e > trace file with babeltrace - but do not see my custom trace point. I also > do not see any trace output from my dpdk application if I reuse DPDK > library traces ( eg: rte_eal_trace_thread_lcore_ready ) instead of defini= ng > my own custom traces. > > 4. On using trace=3D i do not = see > any trace output just used inside my application. > > > > I think the above observations suggest that the issue might be in > configuring my DPDK application to recognize and create trace output > properly. However the rte_trace_dump output suggests that trace is enable= d > here. > > > > What I would like to know is similar to utkarsh's question: > > Is there anything I am missing in configuring my application to > recognize traces? If so can you please point it out? > > I think a hint was posted later, about this topic. > Did you compile your application tracepoint register code with > -DALLOW_EXPERIMENTAL_API ? > > If you confirm it solves your issue, we need to enhance the trace > framework documentation. > > > -- > David Marchand > > --00000000000005a9a70608b70f38 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Thank you for your email. I am alre= ady compiling the application that has the tracepoint register code with -D= ALLOW_EXPERIMENTAL_API but still am running into this issue. Are there any = other possible causes for this behaviour? Thanks again.

Regards,
Sanjit Kumar

On Fri, Oct 27, 2023 at 1:11=E2= =80=AFAM David Marchand <da= vid.marchand@redhat.com> wrote:
Hello,

Copying trace framework maintainers.

On Fri, Oct 27, 2023 at 9:48=E2=80=AFAM Sanjit Kumar
<sanj= it.kumar@aviznetworks.com> wrote:
> I am trying to test the usage of the DPDK trace library. I have run in= to the same issue as recounted here - https://mails.dpdk.org/archives/users/2020-December/005266.html=C2=A0 = - where I am able to build and run my DPDK application where I have created= and registered my custom trace point (verified via rte_trace_dump(stdout) = which says my traces are 'enabled' - i see the right trace buffer s= ize, trace file destination etc). The trace point creation and registration= are identical to what is mentioned in the program guide using RTE_TRACE_PO= INT in a header file and registering it in my dpdk application via RTE_TRAC= E_POINT_REGISTER macro.
>
> What I notice are as follows:
>
> 1. The program builds and runs as intended.
> 2. The trace files are generated in the correct destination directory.=
> 3. On using trace=3D.*=C2=A0 ----> I see a huge list of traces on v= iewing the trace file with babeltrace - but do not see my custom trace poin= t. I also do not see any trace output from my dpdk application if I reuse D= PDK library traces ( eg: rte_eal_trace_thread_lcore_ready ) instead of defi= ning my own custom traces.
> 4. On using trace=3D<regex for traces used in my application> i = do not see any trace output just used inside my application.
>
> I think the above observations suggest that the issue might be in conf= iguring my DPDK application to recognize and create trace output properly. = However the rte_trace_dump output suggests that trace is enabled here.
>
> What I would like to know is similar to utkarsh's question:
> Is there anything I am missing in configuring my application to recogn= ize traces? If so can you please point it out?

I think a hint was posted later, about this topic.
Did you compile your application tracepoint register code with
-DALLOW_EXPERIMENTAL_API ?

If you confirm it solves your issue, we need to enhance the trace
framework documentation.


--
David Marchand

--00000000000005a9a70608b70f38--