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 7F7C7A0543; Wed, 14 Dec 2022 13:10:46 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1C38E400D6; Wed, 14 Dec 2022 13:10:46 +0100 (CET) Received: from NAM04-DM6-obe.outbound.protection.outlook.com (mail-dm6nam04on2072.outbound.protection.outlook.com [40.107.102.72]) by mails.dpdk.org (Postfix) with ESMTP id 789264003F for ; Wed, 14 Dec 2022 13:10:44 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IxElt7ArXKPxUfSTAT68DLyXerF8J5jIBnQuBLO8p+uZ4+1fc23FVAxXyzPMupCCIyaf/qOJ6PPUXCRn0VyY0jwjQrEtuidoQUAp/KFI0X64/cYf8BD3URSlifEPzB5nVym+bxADzjD6vaZoAgGsTnWrJdUvlO0Csh42wpodVnDu2rHNmKITI5Cy15OHHKd5jIKTJ9f8Nok04fHWrWA3YfHPtTGbm2a+7p0o7YZ/hk+WvplpQTwkAIyem/ErgAJkmB8tcBdlQGUOlpevh5922rF7Wir0xsqvxTuBF1NqhmBsX4cxtSgPaiyb1xtMW3TJ2wIePJ5l80R5JexmoF9oBg== 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=JaCo/ArAcCu8wAEh4A4buJaJLdJSToxKfVszs2oYLcU=; b=DdK7i8jzZPfgzoZICcjofmbW2fn0XPzWtgj1WSBEyRqdIWLeTf1xLcV1yDTnkTi8fhOLg67dGBKEDDSEmSATxCHOx0mYEfaCn9Pwy/MeDiJ7E8GKtxMCdE8L/5N6SSoDYVjQX2Whs/svLNW6qc3ea/ICOqFF7pMP8yFLrOvnL8rhxzH7rExlzBBM4JWp234JDVui+3kHHkC13vrcH2hVMldYN++eExZaf9YarJ7vrA0FiMr7jXtk533GW/bEaCcxfEwRZUcS+rclBMCNyImJLDa2VLblmPxcO8wu9OQLUeVBRHnlw63h2pFJR51outau2WmmcVaiLeHtYIhRNUJsnA== 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=JaCo/ArAcCu8wAEh4A4buJaJLdJSToxKfVszs2oYLcU=; b=jeSck9imZzJZrc/1FUTR5Am2RPvxfm0u+Wi33vdWrnVTIotUa3qrQdtvjKyftw8I0sbcrgDxrGWzYMNQEyclx3IZOGii2uRWyJt8IJtOsgAyXOIQxXHPmUKsrlB0daX6f6m17r4woA5l4iPb9EKOruB2x7xqAmgWL3XDFBULWQU= 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 MN0PR12MB6151.namprd12.prod.outlook.com (2603:10b6:208:3c5::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5924.11; Wed, 14 Dec 2022 12:10:39 +0000 Received: from CH2PR12MB4294.namprd12.prod.outlook.com ([fe80::b482:d5bd:c7d0:3842]) by CH2PR12MB4294.namprd12.prod.outlook.com ([fe80::b482:d5bd:c7d0:3842%8]) with mapi id 15.20.5880.019; Wed, 14 Dec 2022 12:10:39 +0000 Message-ID: <7a06cfd9-f9de-2df5-d172-44aef97b7529@amd.com> Date: Wed, 14 Dec 2022 12:10:23 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1 Content-Language: en-US To: Jerin Jacob 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 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> From: Ferruh Yigit Subject: Re: [PATCH v3 1/4] ethdev: add trace points In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0276.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:195::11) To CH2PR12MB4294.namprd12.prod.outlook.com (2603:10b6:610:a9::11) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH2PR12MB4294:EE_|MN0PR12MB6151:EE_ X-MS-Office365-Filtering-Correlation-Id: d9150ab0-d84a-452b-89a5-08daddcc368e 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: MExSuLGq5tUhF2tBXuji8V705aT/jQH59FCcOOtIsQ8M+cZ+E/fqPIH0x6r+uW6l+y1CXUZW0wt0Vtbmpa0Hi9vm+dHYeQrtg9kKMBfFA1ledBlwhQwK1zvQiLBwcX81Iyna3V5SpUGswK4Sm5XJVg2zxMZ5iSX6fMcKhXdBP9FO74AqNtescCS/duAUZug+idm+JoprsdWYW/ddFqMI4C5T/kYTDHPVAJL7awDcLRLjm3d4N2FL8lEN4UNCIbyDwCMeqD6+Kl/zmKGa0v3SVYzfFiXLt7TEMa3mO3YZ4SXwLkcgRM58CZuL+s2DVtSBBMXMUj43ISpCUP2qMBSn160+da0IdP0EQX80U0qKLfSKLjH7wqEx38E5YTe4/M1kPDbceMwgcxQkOlV8PJ6b6dYZDy+g7h2uKlj4fKaiAduwSmGi1GjZoNabMHVQw1Ud2sb83Z/ZpcLWUkLfvHP22rSR+e7bf7qKHFRXS78bGk2gUZqfYLDRamt8sTIcFA0BhpDNBYMGA+hc4oteZKWi8hcmSXDQXF0l4egJ1qW9+FQfxA74i9rDOTl4bnQiHSaePBudgpQc0kwb5FcLM6O+3rdpnCgdGonFMrx1ERqVWKCYdZv14V0xxV7LIgLrH6HmQO8wy049ZM+IHA8EMsXmfOoPHGOgFsDAL3BVZzQAfrdEplQcTRFuW+eS9RV7aZXZ5j09KY3YAFNtBQyd86X5UAkm1odaMVKyZAK3VJ4wRdWgM6ruavI72zqr9jhdH8sx 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:(13230022)(4636009)(136003)(39860400002)(366004)(396003)(346002)(376002)(451199015)(2906002)(2616005)(38100700002)(31686004)(478600001)(6486002)(966005)(6506007)(6666004)(53546011)(4326008)(8676002)(66946007)(66556008)(66476007)(6916009)(6512007)(186003)(26005)(5660300002)(8936002)(41300700001)(83380400001)(44832011)(7336002)(7366002)(7406005)(7416002)(36756003)(316002)(31696002)(86362001)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NjZFSVI0UUVwVGhNNkI3ZVVIbGdNVHJoVWkwZ2U5c0dLbHNvTUx3OStTekdB?= =?utf-8?B?RVNNRnJGUmlrWXgraFFnQkMwNm44dEdEcGFRSFg3RDVoaHN2SmdoN1U3dVh4?= =?utf-8?B?MGllT04wazRSdTVsNFZzbm1IU3UxSy94QlRKOHVWUU1kSFYyS1prY2tudGJy?= =?utf-8?B?bWNvTmxSQnBRZ3BaSUFCbUUrL0xjQk94a3doTUF0NDhYb3E1bTJPNmtmaytr?= =?utf-8?B?Y2tybjVwc3d1eG83MzZEby8rRGRCNVdSUGc1cUJSWU1pMHF6N0ZTcVh2dFJS?= =?utf-8?B?cS94WERCMXhjVE5Cck1yRXIrZEwvOTZ5S2dEeU0vUjVrS0IzckVpMGtmUTdI?= =?utf-8?B?MmdQYUpUTlczeU44ZHBYVGU3UklpWTFkSWpiZ01tVjFoeHIyM1d3M1NZaTFZ?= =?utf-8?B?b2huWU5UeXJTMk1iZmlMQjRvVjQrTDN6MnhtR0FoVXZQVTdYRENITENHL2dG?= =?utf-8?B?L2d0SWhidkgvbmlJelFLSDg5QnVmSkFzOE1hMXFscFRSbDdCQ2lhWTZ5MzRp?= =?utf-8?B?aGlsVndqTDltbjlDekY1TFJ3azZHclB2bUVqeVpiQTQ2cXFmWUZ3SWJJeVhH?= =?utf-8?B?VDdQZjRNMVFmNzR1bTZYdUNjKzFHYlZRTVlvODExaVM0cDJxdkMxaFdPaklP?= =?utf-8?B?WjZXME5wNzYxcTRpdHltK0lEV1hveUtLeUhWd0N5d0tUK200MVJtTWZuaDFj?= =?utf-8?B?bGFBanh0SnhHL0pnUWlkT080akdmYkUrTFl2SjNWSCtVbjRYb1pFQ2VqdWgw?= =?utf-8?B?RHNQTVFwQ1R2K3M1L1pGWEp6QUhuaEpBS0lsbWwvOE45cW16QThoanFPb21n?= =?utf-8?B?L003ZFpTMkU5N0YzaVc3ZERnU0NJWTVsM2ZNUGdOMWd2V0ErVFNXRlIrME1F?= =?utf-8?B?VlZna1dTd2tZZFY0NVJlaGhGTjRkYjh2andwOXJwZDhhcXg5dC8xRFBJT0Rn?= =?utf-8?B?blVTQ0UrZlB1Rzh3aURoNnNOQlFETkQ5eDY4bTRNeDdCOVArZFIwbFhBQWt2?= =?utf-8?B?Z0lxUzd2OXNtQm1rdERBWWhQSlNkSkxoSVFkRzFpVGF0cjFGVjdraGJHckM5?= =?utf-8?B?VExqbm5mMWwzcHUwbU1LUURVNkNSZkprK0dTY0pGZjllenZ6ZnNTbXZMWXAz?= =?utf-8?B?VGpvMEpKY29wcC9mQ2pQZDlpQWU2alIwN1cvODRMMm5lclQ5TzdUZDVRR05x?= =?utf-8?B?WDdlWUlmc2llV0wyTGZTc0FnNXJoUmlqT2pocGhsVGhuUkdxVzlOUnVQSDJF?= =?utf-8?B?TzBkbnNxL3BUaFBETmRUNERBTDY3dS9kblZBeGhPV25rclluK1c1L0lLK3dV?= =?utf-8?B?YzBCL2VKbkFXM0VIQVpFcnROU05US0lvSVVnd3N4Tm1vb2pUZVRtZmlGZXhh?= =?utf-8?B?dElkcHgrNVNlNFV6aEQ4a29aVGRCdE10N0tYT1M1dlNpU3E5ZzBmd1YxVXJa?= =?utf-8?B?N2VnNUpNeG5kSWNVMjl6b3ZYQnBvanVNTjRTdnpIdllsakpYa01GTDRteVAv?= =?utf-8?B?S0ZnU3VSMEx0NklBekVGY1MwY1NGdzhVcFNMSnIzbDExbzZ0aEVZUTZYSmRS?= =?utf-8?B?ZWJ4WGd5bkN6YjVlajFQRDArcERmb1dma1kraUYrMmxjOTNUaHM1M3Z4Wno3?= =?utf-8?B?NHVHSExMbE1BTGhWeXBMMENrSkxyd0laVk95OWhIOC9XOTJFVHk3M2RUbWNy?= =?utf-8?B?YW9HZ0VvLzRGcE5MZ3FMYmlsdkpoTFlMSDRvMDd3Z3lLTk9NbWhVVXpWZUc1?= =?utf-8?B?STU3QlFEZjJxOUJIaXd0cHFac1dka2dhZEY4eHFCcGIraWM4d0R4RkxHV2ZB?= =?utf-8?B?Wlhsdm85ME5WUk0rcndadUYrbXJyaXVjZVVDbTMrZW9nc1pCU2hoQU5LMFlk?= =?utf-8?B?TUlSM0VjWkFFemkrem1lVmRkSWtvK1p6anF4SzF3RnQ1ZVVtd2MvRlJ1dTRB?= =?utf-8?B?SER3NHNEYmlRV3EyZ3BLTnozRk0yNG90ZkNwVWVDZUd2V25DNzBpMFd0cnBt?= =?utf-8?B?Q0tqNDRyZWhibURBd0NLWk1iUmRBN1JBRnlBZGYyN05pL0JJODUzWGl3UU13?= =?utf-8?B?WmxrZHgzTkw5a2puUG5ZY0ZJNnVPSncrVjZKRDFFb3ludWFHTGlwdWFUbVJl?= =?utf-8?Q?yB+R8OmmX2tWKzLoCCufQu1uy?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: d9150ab0-d84a-452b-89a5-08daddcc368e X-MS-Exchange-CrossTenant-AuthSource: CH2PR12MB4294.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Dec 2022 12:10:38.9567 (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: jwurpw03egNtALQ/IlYrEmDuHBW6GHcBDxO0cr3RqcQYsmt8e6BG3iNCuN1ATPOI X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB6151 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 12/14/2022 10:40 AM, Jerin Jacob wrote: > 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. > I am aware payload is not fixed technically, but my concern is from user perspective. Lets get 'rte_ethdev_trace_info_get' as example, right now it records 'dev_info->if_index', if we remove it in next release, will it impact the users? Or if we start recording 'dev_info->max_rx_queues' in another release, it will change order of fields in output, will it impact the user? If changing payload doesn't impact user, we can accept changes easier since we can tweak them as needed without user impact. But if the target is to stick to the payload layout as much as possible, we should be more careful before we finalize it. I am trying to understand how strict to be in accepting trace point patches. >> >> >> 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. > Most of the trace point records only on success path, and not record at all when there is a failure in the API, that is why I think trace can't completely replace the logging. But trace may be useful to analysis a functioning system for performance issues, overall system analysis, or unexpected behaviors. In that case I am not sure how much detail to record in trace. Because recording more fields comes with additional runtime cost and memory cost, right? Also useless records can be noise in the trace output. OK to record return values but I don't know if it may be misleading because in some of the failure path trace functions not called at all, so recorded failures will be subset of the overall failures. BTW, I don't think that we should record all failures in trace log, that will create to much noise in the code. >> 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. Got it, there is '__RTE_TRACE_FIELD_ENABLE_MASK' check, and this is the only cost when trace is disabled. > For RTE_TRACE_POINT_FP it is zero if it is not enabled at compile time. > ack > >> 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. > OK, default 1M buffer doesn't look something to worry about. >> >> >> 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); > got it, do we really need direct access to trace point (option 1), I would be OK to remove that option to not expose all these trace point objects. > >> >> >> >> 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. > Thanks. > >> >> >> 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. >>