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 BE5C743212 for ; Fri, 27 Oct 2023 09:47:56 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 773D84029A; Fri, 27 Oct 2023 09:47:56 +0200 (CEST) Received: from mail-io1-f41.google.com (mail-io1-f41.google.com [209.85.166.41]) by mails.dpdk.org (Postfix) with ESMTP id 49E2040275 for ; Mon, 23 Oct 2023 23:52:20 +0200 (CEST) Received: by mail-io1-f41.google.com with SMTP id ca18e2360f4ac-7a92727934eso93037439f.3 for ; Mon, 23 Oct 2023 14:52:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aviznetworks-com.20230601.gappssmtp.com; s=20230601; t=1698097939; x=1698702739; darn=dpdk.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=r578XCy8b9GaotuUi8COJt3/5zNPfnu0Hp5ialk4Aj8=; b=iZP1W/KvwEUzw/aK8jSJ7AHA5x468MqOm+8R92oSWUK187VFJ5nK0odIoUquxswGDa 4XMYEAUJH4jilhCku6+S1Qa08uCivXxCaWreNs5Qf9oz2AIKy8806/Tb8lxHXDfDGXeb NQ0mn6yPTQ1ym3LXZ2eAxBe/R3HCY7MWMLj0ggf67aG1knwPfzrmrXSYHETWTkO+ESQc 9LPuLaPxNPUEyXQD/D8k1zF1hUHaWz6IYup0Es3gP5BmPIOsxmOh1lM1Up9ISPNSowUQ Nbgj87eoWkxb/oP7UHIqCKPz3xkZmiPoa5NRQvUHAos6PQW2u1GceAC/7FPP7wajLRkU EJ6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698097939; x=1698702739; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=r578XCy8b9GaotuUi8COJt3/5zNPfnu0Hp5ialk4Aj8=; b=EeYFVzjTpYJhF6iW4ht32KkGTikaCImbWZ0OW+iTrsGCR6h4kgmIj/WNceUEO8oDCa XnwtgnL4r/Ft4uFItMB8Yr63fFc/PMej7A95z341ij8RLxRt4UruaWPUPIzSXNTSPEUp GijnyMKoecRUpxiiMP4ivMKEN/FmNovXF5jgkILWEN1R+dkznJ9giUtNk3GA2DPR71Ve 3VGNWZ7ghLdce0IY7NTdkY+nMa8AT4iU7A/3KTkQo0gvsB07aR/gjNsNyJnCb2mrTHw5 gdIWwzCM1ULbric6PXLFBxByUgKkH0iU7PFPPG4TMVeNdKrvkdNXUFKTIN/Pn4E+SyK5 +mxw== X-Gm-Message-State: AOJu0Yz9kFos3/760EDdT1TOE4Uc8KePj+cQ5k4/l8IhzOmWmZVHsfFc i4FrCLcJykum5sV7c3vyOY8JZz8xnHZlphtmJ708Hk/X69GxKabpRNIcMg== X-Google-Smtp-Source: AGHT+IEf0hEyXLHinGUL1DNFJGG2MmDzVtNRQ9JhkJ6P6KXawUB/4+9Foz2iHCAEKShpsoWyIvgXzetM80p/MAbwEdw= X-Received: by 2002:a05:6e02:1be8:b0:357:97fb:b173 with SMTP id y8-20020a056e021be800b0035797fbb173mr14831276ilv.28.1698097939319; Mon, 23 Oct 2023 14:52:19 -0700 (PDT) MIME-Version: 1.0 From: Sanjit Kumar Date: Mon, 23 Oct 2023 14:52:08 -0700 Message-ID: Subject: Re: [dpdk-users] Unable to see traces from a user defined DPDK Tracepoint To: users@dpdk.org, "utkarshece80587@gmail.com" Content-Type: multipart/alternative; boundary="00000000000077a3350608693ca2" X-Mailman-Approved-At: Fri, 27 Oct 2023 09:47:55 +0200 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 --00000000000077a3350608693ca2 Content-Type: text/plain; charset="UTF-8" Hi, I am trying to test the usage of the DPDK trace library. I have run into 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) which 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=.* ----> I see a huge list of traces on viewing the 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 defining my own custom traces. 4. On using trace= 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 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 recognize traces? If so can you please point it out? Thanks and Regards, Sanjit Kumar --00000000000077a3350608693ca2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I am trying to test the usage of th= e DPDK trace library. I have run into the same issue as recounted here - h= ttps://mails.dpdk.org/archives/users/2020-December/005266.html=C2=A0=C2= =A0- where I am able to build and run my DPDK application where I have crea= ted and registered my custom=C2=A0trace point (verified via rte_trace_dump(= stdout) which says my traces are 'enabled'=C2=A0- i see the right t= race 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.=C2=A0

What I = notice are as follows:

1. The program builds and r= uns as intended.
2. The trace files are generated in the correct = destination directory.=C2=A0
3. On using trace=3D.* =C2=A0= ----> I see a huge list of traces on viewing the trace file with babeltr= ace - but do not see my custom trace point. I also do not see any trace out= put=C2=A0from my dpdk application if I reuse DPDK library traces ( eg: rte_= eal_trace_thread_lcore_ready ) instead of defining=C2=A0my own custom trace= s.
4. On using trace=3D<regex for traces used in my applicatio= n> i do not see any trace output just used inside my application.
<= div>
I think the above observations suggest that the issue mi= ght be in configuring my DPDK application to recognize and create trace out= put properly. However the rte_trace_dump output suggests that trace is enab= led here.=C2=A0

What I would like to know is simil= ar to utkarsh's=C2=A0question:
Is there anything I am missing= in configuring my application to recognize traces? If so can you please po= int it out?


Thanks and Regards,
Sanjit Kumar
--00000000000077a3350608693ca2--