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 E1FF3A0543; Wed, 14 Dec 2022 11:40:43 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BDEEC400D6; Wed, 14 Dec 2022 11:40:43 +0100 (CET) Received: from mail-vs1-f50.google.com (mail-vs1-f50.google.com [209.85.217.50]) by mails.dpdk.org (Postfix) with ESMTP id 4E2704003F for ; Wed, 14 Dec 2022 11:40:43 +0100 (CET) Received: by mail-vs1-f50.google.com with SMTP id 124so17432334vsv.4 for ; Wed, 14 Dec 2022 02:40:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=FNPoX1rERlx04ZcDCSW8dukQITohpaO6RwPouek4aV0=; b=IU9VeI96LsnGUci37365C2VROXpRh1SWbrrUQbaZigYDBYCUn8zh70KtPJ/F1qFc/Z NyAWoJRP1BK4NeijN2TUSC9132VMqPIzxNKEyFCx3/OPPAknrpvYVjksHGK/yDbNysgH /yQOHiW+ecsISBNu9YWz8XRpjXIJgSryZsmyW5INhTEtJG7/c35SA8sl9SiB24s/Gegn djH+9ufz1efBwGL9y2EapXaRP4HGLSPQK95hswI4q0pH7tdyuCB44GSh4/Dz4HqSavAt BLSq2p5A5AUA6ennyFGOKO/eI6fXV+pZFfXQTWRrfASL1iBI2m/TWNq/EBFNMA9OpAV5 dNfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=FNPoX1rERlx04ZcDCSW8dukQITohpaO6RwPouek4aV0=; b=i4e/eH7Pp3jGR2QN3p1HxQwBguMy4yIoIJPFxn9lTeyReojKKc5snV6to5N1hJoGCP X63cBRPzNygIqw47tu9uECMKFvNPSrItYusRiqBy5L7vjIDWcEb8GaWc27en0yShQ+Pi H/Vo1KyNVjn8sG1Z9ZZb9YNk3+cssjwvRh0My8OSmyHshocrmAcxktH2s+vSETqyveJ9 /5Rg9mlEgO5RUEh1Bfl+mJ7uXUuUJzljEpwDMT6eEJfR1Usx6s8CjaAo2s2xu1BIPAIl ZATR12xHrxa8lEo6s4lo8dunNVmxlOVV3v00kUtFxNTBxBPcBYAmxn8N9NV1s8EXhwmT O6Yw== X-Gm-Message-State: ANoB5pmtnGFU9Wja9WQkff7IvW5ULZasJsLZEnYw8dhkrdtcmT6/IPXl 2A9Dz5OWPhLGzX9O4lcN2I6kXE34lNJDfEtK59g= X-Google-Smtp-Source: AA0mqf4wcDTvyhlJo6LPesVpkI4tVE7ZtFM1xViPcdYskQMQ1M1YNKKRHhjSbX7/G0UNuR4lbwLrOmfU2eaEBmNlsjw= X-Received: by 2002:a67:e8c5:0:b0:3b0:bfc7:7bf5 with SMTP id y5-20020a67e8c5000000b003b0bfc77bf5mr11475849vsn.73.1671014442486; Wed, 14 Dec 2022 02:40:42 -0800 (PST) MIME-Version: 1.0 References: <20220929102936.5490-1-adwivedi@marvell.com> <20221006151844.23483-1-adwivedi@marvell.com> <20221006151844.23483-2-adwivedi@marvell.com> <9a458e46-f71c-22b6-63a2-5c425624275a@amd.com> In-Reply-To: <9a458e46-f71c-22b6-63a2-5c425624275a@amd.com> From: Jerin Jacob Date: Wed, 14 Dec 2022 16:10:16 +0530 Message-ID: Subject: Re: [PATCH v3 1/4] ethdev: add trace points To: Ferruh Yigit Cc: Ankur Dwivedi , dev@dpdk.org, thomas@monjalon.net, mdr@ashroe.eu, 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 Content-Type: text/plain; charset="UTF-8" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Wed, Dec 14, 2022 at 1:37 AM Ferruh Yigit wrote: > > On 10/6/2022 4:18 PM, Ankur Dwivedi wrote: > > Hi Ankur, Jerin, Hi Ferruh, Please find answers to generic trace questions. > > I have some major questions, I can see some already queried by Andrew as > well: > > 1) How flexible are we on changing trace log output? > Should we take trace log as kind of user interface and don't break it > (as much as possible)? Or is it OK to change whenever we want? If you see https://doc.dpdk.org/guides/prog_guide/trace_lib.html "Section: 6.9.3. Trace memory layout", Currently, we defined packet.header, packet.context, trace.header as minimum as required. It can be extended if needed. Trace payload is not fixed, it is created based on arguments of RTE_TRACE_POINT. > > > 2) What is the main purpose of the trace library. > Is it to record type and frequency of the calls? Or is it to log values > and state of the device/driver after each call? >From the framework POV, it can be used for both. I think, as first step, we can emit the traces for public DPDK APIs with return type of each API. > This can guide us to decide > - which values to record (should record only pointers or values of structs) > - if to record API return values and failure paths > - if to add tracing all APIs or not, like > 'rte_eth_dev_rx_offload_name()' kind of helper function that converts > offload to a string, which doesn't have any functional impact, or > 'rte_eth_speed_bitflag()', and many more... > > > 3) What is the runtime impact. Profiling overhead is one cycle. i.e. RTE_TRACE_POINT is added, and it is disabled at runtime. For RTE_TRACE_POINT_FP it is zero if it is not enabled at compile time. > As far as I can see some values copied and some memory is used for this > support, even user is not interested in tracing. For control path APIs > we can ignore the additional cost by memcpy, but how big memory > requirement is? Currently, per core/thread 1MB trace buffer is created as default. The size can be overridden via EAL command line argument. See __rte_trace_mem_per_thread_alloc(). If you see https://doc.dpdk.org/guides/prog_guide/trace_lib.html section "6.5. Event record mode", it has two modes Overwrite - When the trace buffer is full, new trace events overwrites the existing captured events in the trace buffer. Discard - When the trace buffer is full, new trace events will be discarded. > > > 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 = rte_trace_point_lookup("app.dpdk.test.tp"); rte_trace_point_enable(trace); > > > > 5) (bonus Q) Can we have an 'rte_trace_point_emit_xx()' function to > record mac address (struct rte_ether_addr) as string? > And maybe another set for array types? Yes it possible and better to add rte_trace_pint_emit_,mac() or so. > > > There are bunch of small comments inline, some are related to above > highlevel question. > But I stopped after some point, specifically after > 'rte_eth_trace_timesync_adjust_time()' :), this is a big file, splitting > it may help reviewers. >