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 5CFA2A04B8; Tue, 5 May 2020 18:28:47 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1E1B31D653; Tue, 5 May 2020 18:28:47 +0200 (CEST) Received: from us-smtp-1.mimecast.com (us-smtp-2.mimecast.com [205.139.110.61]) by dpdk.org (Postfix) with ESMTP id 546361C1C0 for ; Tue, 5 May 2020 18:28:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1588696125; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vrpkYiTHhOXpbizjh3G2f9ZuM/zxTIkB2s4qh+SdMdY=; b=SD4o+AAiCXU9e1poV0UvmO1GzBltC8iSBCIs6PghTJhnD+Ii9dXB+oCCgSHQqHVaRor/Ly 6MyAyXmndrhLMieG6t2yiACwv2e3hua3CiABH7jD6mjaU2zriQ/IGceS/Ka/on8I6vOHYV YKCFoHv9hyzWW8scql++rVs11ry7pNU= Received: from mail-vs1-f72.google.com (mail-vs1-f72.google.com [209.85.217.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-4-7UTKPL8HOCOIjwhjLvdKDg-1; Tue, 05 May 2020 12:28:41 -0400 X-MC-Unique: 7UTKPL8HOCOIjwhjLvdKDg-1 Received: by mail-vs1-f72.google.com with SMTP id w18so663678vsw.9 for ; Tue, 05 May 2020 09:28:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=piHs46ZIhcH0Fsz6W0FhkVDUSmWeZfyroZETctGYp18=; b=WjsONPZXNXbhhtSjUE/M8vNmd1HBaX7Qv7U3f9dvar1WSksmubGEnEPpjtXy1fYrz3 G0rK/zzyTex6dnqMNrLSdfS+ePnJUNvG3iayIaIdwDcMFHX7ZGI7i3Q+qCpMNJStffsE AIARUvGBVk3lFmPtUtMYZ2qz66fV3ZThZfzj9J4U1V1AasCNeBTXA845y+SSUuBDuEzm +CEiXJAvtv5Te4fNse99uPE2A1R8LPXAk12Ijviz7W9Tk7J30oSVusVkCaIi9skbWKdj mAcInZj9JO/z7eZB9adMCD41xKcwKEZF5Xogv7Po07pV1GdD7wpb3BXz1c+gna2JAoJq FhIQ== X-Gm-Message-State: AGi0PuY5B7TAA23gHQZk74vCkfs7APxpCiYHiXnnCXlxCGh7NN2DTH19 x5+A0sKDo2Mr7t868Z2X4nvy9V5YXdbnMHT3ANlqTiVtqLHmHmzkwzZY9HwQt4JC9eK40XdCVK2 M1QI6uTC8oCkBFJK+a0I= X-Received: by 2002:a67:ff95:: with SMTP id v21mr3795412vsq.105.1588696121387; Tue, 05 May 2020 09:28:41 -0700 (PDT) X-Google-Smtp-Source: APiQypKZx03f03ggv714MKAHH6eHwA6puLj4LMys9RPi7mC8oMJa9EeUnDD1YwYiRu8qYlA6c3T9TfRdlVJImWh3PhM= X-Received: by 2002:a67:ff95:: with SMTP id v21mr3795387vsq.105.1588696121109; Tue, 05 May 2020 09:28:41 -0700 (PDT) MIME-Version: 1.0 References: <20200503203135.6493-1-david.marchand@redhat.com> <2596990.BEx9A2HvPv@thomas> <2479551.BddDVKsqQX@thomas> In-Reply-To: From: David Marchand Date: Tue, 5 May 2020 18:28:28 +0200 Message-ID: To: Jerin Jacob Cc: Thomas Monjalon , dpdk-dev , Jerin Jacob , Sunil Kumar Kori , John McNamara , Marko Kovacevic , Declan Doherty , Ferruh Yigit , Andrew Rybchenko , Olivier Matz X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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" 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 w= rote: > > > > > > 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 loo= k 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 registrat= ion. > 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. 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, --=20 David Marchand