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 A9A2C42D70; Tue, 27 Jun 2023 11:33:41 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9819B427E9; Tue, 27 Jun 2023 11:33:41 +0200 (CEST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mails.dpdk.org (Postfix) with ESMTP id 9899B427E9 for ; Tue, 27 Jun 2023 11:33:39 +0200 (CEST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 4B17B5C01E0; Tue, 27 Jun 2023 05:33:38 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Tue, 27 Jun 2023 05:33:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1687858418; x=1687944818; bh=9CrIoNG5skgcSxthMXxJ/WKzr79jcasxvgV yfyagvIU=; b=gwX9uDhpQu6Ycc7RJmzEtPHoBsyBuVe1iYQ+rMdiq0pqa9+tq49 ESPyYFqGTUAqZem6u9pdZjx9URjZ0aR5PJMHc3bQ0VitIFr2emee4dvMkWtwCiNH Rbm2tEoGbSs7GECqz8ytg1awXptY2XPKWMgguYecoZIU99KnzgpJAAJR0gIFwcZt SOhBVcwMLK3JBK0biiFa7Nw6d07gTlbN4Hy2UrFgCpPoDWphOUWO9Q+wn8RDuMzF Ad3WuI6KGUtPnzp/ZhOMhPcUf0Z3iZUWRBXOtF/oNWQuiNxoHrTW20kWwWujIq81 egXkqS4gopYr/R3a5w4npMc4CS0Ur6axP9Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1687858418; x=1687944818; bh=9CrIoNG5skgcSxthMXxJ/WKzr79jcasxvgV yfyagvIU=; b=M+jt0QOT2KDhJLsRH2Gs4pTk5WPs8IsqHOYPtpNc8jFsu1tu/84 DHfz8RX9l0pl+mN3sx8kl/KcBI34uvo3cOqRhuIjxp9JfgCSU0GQttfZUaFep+LR qsqt27/yF7Y7BcexLzHKR1KHvJSComg/09+Dvd17B5Wz6O/gRv7CQUzraSQxZQLp FbvLGBe0Ka2sukVSwlMAPUs0wQU65nojis17zdaz+EJvU5a5U6j5QejjMNed7GFc LD8s3O2sIe35etBvT1dRv67TiekIaMYodQ6K/wCJcYpBep5M2mEnVNZ2BIsz7Hev DVCfnIE4HBn3fkzNU2ovV6fhHapKZZBHROA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrgeehhedgudeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthhqredttddtjeenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpeegtddtleejjeegffekkeektdejvedtheevtdekiedvueeuvdei uddvleevjeeujeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 27 Jun 2023 05:33:37 -0400 (EDT) From: Thomas Monjalon To: Slava Ovsiienko Cc: "dev@dpdk.org" , Jerin Jacob , Raslan Darawsheh , david.marchand@redhat.com, Maayan Kashani Subject: Re: [RFC 2/5] common/mlx5: introduce tracepoints for mlx5 drivers Date: Tue, 27 Jun 2023 11:33:35 +0200 Message-ID: <7744170.gsGJI6kyIV@thomas> In-Reply-To: References: <20230420100803.494-1-viacheslavo@nvidia.com> <2800790.AiC22s8V5E@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 27/06/2023 10:19, Slava Ovsiienko: > From: Thomas Monjalon > > 27/06/2023 08:15, Slava Ovsiienko: > > > From: Thomas Monjalon > > > > 13/06/2023 18:01, Jerin Jacob: > > > > > On Tue, Jun 13, 2023 at 9:29=E2=80=AFPM Slava Ovsiienko > > > > > > > > > wrote: > > > > > > From: Jerin Jacob > > > > > > > On Tue, Jun 13, 2023 at 9:20=E2=80=AFPM Slava Ovsiienko > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > <..snip..> > > > > > > > > > > > > > > > > > > > > mlx5_os_interrupt_handler_create; # > > WINDOWS_NO_EXPORT > > > > > > > > > > mlx5_os_interrupt_handler_destroy; # > > > > > > > > > > WINDOWS_NO_EXPORT > > > > > > > > > > + > > > > > > > > > > + __rte_pmd_mlx5_trace_tx_entry; > > > > > > > > > > + __rte_pmd_mlx5_trace_tx_exit; > > > > > > > > > > + __rte_pmd_mlx5_trace_tx_wqe; > > > > > > > > > > + __rte_pmd_mlx5_trace_tx_wait; > > > > > > > > > > + __rte_pmd_mlx5_trace_tx_push; > > > > > > > > > > + __rte_pmd_mlx5_trace_tx_complete; > > > > > > > > > > > > > > > > > > No need to expose these symbols. It is getting removed > > > > > > > > > from rest of > > > > DPDK. > > > > > > > > > Application can do rte_trace_lookup() to get this address. > > > > > > > > > > > > > > > > > > > > > > > > > > It is not for application, it is for PMD itself, w/o > > > > > > > > exposing the symbols build > > > > > > > failed. > > > > > > > > > > > > > > PMD is implementing this trace endpoints, not consuming this > > > > > > > trace > > > > point. > > > > > > > Right? If so, Why to expose these symbols? > > > > > > > > > > > > As far as understand: > > > > > > The tracepoint routines are defined in dedicated > > > > > > common/mlx5_trace.c > > > > file. > > > > > > The tx_burst in mlx5 is implemented as template in header file, > > > > > > and this template is used in multiple .c files under net/mlx5 f= ilder. > > > > > > So, common/mlx5 should expose its symbols to net/mlx5 to allow > > > > > > successful linkage. > > > > > > > > > > OK. I missed the fact the these are in common code and net driver > > > > > is depened on that. > > > > > So changes makes sense. > > > > > > > > It does not make sense to me. > > > > These are tracepoints for the ethdev driver. > > > > Why declaring them in the common library? > > > > > > Just to gather all mlx5 traces in the single file, to see all availab= le tracing > > caps in single view. > >=20 > > Better to not export them. > >=20 > It is not about export, we have analyzing script over the trace data, and= it would be better to see all the tracing > routines gathered in one place. I would prefer not to spread trace point = definitions over the multiple source files. You don't need to export trace symbols for using them. It has been discussed already with Jerin that we prefer not exporting trace symbols if it can be avoided. Here it can be avoided.