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 307B1A00C3; Tue, 13 Sep 2022 09:18:34 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1188B40156; Tue, 13 Sep 2022 09:18:34 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id A8AB940151 for ; Tue, 13 Sep 2022 09:18:32 +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 B29ED7B; Tue, 13 Sep 2022 10:18:31 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru B29ED7B DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1663053511; bh=+wjWqeyoxVzYnb0xq4hbZwIbpK1Aix2oGYP8PmHUcEQ=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=qtgrZP9nGpB/SpPMZ+tb6mhGOY0lAjo4EPgoP7SAOK84TuRhy/mXrWCoxi7PQZoIU r/ALEsCHM68aeOVCo4J7t+qKLSVTRYk8CmL4z6lYBGKIG2ry9535RveTaPiy4oea97 4h62hMWQ6G12QrwAIB7l6qhqICIJOyTpWxuSZdOA= Message-ID: Date: Tue, 13 Sep 2022 10:18:30 +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 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" , 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" References: <20220804134430.6192-1-adwivedi@marvell.com> <20220804134430.6192-2-adwivedi@marvell.com> From: Andrew Rybchenko Organization: OKTET Labs In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 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.