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 1ABBAA00C2; Mon, 26 Sep 2022 17:03:25 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 08D5541133; Mon, 26 Sep 2022 17:03:25 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 1474340DF7 for ; Mon, 26 Sep 2022 17:03:24 +0200 (CEST) Received: from [192.168.38.17] (aros.oktetlabs.ru [192.168.38.17]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id F33CC5E; Mon, 26 Sep 2022 18:03:22 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru F33CC5E DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1664204603; bh=4md2+zWNYOR5vdTGa18o7rw8hzVghULf6I5Wg5maSLY=; h=Date:Subject:From:To:Cc:References:In-Reply-To:From; b=YJDTT9szyZvs0oFafds1qnrxmyv8f5g7/r0nVy+2zHQx0JF4QauEseMbx2/lmbO2w +UTJU6sCLPsmdF/qpbrP2wIDdfIqWqsWz8teXYTZoS4Ot/57+R/aWqV72KXjUkFcPj lb4xvVZL1Bhy6Bg6Tohm0rvhWg3KVldClBBWcdmk= Message-ID: <4508c74a-3530-5c08-a824-c72dc327dadd@oktetlabs.ru> Date: Mon, 26 Sep 2022 18:03:22 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0 Subject: Re: [EXT] Re: [PATCH 1/6] ethdev: add trace points Content-Language: en-US From: Andrew Rybchenko To: Ankur Dwivedi , "dev@dpdk.org" , Jerin Jacob Kollanukkaran Cc: "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" , Igor Russkikh , "shepard.siegel@atomicrules.com" , "ed.czeck@atomicrules.com" , "john.miller@atomicrules.com" , "ajit.khaparde@broadcom.com" , "somnath.kotur@broadcom.com" , "Maciej Czekaj [C]" , Shijith Thotton , Srisivasubramanian Srinivasan , Harman Kalra , "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" , Nithin Kumar Dabilpuram , Kiran Kumar Kokkilagadda , Sunil Kumar Kori , Satha Koteswara Rao Kottidi , Liron Himi , "zr@semihalf.com" , Radha Chintakuntla , Veerasenareddy Burru , Sathesh B Edara , "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" , Rasesh Mody , Shahed Shaikh , Devendra Singh Rawat , "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" References: <20220804134430.6192-1-adwivedi@marvell.com> <20220804134430.6192-2-adwivedi@marvell.com> Organization: OKTET Labs In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 @Jerin, I'd like to know what do you think about my question/thoughts below. On 9/13/22 10:18, Andrew Rybchenko wrote: > On 9/13/22 09:48, Ankur Dwivedi wrote: >> Hi Andrew, >> >>> -----Original Message----- >>> From: Andrew Rybchenko >>> Sent: Monday, September 12, 2022 4:30 PM >>> To: Ankur Dwivedi ; dev@dpdk.org >>> Cc: 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; Igor >>> Russkikh ; shepard.siegel@atomicrules.com; >>> ed.czeck@atomicrules.com; john.miller@atomicrules.com; >>> ajit.khaparde@broadcom.com; somnath.kotur@broadcom.com; Jerin Jacob >>> Kollanukkaran ; Maciej Czekaj [C] >>> ; Shijith Thotton ; >>> Srisivasubramanian Srinivasan ; Harman Kalra >>> ; 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; Nithin >>> Kumar Dabilpuram ; Kiran Kumar Kokkilagadda >>> ; Sunil Kumar Kori ; Satha >>> Koteswara Rao Kottidi ; Liron Himi >>> ; zr@semihalf.com; Radha Chintakuntla >>> ; Veerasenareddy Burru ; >>> Sathesh B Edara ; 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; Rasesh Mody >>> ; Shahed Shaikh ; Devendra >>> Singh Rawat ; 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 >>> Subject: [EXT] Re: [PATCH 1/6] ethdev: add trace points >>> >>> External Email >>> >>> ---------------------------------------------------------------------- >>> On 8/4/22 16:44, Ankur Dwivedi wrote: >>>> Add trace points for ethdev functions. >>>> >>>> Signed-off-by: Ankur Dwivedi >>>> --- >>> >>> [snip] >>> >>>> diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c index >>>> 1979dc0850..a6fb370b22 100644 >>>> --- a/lib/ethdev/rte_ethdev.c >>>> +++ b/lib/ethdev/rte_ethdev.c >>> >>> [snip] >>> >>>> @@ -525,6 +536,7 @@ rte_eth_dev_owner_delete(const uint64_t >>> owner_id) >>>> >>>>        rte_spinlock_unlock(ð_dev_shared_data->ownership_lock); >>>> >>>> +    rte_ethdev_trace_owner_delete(owner_id, ret); >>> >>> I'm wondering why trace is sometimes added in the middle of the >>> function, >>> but in the majority of cases it is added as the first or the last >>> action. Is there >>> any logical/guidelines behind it? >> In this case for printing the return value the trace was added at the >> end. I can change it if not required. >> The logic which I used was to log at least the input arguments of a >> function and in some cases also log important information(according to >> me) if possible.For example in rte_eth_tx_buffer_count_callback() I >> was also logging the count at the end. Similar logic in >> rte_eth_link_get_nowait(). >> Please let me know your views. > > The answer depends on purposes of tracing. I guess that the > main goal is to understand what the application does. So, > tracing without logging the result does not sound really > useful. What's the point to see that application has tried > to enable promiscuous mode without knowing the result if > the attempt is successful or not? If failures are critical > for the application functionality, hopefully it will > result in error logging which could be used together with > tracing to understand what happens. > > If so, it drives us to tracing nearby the end of the function > when the function really has tried to do something. If there is > no branching there we'll have some tracing of failures as well, > but we definitely need to see the result in the trace point. > > I almost have no experience with tracing, so my thoughts > could be wrong. Meanwhile I've updated the patch series as "Requested Changes" since some fixes were promissed in v2.