> @Jerin, I'd like to know what do you think about my question/thoughts below
@Andrew Rybchenko see 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 <andrew.rybche...@oktetlabs.ru> > >>> Sent: Monday, September 12, 2022 4:30 PM > >>> To: Ankur Dwivedi <adwiv...@marvell.com>; dev@dpdk.org > >>> Cc: tho...@monjalon.net; m...@ashroe.eu; or...@nvidia.com; > >>> ferruh.yi...@xilinx.com; ch...@att.com; humi...@huawei.com; > >>> linvi...@tuxdriver.com; ciara.lof...@intel.com; qi.z.zh...@intel.com; > >>> m...@semihalf.com; m...@semihalf.com; shaib...@amazon.com; > >>> evge...@amazon.com; igo...@amazon.com; cha...@amd.com; Igor > >>> Russkikh <irussk...@marvell.com>; shepard.sie...@atomicrules.com; > >>> ed.cz...@atomicrules.com; john.mil...@atomicrules.com; > >>> ajit.khapa...@broadcom.com; somnath.ko...@broadcom.com; Jerin Jacob > >>> Kollanukkaran <jer...@marvell.com>; Maciej Czekaj [C] > >>> <mcze...@marvell.com>; Shijith Thotton <sthot...@marvell.com>; > >>> Srisivasubramanian Srinivasan <sriniva...@marvell.com>; Harman Kalra > >>> <hka...@marvell.com>; rahul.lakkire...@chelsio.com; johnd...@cisco.com; > >>> hyon...@cisco.com; liudongdo...@huawei.com; > >>> yisen.zhu...@huawei.com; xuanziya...@huawei.com; > >>> cloud.wangxiao...@huawei.com; zhouguoy...@huawei.com; > >>> simei...@intel.com; wenjun1...@intel.com; qiming.y...@intel.com; > >>> yuying.zh...@intel.com; beilei.x...@intel.com; xiao.w.w...@intel.com; > >>> jingjing...@intel.com; junfeng....@intel.com; rosen...@intel.com; Nithin > >>> Kumar Dabilpuram <ndabilpu...@marvell.com>; Kiran Kumar Kokkilagadda > >>> <kirankum...@marvell.com>; Sunil Kumar Kori <sk...@marvell.com>; Satha > >>> Koteswara Rao Kottidi <skotesh...@marvell.com>; Liron Himi > >>> <lir...@marvell.com>; z...@semihalf.com; Radha Chintakuntla > >>> <rad...@marvell.com>; Veerasenareddy Burru <vbu...@marvell.com>; > >>> Sathesh B Edara <sed...@marvell.com>; ma...@nvidia.com; > >>> viachesl...@nvidia.com; sthem...@microsoft.com; lon...@microsoft.com; > >>> spin...@cesnet.cz; chaoyong...@corigine.com; > >>> niklas.soderl...@corigine.com; hemant.agra...@nxp.com; > >>> sachin.sax...@oss.nxp.com; g.si...@nxp.com; apeksha.gu...@nxp.com; > >>> sachin.sax...@nxp.com; abo...@pensando.io; Rasesh Mody > >>> <rm...@marvell.com>; Shahed Shaikh <shsha...@marvell.com>; Devendra > >>> Singh Rawat <dsinghra...@marvell.com>; jiawe...@trustnetic.com; > >>> jianw...@trustnetic.com; jbehr...@vmware.com; > >>> maxime.coque...@redhat.com; chenbo....@intel.com; > >>> steven.webs...@windriver.com; matt.pet...@windriver.com; > >>> bruce.richard...@intel.com; mtetsu...@gmail.com; gr...@u256.net; > >>> jasvinder.si...@intel.com; cristian.dumitre...@intel.com; > >>> jgraj...@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 <adwiv...@marvell.com> > >>>> --- > >>> > >>> [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. Yes. It make sense to include the result. For example, rte_malloc etc we are already adding the result so the consumer of trace can get better view. > > > > 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.
