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 2FD7041B91; Tue, 31 Jan 2023 19:38:44 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C4F6A40684; Tue, 31 Jan 2023 19:38:43 +0100 (CET) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2054.outbound.protection.outlook.com [40.107.223.54]) by mails.dpdk.org (Postfix) with ESMTP id 9C37A4067B for ; Tue, 31 Jan 2023 19:38:42 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lOEF3N7T09l1TxVvdFratd/Yev0OrIwFO4yL15Gm5v/jH9s/s/esd+tgxbjs4ZXGRafCFx2uRTeawP9hiohMn4VLKGbehonVWep7Ex/xcJfq4At3jMrAgFaWbu9q0pguo/jlnzRe5826y5NMV9+KnwEsKxFaHCXEKbza2rw+MAiAH+xhQVfZZA9Z3vHBgvaYAKotvcm+mO6oe86kH+kkGdgG35uYEZ5MHTdUIpzHq1qpHSA0vKKs1J8v0avT77Osj6Rpqkzz1zUsvkMWMKyBwCwnt1S5SZMI9faUXUY2O/jf/YYy6URDxiOqwijm+2P3d/OlqqVA9hLoBKgan8sc4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=SiX1bwPZaHRVoIMw2AJZgbiKaBdwvxG+5YEh6q2nohc=; b=l+B4cj+6tQNAIVLcT4Leobes6yN8s69ZbuyL8Jrfa6W0oNMpQveEbXhljUpnqC2f6VDim40tgtAr3OYJLlbn+gPt1wj8Fjo2cDzb2hfwEwsLHZaX2HmUY4VE4NMJaeWMTDzdIPjA7XVZ1OZAZeZRnaopiBS46AtHXLFj/DxPgYUL1IFeqT0l8Ppt10vKcMyZDGQV90Oftg1A2Rg7NhsT+Q33IlHyKtWVJl55NV0jwBJXspwJD5PQCf/eDyc0QHz9APRouDiwytNL63aI2effzgaEHWA1TXpL4E9nd/JHD4EYptwH8XK+e9nA4Dujd+83LVaK0W5gu9L4Hx5+s2s/vg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SiX1bwPZaHRVoIMw2AJZgbiKaBdwvxG+5YEh6q2nohc=; b=TympfA9dfmtiVbcWxXQpBUjK/cISSucZ+uX0zkLHh8gJys6UYAK5rR/4gkYXBAEjI4s91EjtaV3Z3KWdxv3awY2ZtCXC7CYSBBxxq01N6TmY8x7oAKjG9bz+fOtwp3Nua1J2Uf8vJiHcKstKnLk00RRmjfvN76yBDDali/kWZtk= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Received: from CH2PR12MB4294.namprd12.prod.outlook.com (2603:10b6:610:a9::11) by PH0PR12MB5418.namprd12.prod.outlook.com (2603:10b6:510:e5::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6043.38; Tue, 31 Jan 2023 18:38:39 +0000 Received: from CH2PR12MB4294.namprd12.prod.outlook.com ([fe80::4807:1f44:5e04:e05a]) by CH2PR12MB4294.namprd12.prod.outlook.com ([fe80::4807:1f44:5e04:e05a%8]) with mapi id 15.20.6043.038; Tue, 31 Jan 2023 18:38:39 +0000 Message-ID: <91a635b5-3fe5-b47d-d8ba-44f9b1614bf9@amd.com> Date: Tue, 31 Jan 2023 18:38:22 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Content-Language: en-US To: Ankur Dwivedi , "dev@dpdk.org" , David Marchand , Jerin Jacob Kollanukkaran , Andrew Rybchenko Cc: "thomas@monjalon.net" , "mdr@ashroe.eu" , "orika@nvidia.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" , "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 , "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" , "mb@smartsharesystems.com" References: <20230112112140.807233-1-adwivedi@marvell.com> <20230120084059.2926575-1-adwivedi@marvell.com> <20230120084059.2926575-3-adwivedi@marvell.com> <614e22c6-8485-0e8d-742e-b3d100f96468@amd.com> From: Ferruh Yigit Subject: Re: [EXT] Re: [PATCH v6 2/6] ethdev: add trace points for ethdev (part one) In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P265CA0166.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:312::10) To CH2PR12MB4294.namprd12.prod.outlook.com (2603:10b6:610:a9::11) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH2PR12MB4294:EE_|PH0PR12MB5418:EE_ X-MS-Office365-Filtering-Correlation-Id: 3799340c-c249-40dd-611e-08db03ba5e4a X-LD-Processed: 3dd8961f-e488-4e60-8e11-a82d994e183d,ExtAddr X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: H4Wm9fbxb82ON2vr5s84zIdKrZhPV8JjzvhDeXmIKhIR4bgGuC7b2nAyZ+IiQADEwiaGrJ1BVuelSunGeEQf0ppLseNfk0eYujxEGLIoL0kfFGc2L/1sFfDaQx4Jh+WnzlhM6YwIRRCUvzw0GrOpBx89K4SfNDqe3fyDkSedYwaoHQxjc/lkY1dcwcZDt76WpSyas6UFNbJyah4qIguASOZsLHNKqx29kV0l7Xx48eolva6qsQSw5Vjts7daRKzxzpHzIMEcq3+9zlI9mBybhm57ytBVBN9UqP7zqj0+YCUjYQ6ZhL5L17C+RTo/L1MDjRliiGvlbIJkDlUN+qy5sPzpRU0uCjtRu3Pr7nOr0mX1daPUdIBwJkbAlcZpjFUun92H8RQsNAtWKPoTMoOxIE9x0CTLjOzxMTMKdB7ydoYIMq4X4i+ivovv4+qGWeuLEqnorLMVBE6mZy/I2qYgNMYc9fsL/IzcQqn5oM8vtbARdxoe5HeiO9fpfVQJ/ggLNpDxcPhPdcj2MLXYSaxyI4t3/4eSfs91nxQR5s+Rv+43q4BfsVD3O4Xgop+e407PZuDoclxeg3PnALD00WiHDc2TW7zCi10+v6w3CLnaYE3u8LhgXjp21fXIqSL0GTMufLWVDuy0G4WaN8la/iCnm30yBwH7L0cnPelzDJgbRh1nO8FZlLcauuIynYERwPmkAYpTc6QI/Jcptg5oUnVlQ17GpziCN6Ge98UzFFxF3ek= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR12MB4294.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230025)(4636009)(376002)(366004)(396003)(346002)(136003)(39860400002)(451199018)(38100700002)(86362001)(66556008)(31696002)(36756003)(66946007)(41300700001)(8936002)(5660300002)(7416002)(7336002)(7366002)(54906003)(110136005)(316002)(66476007)(4326008)(8676002)(7406005)(2906002)(44832011)(83380400001)(2616005)(6486002)(478600001)(186003)(53546011)(26005)(6512007)(6506007)(6666004)(31686004)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?UmpKMmNVeS8vRURib3Z0cmFpbzRReGdQTlJWNEE3Q3NRYW1TdmdFRHRyK05v?= =?utf-8?B?TWR2M1NGMGo0VjFNUXVtRHFBWnZpMFJDWmFNNU0rVnkzK3MvNG5YUS80RmE1?= =?utf-8?B?cy9ESzdHalFNS0VObkRJY3h4MWJUcDl0TW1lV2lKWDZxQ0o2RHhqWWhOSHlp?= =?utf-8?B?RmNLQWwyVGdlYk9GMjNVNHUrSzdXRzlZcTZhVDNvZjRYc09IaktFSHFnc1U0?= =?utf-8?B?dXdJNEV4ZWJQdjQ3VnA5dlE2NUFpNC90QUVNNzhkekVUbUJTR2cvUGZaSWZC?= =?utf-8?B?YzlMcFBFU1hNQm4zRSs2U3NoaWt4K3JTb0NNSXdRTm95NUduQWlaclFKc25N?= =?utf-8?B?TWpMYjdIYWkzUktwUnBQV29ONG4yeE5MV1I2UkF2RVYrY0JhR3RNVTA1VXhl?= =?utf-8?B?LzB2dVpFUHUwSEc3QkxUL1l4WjJqMGdZbHBGd1BNTlhvOWMyb205RFZpOVpo?= =?utf-8?B?d1YwUG1EVk5jcU5wUEM0UlU5Q2ZEdTM1TFZqcFR3QUd2aWRsK1ljSVFDajFn?= =?utf-8?B?THFzdksvVCtGOTE3bmphS2k4OGZjZTJBVnVwb3gxRzdkdis3RXZHaSsrQTds?= =?utf-8?B?RkovMFVpeXlMcis4VmsrbGJoZ215REIrUERxOWdocDFVcmhEK3ZqMndaaXg4?= =?utf-8?B?aGhDZWhvSlArOUpQZmIxQWs4dVV3VDkvZEdBVWI5NGtoREpPSDdDdG16eGpJ?= =?utf-8?B?M2FEektHdEFVcEFuNDdWYTIranJxRnJnQnFkSUNnYnphY1l2anF4M1pHVDhJ?= =?utf-8?B?VTUyTWpMZzVjSWc0eUZUc1F6ZXRRb2lWY2lmOEg5Tm81eXFId2pnTWVYbERi?= =?utf-8?B?UU5qSm9VM3MvUUxtWHcwcVRpL3ZUbFN3dk1Ud1JzaHN2UCs1N3IvN3Q3UllW?= =?utf-8?B?RXJyNDFrNjdzcDRSdnZBM2x6czNQSmhQYWNqRUNqMkdPZEE2aS9lMjdIaU5O?= =?utf-8?B?ZVJ4K0Z2Z28xblpVdGs2RzdJTTN4aDhJc0ZISWozZUkwNTZ2ZFZlSDlOaEUv?= =?utf-8?B?VmVBR08rb1Fudnk1OVF0ejBST3ZHc2FsN1FJaEpjcG1PVVl2aWIwYkd5ZVZB?= =?utf-8?B?RUd5V2JWS1FvK29GdFFWZTdYaGZvZE10R2xOdTFtUkpHV0MreFFmUXdjeGFZ?= =?utf-8?B?SGVXREZ5OExtZXdDOEdvNW1EZkkzT2ZNOG9LekViNktLSFR2TURhMHR5SHF2?= =?utf-8?B?YWxGa1EyaENnWm1TQmI5dndGNWVnWWlDNEJFMndURFE0VmZhdDNOQzZNMHlS?= =?utf-8?B?L0IxcjVva3FBZnJXSjhCUm5QZ1g3VzU5eUl6dVU0dEJTQ0VhbXVOOEFuZExT?= =?utf-8?B?MkxhUFRLZjNQTHc2djFjV2h0V0hTeW9UditXMGh0dFVwVEVQQVNTR0hrck15?= =?utf-8?B?Q2RGQlluNXBlZGJWU0l1cUpFVWdHVVlLVEM2SjFDQ21TM2Z3YkowK0JPckhz?= =?utf-8?B?WU0yeTFralNhalQ1U2djQ0IxNEpZLzJwMC9WbWRPTTJhR1pacU5Jd0ZtWGlz?= =?utf-8?B?RGJCNTJvbkg0cllleXlua1d1OTFCa1pxVFVpOGJ0UC9YcDBROWJweC9oTnJZ?= =?utf-8?B?eGJuM2lhN3NzVFBNY1dPbmJIWHFaZms0L0k2MU1kRGdJM2p2UTZBQlNvc3dP?= =?utf-8?B?dnlJenZCUG1Zbm1RWnBOWjdZclh1OFZDMFRqeGthYnl6NldRWnZ3cURLaW9K?= =?utf-8?B?MzBBREFuQ0hlOGhuenZMaTVHb3VnU2VIWTd4UkN3M21wRGV4QWQ0eFlPdjZI?= =?utf-8?B?Z0c0UGd5SXB4VWhKdDVRWEpUSllCR0ZEZTlmOEpsWlJuODNRSEYzalRDUTJz?= =?utf-8?B?TGZwL2IzTDhTa0FXcXBRc3Jud25tV3QzZzdJTVRxSnpVSVc5bGJST0Vrcno5?= =?utf-8?B?dU1DUEZBQW14ajRNTGdER1VnMW0vQmV1a2pHSUNSY1g2ejZ2OHVFTE9rVjBN?= =?utf-8?B?UFRweEYzV1l6aTBoRHl5RSs0OEVCdWEvZ1kxK3RKdWdWQU43d1BDZ3dPLzJx?= =?utf-8?B?WmZ2akF0a2Z6NWpOdGdYdU5QQmt1VEJiMGswZ2pJaUltd0c3NTBJZmFmUVk2?= =?utf-8?B?VkdESzhQZm1CUWgyeWVuS01OT2NMcWFMcnZSSkJqOW92MUk1TGFjWitqRk56?= =?utf-8?Q?euOkWdsbrDt5O0SkUvVqEEY95?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3799340c-c249-40dd-611e-08db03ba5e4a X-MS-Exchange-CrossTenant-AuthSource: CH2PR12MB4294.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Jan 2023 18:38:39.3476 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: pahnSm1O1Ydb4qN7ylP4dxdeAO8gb1mYLD92pcY8doQtueIoswfO82XHUolrFkh3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR12MB5418 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 1/30/2023 4:01 PM, Ankur Dwivedi wrote: <...> >>> diff --git a/lib/ethdev/meson.build b/lib/ethdev/meson.build index >>> 39250b5da1..f5c0865023 100644 >>> --- a/lib/ethdev/meson.build >>> +++ b/lib/ethdev/meson.build >>> @@ -24,6 +24,7 @@ headers = files( >>> 'rte_ethdev.h', >>> 'rte_ethdev_trace.h', >>> 'rte_ethdev_trace_fp.h', >>> + 'rte_ethdev_trace_fp_burst.h', >> >> Why these trace headers are public? >> Aren't trace points only used by the APIs, so I expect them to be internal, so >> applications shouldn't need them. Why they are expsed to user. > 'rte_ethdev_trace.h' can be made as internal. Not sure about 'rte_ethdev_trace_fp.h' and 'rte_ethdev_trace_fp_burst.h' as the tracepoints in fast path may be called from public inline functions. Trace calls used by inline functions needs to be public, in this case at least 'rte_ethdev_trace_fp_burst.h' needs to be public. Can you please at least move all trace points that are called by inline functions to the same file, 'rte_ethdev_trace_fp_burst.h', to reduce number of the header files to make public? Feel free to rename header if required. Meanwhile not sure about adding new header as dependency to end user. @Jerin, @Andrew, what do you think 1) to move these trace points to 'rte_ethdev_core.h' OR 2) disable trace calls in inline functions on compile time, possibly with existing 'RTE_ETHDEV_DEBUG_*' macro <...> >>> - if (port_id >= RTE_MAX_ETHPORTS) >>> + if (port_id >= RTE_MAX_ETHPORTS) { >>> + rte_eth_trace_find_next(RTE_MAX_ETHPORTS); >> >> Is there a specific reason to trace all paths, why not just keep the last one? > This can be kept as the function returns with RTE_MAX_ETHPORTS here. 'RTE_MAX_ETHPORTS' more like error path, that is returned when no more valid port left, since most of the trace doesn't record error return values, I thought this can be dropped as well unless there is an explicit need for it. <...> >>> +RTE_TRACE_POINT( >>> + rte_eth_trace_rx_hairpin_queue_setup, >>> + RTE_TRACE_POINT_ARGS(uint16_t port_id, uint16_t rx_queue_id, >>> + uint16_t nb_rx_desc, const struct rte_eth_hairpin_conf *conf, >>> + int ret), >>> + uint32_t peer_count = conf->peer_count; >>> + uint32_t tx_explicit = conf->tx_explicit; >>> + uint32_t manual_bind = conf->manual_bind; >>> + uint32_t use_locked_device_memory = conf- >>> use_locked_device_memory; >>> + uint32_t use_rte_memory = conf->use_rte_memory; >>> + uint32_t force_memory = conf->force_memory; >>> + >>> + rte_trace_point_emit_u16(port_id); >>> + rte_trace_point_emit_u16(rx_queue_id); >>> + rte_trace_point_emit_u16(nb_rx_desc); >>> + rte_trace_point_emit_ptr(conf); >>> + rte_trace_point_emit_u32(peer_count); >>> + rte_trace_point_emit_u32(tx_explicit); >>> + rte_trace_point_emit_u32(manual_bind); >>> + rte_trace_point_emit_u32(use_locked_device_memory); >>> + rte_trace_point_emit_u32(use_rte_memory); >>> + rte_trace_point_emit_u32(force_memory); >>> + rte_trace_point_emit_int(ret); >> >> Do we need temporary variables like 'peer_count', why not directly use them: > Temporary variables are needed where the actual variable is a bitfield. > For example in struct rte_eth_hairpin_conf: > struct rte_eth_hairpin_conf { > uint32_t peer_count:16; > .... > uint32_t tx_explicit:1 > .... > }; > > Otherwise there is a compilation error. > ../lib/ethdev/rte_ethdev_trace.h:253:9: note: in expansion of macro ‘rte_trace_point_emit_u16’ > 253 | rte_trace_point_emit_u16(conf->peer_count); > | ^~~~~~~~~~~~~~~~~~~~~~~~ > ../lib/eal/include/rte_trace_point.h:369:38: error: ‘sizeof’ applied to a bit-field > 369 | mem = RTE_PTR_ADD(mem, sizeof(in)); \ > Got it, that is because of bitfields. But as I look the 'rte_trace_point_emit_u16' macro, it is like: ``` #define rte_trace_point_emit_u16(in) __rte_trace_point_emit(in, uint16_t) #define __rte_trace_point_emit(in, type) \ do { \ memcpy(mem, &(in), sizeof(in)); \ mem = RTE_PTR_ADD(mem, sizeof(in)); \ } while (0) ``` Here, in '__rte_trace_point_emit' macro 'type' is not used at all, if so what is the point of passing type? If 'sizeof(type)' used, instead of 'sizeof(in)', it would be possible to use bitfields directly, what do you think? Also, as for the "struct rte_eth_hairpin_conf" sample, some of the bitfields are 1 bit length, does 'uint32_t' really needed for them? <...> >>> +RTE_TRACE_POINT_FP( >>> + rte_eth_trace_find_next, >>> + RTE_TRACE_POINT_ARGS(uint16_t port_id), >>> + rte_trace_point_emit_u16(port_id); >>> +) >>> + >> >> Why 'rte_eth_trace_find_next' added as fast path? >> Can you please add comment for all why it is added as fast path, this help to >> evaluate/review this later. > > There were many functions for which I was not sure about whether they should be slow path or fast path. I made the following assumption: > > For slow path I have chosen the function which do some setup, configure or write some configuration. For an example rte_eth_trace_tx_hairpin_queue_setup, rte_eth_trace_tx_buffer_set_err_callback, rte_eth_trace_promiscuous_enable are slow path functions. > > The functions which read data are made as fastpath functions. Also for functions for which I was not sure I made it as fastpath. > > For an example rte_ethdev_trace_owner_get, rte_eth_trace_hairpin_get_peer_port, rte_eth_trace_macaddr_get are made as fastpath. > > But there are few exceptions. Function like *_get_capability are made as slowpath. Also rte_ethdev_trace_info_get is slowpath. > > The slowpath and fastpath functions are in separate files. rte_ethdev_trace.h (slowpath) and rte_ethdev_trace_fp.h (fastpath). > > Please let me know if any function needs to be swapped. I will make that change. > Got it, I think most of the trace points in the 'rte_ethdev_trace_fp.h' are for control/helper functions like: 'rte_ethdev_trace_count_avail', 'rte_ethdev_trace_get_port_by_name', 'rte_eth_trace_promiscuous_get' ... I thought you did based on some analysis, that is why I asked to add that reasoning as code comment. I think we can generalize as: 1) Anything called by ethdev static inline functions are datapath, and must be 'RTE_TRACE_POINT_FP', like 'rte_eth_trace_call_[rt]x_callbacks', 'rte_ethdev_trace_[rt]x_burst', 2) Anything that is called in endless loop in application/sample that has potential impact although it may not really be datapath 3) Rest are regular trace points, RTE_TRACE_POINT. Item (2) requires some analysis and whenever you found one of them please comment the reasoning in the code where trace point is defined.