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 6E8C8A0547; Wed, 12 Oct 2022 11:49:58 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 13F3742D6E; Wed, 12 Oct 2022 11:49:58 +0200 (CEST) Received: from mail-qv1-f43.google.com (mail-qv1-f43.google.com [209.85.219.43]) by mails.dpdk.org (Postfix) with ESMTP id A7AB542B6D for ; Wed, 12 Oct 2022 11:49:56 +0200 (CEST) Received: by mail-qv1-f43.google.com with SMTP id mx8so10565739qvb.8 for ; Wed, 12 Oct 2022 02:49:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=J06nToz8ZEcU86KOEsFuAiKUh/ZE28bLHd+wqpMHWjY=; b=cEfaB3TBfMtjKAblT3hI6fDXNAsoag+vyt45s/vJcUkq0SYD1w8FdfJLt8eJGwaWi9 OAoYH69NggYfw1KKmitQ9gysIu7QXyAec7e5EMfg10R0cSr9lDbBy0Nj0+bpIE51YJ2d ozdbDcS2eZv1GhXrVZbw/yLfgX2xyzz5NvDtqNMJgUButdV1ia0TWjjcg8q5KbGpQWc8 +UTtmIej+zAwoT/6FOkvkrxps4E0Iaa2Ny3QESPg0bnWcU65iHEKyI7ypyyaJNQ3A1v0 1Ps32z2ywpOK6IeClTaYa2MT2jY6PVNAaI8aqqjAF2eu499TYvBduINWoln7Wx8ccYUu +7eA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=J06nToz8ZEcU86KOEsFuAiKUh/ZE28bLHd+wqpMHWjY=; b=Vwvdil5/aWAUcNsn5kuKPijigcqtmiKJWIYqw4Fy/35g40ER6SQydE6gG7h/GwQxKW JchCddBWwcDE2YIAwkKDXVJ+g2ykTBVqYweeWcq/OrnhaKp97qFSemLu6H1EKEgqi5ky yp2GD8FX2p/e4R/RfPc0PniLKzMHNNsOKg0CsgDIrBAIobBtuwwiHjMMiepLJde4SaHh 4zNCh6vhrlm/qaUR6HGqjDJPU6jP6Iac6f1X3C46CGFQN2AKjiGKyowwfXfSAQxhg34B n/ElvsV3xZL/cgKKqQQVuxeOIcNRqZWPgPy8K/HCu17vDqHoq17mDjKCJVBjf2rUOFI9 sbTA== X-Gm-Message-State: ACrzQf2OE6rKYE4ErwxW5XzaUCEurJBPfSdkdunYzeGs3r40WFdmOzZI LWAybVMBUdJKNnH1/YMIs1SvLAETktp3X4Snx+Y= X-Google-Smtp-Source: AMsMyM7UTBuR0gauKZ60CxY4vyUwu/tWD1Yn5POcynwVbM+v04aXN2BFTu2dlK+FBG5fNnhSBraW/dYLyGNwDBi6h/c= X-Received: by 2002:a0c:b256:0:b0:4b1:9f77:91da with SMTP id k22-20020a0cb256000000b004b19f7791damr22488621qve.84.1665568196078; Wed, 12 Oct 2022 02:49:56 -0700 (PDT) MIME-Version: 1.0 References: <20220804134430.6192-1-adwivedi@marvell.com> <20220929102936.5490-1-adwivedi@marvell.com> <20220929102936.5490-2-adwivedi@marvell.com> <6bee8943-408e-a930-f053-541af8bed6d0@oktetlabs.ru> <7369fc89-6588-8898-ed2d-91329248e2b6@oktetlabs.ru> In-Reply-To: From: Jerin Jacob Date: Wed, 12 Oct 2022 15:19:30 +0530 Message-ID: Subject: Re: [EXT] Re: [PATCH v2 1/4] ethdev: add trace points To: David Marchand Cc: Andrew Rybchenko , Jerin Jacob Kollanukkaran , Ankur Dwivedi , "dev@dpdk.org" , Thomas Monjalon , Ferruh Yigit , Ray Kinsella Content-Type: text/plain; charset="UTF-8" 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 Thu, Oct 6, 2022 at 1:27 PM David Marchand wrote: > > On Thu, Oct 6, 2022 at 9:50 AM Andrew Rybchenko > wrote: > > >>>>> diff --git a/lib/ethdev/version.map b/lib/ethdev/version.map index > > >>>>> 3def7bfd24..e3d603cc9a 100644 > > >>>>> --- a/lib/ethdev/version.map > > >>>>> +++ b/lib/ethdev/version.map > > >>>>> @@ -288,6 +288,150 @@ EXPERIMENTAL { > > >>>>> > > >>>>> # added in 22.11 > > >>>>> rte_flow_async_action_handle_query; > > >>>>> + __rte_eth_trace_add_first_rx_callback; > > >>>> > > >>>> Why is it in EXPERIMENTAL section, but not INTERNAL? > > >>> [Ankur] Because the functions for which trace is added are not internal > > >> functions. > > >> > > >> Sorry, but I don't understand. I agree that tracing of public inline functions > > >> must be part of ABI, but why everything else should be a part of ABI? > > > [Ankur] I see that there are some already existing trace functions added in EXPERIMENTAL in version.map like __rte_ethdev_trace_configure, __rte_ethdev_trace_rxq_setup. So not sure will it be internal or experimental. > > > > > > But you are right the trace function will not be called as a public api. Should I make the newly added trace as internal then? > > > > @David, do I understand correctly that trace points in > > EXPERIMENTAL is a mistake in majority of cases? > > The trace point global variables (__rte_trace_foo) are only exposed > for inline helpers that might call their associated trace point helper > (rte_trace_foo()). > An application is not supposed to directly manipulate them. > Any tp manipulation should be through the rte_trace_point_* API. > > Jerin, do you see any other uses for them? No. Expect the following ones, which can be used by application directly. __rte_eal_trace_generic_float; __rte_eal_trace_generic_func; __rte_eal_trace_generic_i16; __rte_eal_trace_generic_i32; __rte_eal_trace_generic_i64; __rte_eal_trace_generic_i8; __rte_eal_trace_generic_int; __rte_eal_trace_generic_long; __rte_eal_trace_generic_ptr; __rte_eal_trace_generic_str; __rte_eal_trace_generic_u16; __rte_eal_trace_generic_u32; __rte_eal_trace_generic_u64; __rte_eal_trace_generic_u8; > > If not, I agree we can mark all those INTERNAL. > I can send a cleanup post rc1. Thanks > > > -- > David Marchand >