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 F065942D71; Tue, 27 Jun 2023 13:36:41 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 873A64282D; Tue, 27 Jun 2023 13:36:41 +0200 (CEST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by mails.dpdk.org (Postfix) with ESMTP id 252FB40F18 for ; Tue, 27 Jun 2023 13:36:40 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id A36385C0180; Tue, 27 Jun 2023 07:36:39 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Tue, 27 Jun 2023 07:36:39 -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= 1687865799; x=1687952199; bh=N6s4vwTJ0pTuqIpzJouyz6EzvuGWreHcQ1D w0FbALko=; b=JGPcsv8Ri3wuWDaCyV9NcT+fLvqQ/mTKuUAW0/cgN/EZPEcruiO J5hpsDFmHZgQuUgojUfDLbPCoGdKjV4PMBXa5hk37DXsmaLKl7W1sGsws+ONKSbf UgTy09yY4YTn9RdyerV4gUDtkoUy9D4mchfR1CyajksBwoXlvhU3ZxLMQqhSQGF0 7VasXBAwv3EodmdFnA984+/4m+KonZBncB4vfncK4LCnzLn2Sc64+mxW+aVi+B2P DXYOQO9tk2bTZ3ctPf8w8tItBFMEoSpEVLuBk/yVTK5rPFxO7SYNzpvLcvVjEnQY YWW+j3p3HdPT6maDv/vRODI78/ssMwGvk3w== 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= 1687865799; x=1687952199; bh=N6s4vwTJ0pTuqIpzJouyz6EzvuGWreHcQ1D w0FbALko=; b=eDTqJmC0ND8CjnCEyDotg1B7hnIqhSy0lNvCXwD14p2xORfuoZY HcunZMPAxs5b/vnUtVNNeziTEa2QF92crclCdlkiWfxR21XHCTEyi9pXl6rwwOl6 lHDsvBux6RXOeVqbFk70+btH0byt+TebshIOq4zkO+kbIgvozvE73ZBNgYXklQu/ ICqi3UeKB1fyJt0h0VD0VSF8JBXQ5GWbnQjsbyEYBH+8i7W0NLigHZKVNFGmVsJB RgxBkXrgS8bd/vfS/1E7Cr317lzkuMZoPE8bODZBR+1cQjQ8kvbBMAFaHmTmEmvc uc/kyb7hKjcQverHkFxfMnU+khWxKvqbAMg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrtddtucetufdoteggodetrfdotffvucfrrh hofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgenuceurghi lhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurh ephffvvefufffkjghfggfgtgesthhqredttddtjeenucfhrhhomhepvfhhohhmrghsucfo ohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtffrrg htthgvrhhnpeegtddtleejjeegffekkeektdejvedtheevtdekiedvueeuvdeiuddvleev jeeujeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 27 Jun 2023 07:36:38 -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 13:36:36 +0200 Message-ID: <22210461.hxa6pUQ8Du@thomas> In-Reply-To: References: <20230420100803.494-1-viacheslavo@nvidia.com> <7744170.gsGJI6kyIV@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 11:43, Slava Ovsiienko: > From: Thomas Monjalon > > 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 add= ress. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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 > > filder. > > > > > > > > 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 > > > > > available tracing > > > > caps in single view. > > > > > > > > Better to not export them. > > > > > > > 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 on= e place. > > I would prefer not to spread trace point definitions over the multiple = source > > files. > >=20 > > You don't need to export trace symbols for using them. > > It has been discussed already with Jerin that we prefer not exporting t= race > > symbols if it can be avoided. Here it can be avoided. >=20 > Without exporting symbols defined in common/mlx5 we have link error for n= et/mlx5. > So, do you insist on having dedicated mlx5_trace.c per /net/mlx5, common/= mlx5, etc? Yes please it looks better to have tracepoints close to their respective fu= nctions.