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 C0234A04A7; Tue, 5 May 2020 19:20:10 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B69151D68E; Tue, 5 May 2020 19:20:09 +0200 (CEST) Received: from new3-smtp.messagingengine.com (new3-smtp.messagingengine.com [66.111.4.229]) by dpdk.org (Postfix) with ESMTP id 655981D68D for ; Tue, 5 May 2020 19:20:08 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailnew.nyi.internal (Postfix) with ESMTP id A7EE75802F4; Tue, 5 May 2020 13:20:07 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Tue, 05 May 2020 13:20:07 -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= hIe/mm4r2Oa1p9MxuZKItRZQ93dvdSr/UY1CulD/Z+w=; b=ktvHr8h0Oc4MyimL qA0e9xU2841BZYL9isLqtaKMn1uhy5cHuS4VHtOTxcOMLDN1RXAYjMa2jJeDlcya iR09psVD0AywvjDSRXEBMflRku8YVgBCdJ2fEVpQz1/tzZZIHc1UoAq7dr6izWAc td7g56F7lLAUCFTmriLDKDVzrh0OIhoNFKMS/KZ6OWcFhATQzpqN/s6VzkJz7C0V +FB6PUZ/ciXkNOfrtvx899gVn7qGM0EJgqNg1zuG9Tmfk66CkDg5j99gGt/3QovU xcoeUJbsRlXLvqKPxK5LFve/B4HwpTyI2FPMgP2mZTvhezlyc1LBPAdoCLuOtOtd fwnjaA== 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=hIe/mm4r2Oa1p9MxuZKItRZQ93dvdSr/UY1CulD/Z +w=; b=tgBm05fmF0hwMd9peG7DokGNPQcpVbu22YtxzXFmi1Qih0SZCUbx3ov1Y ZzoxD7B1afgxFjdnti23J67iiScY4lsr5tN8guZZG8/WuGOjgT2Py/3nR0mK1Lab FgFaPfVSLBduzIu+Ac1u6Uuo7kCfF4KUx0+kM9CyHDQwRioODiAVHfYXhiTYqq2/ yt8MXP5edNq00xPi4RIT/CHoSA0rcPfzb39vDvYjmGGB0We4WW4QxVOtlhP1GBbn mG1Q49mcoK7y46JIQpG1T0eEsr0qvfuu1LDisGd7TbXKRBXnEIPb6+fOcbOAedSJ qBbKd3xDdy7stN8lpTE3Z5lyLc4qA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrjeeigddutdejucetufdoteggodetrfdotf 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 672B63065FE4; Tue, 5 May 2020 13:20:05 -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: Tue, 05 May 2020 19:20:04 +0200 Message-ID: <1870194.PIDvDuAF1L@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" 05/05/2020 19:09, Jerin Jacob: > On Tue, May 5, 2020 at 10:38 PM Jerin Jacob wrote: > > On Tue, May 5, 2020 at 10:28 PM Thomas Monjalon wrote: > > > 05/05/2020 18:46, Jerin Jacob: > > > > On Tue, May 5, 2020 at 9:58 PM David Marchand wrote: > > > > > On Tue, May 5, 2020 at 5:25 PM Jerin Jacob wrote: > > > > > > On Tue, May 5, 2020 at 5:56 PM Jerin Jacob wrote: > > > > > > > On Tue, May 5, 2020 at 5:06 PM David Marchand wrote: > > > > > > > > On Tue, May 5, 2020 at 12:13 PM Jerin Jacob wrote: > > > > > > > > > > > Please share the data. > > > > > > > > > > > > > > > > > > > > Measured time between first rte_trace_point_register and last one with > > > > > > > > > > a simple patch: > > > > > > > > > > > > > > > > > > I will try to reproduce this, once we finalize on the above synergy > > > > > > > > > with rte_log. > > > > > > > > > > > > > > > > I took the time to provide measure but you won't take the time to look at this. > > > > > > > > > > > > > > I will spend time on this. I would like to test with a shared library > > > > > > > also and more tracepoints. > > > > > > > I was looking for an agreement on using the constructor for rte_log as > > > > > > > well(Just make sure the direction is correct). > > > > > > > > > > > > > > Next steps: > > > > > > > - I will analyze the come back on this overhead on this thread. > > > > > > > > > > > > I have added 500 constructors for testing the overhead with the shared > > > > > > build and static build. > > > > > > My results inline with your results aka negligible overhead. > > > > > > > > > > > > David, > > > > > > Do you have plan for similar RTE_LOG_REGISTER as mentioned earlier? > > > > > > I would like to have rte_log and rte_trace semantics similar to registration. > > > > > > If you are not planning to submit the rte_log patch then I can send > > > > > > one for RC2 cleanup. > > > > > > > > > > It won't be possible for me. > > > > > > > > I can do that if we agree on the specifics. > > > > > > > > > > > > > > > > > > Relying on the current rte_log_register is buggy with shared builds, > > > > > as drivers are calling rte_log_register, then impose a default level > > > > > without caring about what the user passed. > > > > > So if we introduce a RTE_LOG_REGISTER macro now at least this must be fixed too. > > > > > > > > > > What I wanted to do: > > > > > - merge rte_log_register_and_pick_level() (experimental) into > > > > > rte_log_register, doing this should be fine from my pov, > > > > > - reconsider the relevance of a fallback logtype when registration fails, > > > > > - shoot the default level per component thing: levels meaning is > > > > > fragmented across the drivers/libraries because of it, but this will > > > > > open a big box of stuff, > > > > > > > > This you are referring to internal implementation improvement. Right? > > > > I was referring to remove the current clutter[1] > > > > If we stick the following as the interface. Then you can do other > > > > improvements when you get time > > > > that won't change the consumer code or interference part. > > > > > > > > #define RTE_LOG_REGISTER(type, name, level) > > > > > > This discussion is interesting but out of scope for rte_trace. > > > I am also interested in rte_log registration cleanup, > > > but I know it is too much work for the last weeks of 20.05. > > > > > > As Olivier said about rte_trace, > > > "Since it's a new API, it makes sense to make > > > it as good as possible for the first version." > > > > > > So please let's conclude on this rte_trace patch for 20.05-rc2, > > > and commit to fix rte_log registration in the first days of 20.08. > > > > Why not hold the trace registration patch 2/8 and apply rest for RC2. > > Once we have synergy between the registration scheme between rte_log > > and rte_trace > > apply the patch for RC2. > > I meant, Once we have synergy between the registration scheme between > rte_log and rte_trace > apply the patch for _20.08_? Because of what I wrote above: As Olivier said about rte_trace, "Since it's a new API, it makes sense to make it as good as possible for the first version." The intent is to show an API as simple as possible in order to have a maximum of developers integrating it, and getting more interesting feedbacks. In other words, we want to make your work shine for prime time.