From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id A19ADA04AE; Mon, 4 May 2020 23:31:15 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 287E51D562; Mon, 4 May 2020 23:31:15 +0200 (CEST) Received: from wnew3-smtp.messagingengine.com (wnew3-smtp.messagingengine.com [64.147.123.17]) by dpdk.org (Postfix) with ESMTP id 4566C1D55B for ; Mon, 4 May 2020 23:31:14 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailnew.west.internal (Postfix) with ESMTP id 761875BB; Mon, 4 May 2020 17:31:12 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Mon, 04 May 2020 17:31:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm1; bh= lkWBjJvGbBGOZq9VFwPbaUx30dNtan2AW8FXh1BX05g=; b=a09+m5kaewEEIem+ YsobB2p3OlOkI92e/S0YVLqjOsGDpDAJ/5LTRfjlX9Qj/WQ1LgihN07jd2zm3Aa2 Echvuw+NYpF3ghZghuYl0Gz3f3cCT+T9WFBwQaO7biLGU9Du7MIQ/cDZfdLyWD/M KpE8SJyp9NPXePfh0KNkgj31ykXs7a7HddTxkqfH5yQmWftrhNvU3u8MbehtY96/ 0edjqWzXlpjua/kD7fCGxjf+hPl4MyAgNn9ri4zEfCKTZH9ZnoynxInMiJCw650q 2eRl3YK18iGhd75onaqf3cN/y59hfRpzgVp5pWJsVZsvInUYq0WPPmyVuzUprILB hUNVGQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=lkWBjJvGbBGOZq9VFwPbaUx30dNtan2AW8FXh1BX0 5g=; b=KRD631tD35513P/0yA3bNAjwP0tBYutwnt4FrUjWuDBYNrz7FS7p5MONe 9vTg1EVb2A1SU5ek1Jq6kzirXus6pLPvNHc141PVNqCvy6uvPLGuKjKkLx2u8RRm Uw8bK3Fo1/EZ8xwhAA33g5mGDBaXvIyRm/fxBbIzVRNqFXDKP0QhFSIA4aOGYn81 hfU4xIdDlAEJAAC60FxZqtaa4DbI5M1pWRDTA0mUslJcPrphSsFVsGilm72CWHvh +JvKJSfLMd9xjviUffbb//c5/kCRvSwHUBRt+qm2eRIjW5Idqxroih+QsnGnamXD PJrQ7a3x5bh04t2VtAKq7apM4JhCg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrjeeggdduheefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvght X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id A3F71306601B; Mon, 4 May 2020 17:31:09 -0400 (EDT) From: Thomas Monjalon To: Jerin Jacob Cc: David Marchand , dpdk-dev , Jerin Jacob , Sunil Kumar Kori , John McNamara , Marko Kovacevic , Declan Doherty , Ferruh Yigit , Andrew Rybchenko , Olivier Matz Date: Mon, 04 May 2020 23:31:07 +0200 Message-ID: <7788528.NyiUUSuA9g@thomas> In-Reply-To: References: <20200503203135.6493-1-david.marchand@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH 2/8] trace: simplify trace point registration X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 04/05/2020 19:54, Jerin Jacob: > On Mon, May 4, 2020 at 11:10 PM David Marchand > > On Mon, May 4, 2020 at 7:19 PM Jerin Jacob wrote: > > > On Mon, May 4, 2020 at 10:38 PM David Marchand > > > > On Mon, May 4, 2020 at 4:39 PM Jerin Jacob wrote: > > > > > On Mon, May 4, 2020 at 7:34 PM David Marchand wrote: > > > > > > On Mon, May 4, 2020 at 4:47 AM Jerin Jacob wrote: > > > > > > > On Mon, May 4, 2020 at 2:02 AM David Marchand wrote: > > > > > > > > > > > > > > > > RTE_TRACE_POINT_DEFINE and RTE_TRACE_POINT_REGISTER must come in pairs. > > > > > > > > Merge them and let RTE_TRACE_POINT_REGISTER handle the constructor part. > > > > > > > > > > > > > > > > > > > > > Initially, I thought of doing the same. But, later I realized that > > > > > > > this largely grows the number of constructors been called. > > > > > > > I had concerns about the boot time of the application and/or loading > > > > > > > the shared library, that the reason why spitting > > > > > > > as two so that constructor registers a burst of traces like rte_log. > > > > > > > > > > > > I am a bit skeptical. > > > > > > In terms of cycles and looking at __rte_trace_point_register() (which > > > > > > calls malloc), the cost of calling multiple constructors instead of > > > > > > one is negligible. > > > > > > > > > > We will have a lot tracepoints latter, each one translates to the > > > > > constructor may not be a good > > > > > improvement. The scope is limited only to register function so IMO it > > > > > is okay to have split > > > > > just like rte_log. I don't see any reason why it has to be a different > > > > > than rte_log. > > > > > > > > What is similar to rte_log? > > > > There is neither RTE_LOG_REGISTER macro, nor two-steps declaration of > > > > dynamic logtypes. > > > > > > > > > Here is an example of rte_log registration. Which has _one_ > > > constructor and N number of > > > rte_log_register() underneath. > > > > rte_log is one thing, rte_trace is already different. > > > > There is _no macro_ in rte_log for registration. > > The reason being in that a rte_log logtype is a simple integer without > > any special declaration requiring a macro. > > I just wrapped in macro for convincing, but it has the same semantics. > global variable and API/macro to register. > > > > > > For tracepoints, we have a special two steps thing: the tracepoint > > handle must be derived from the tracepoint name. > > Then this handle must be registered. > > What I proposed is to make life easier for developers that want to add > > tracepoints and I suppose you noticed patch 1 of this series. > > To reduce the constructors. I don't want trace libraries to add lot of > constructors. > I don't think it simplifies a lot as the scope of only for registration. > > > > > > > > > > > One of the thought process is, we probably remove the constructor > > > > > scheme to all other with DPDK > > > > > and replace it with a more register scheme. In such a case, we can > > > > > skip calling the constructor all tother > > > > > when trace is disabled. > > > > > > > > Sorry, but I have a hard time understanding your point. > > > > Are you talking about application boot time? > > > > > > Yes. The optimization of application boottime time in case of static > > > binary and/or shared library(.so) load time. > > > > As Thomas mentioned, do you have numbers? > > No. But I know, it is obvious that current code is better in terms of > boot time than the proposed one. > I would like to not add a lot of constructor for trace as the FIRST > module in DPDK. No, it is not obvious. The version from David looks simpler to use and to understand. Without any number, I consider usability (and maintenance) wins.