From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
	by inbox.dpdk.org (Postfix) with ESMTP id D8DBEA059F;
	Fri, 10 Apr 2020 15:46:00 +0200 (CEST)
Received: from [92.243.14.124] (localhost [127.0.0.1])
	by dpdk.org (Postfix) with ESMTP id B0CD61C2EE;
	Fri, 10 Apr 2020 15:45:59 +0200 (CEST)
Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com
 [207.211.31.81]) by dpdk.org (Postfix) with ESMTP id 299D51C2EB
 for <dev@dpdk.org>; Fri, 10 Apr 2020 15:45:58 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
 s=mimecast20190719; t=1586526357;
 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=GOGt76wuHmWer3ZL0tJ+wurWjIsS2ILEAk9K6RfP+A0=;
 b=Du1nLoq1hQggN3eJazPo2AKjLgZoQhAbbrzKsvkcV03vXSlfap4ZCytHPrcG0KB4LrG3IK
 vWnDp1JDOhROWqpjtcJ8a1K0dQMZcYFU6gIPtVj3C3lSdl1R31wA+Xwlh1hG2WVbdoBMHL
 GceqTb/HobN3hTLs2csk+YDhPRVyDVs=
Received: from mail-vk1-f197.google.com (mail-vk1-f197.google.com
 [209.85.221.197]) (Using TLS) by relay.mimecast.com with ESMTP id
 us-mta-453-kXZUzTZoO-Cg0ThaBzVvRg-1; Fri, 10 Apr 2020 09:45:56 -0400
X-MC-Unique: kXZUzTZoO-Cg0ThaBzVvRg-1
Received: by mail-vk1-f197.google.com with SMTP id e69so898109vke.11
 for <dev@dpdk.org>; Fri, 10 Apr 2020 06:45:55 -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=+nR+PYnL6C5jdGgpO7+KK6QPkALJNXfGgKMNRbBVNTg=;
 b=RNM/InQsQ3h//u01moWgCih/0Mk8RnFSRgpXOXUlfqoTKU3eISTuPyxQNJH1IOB9V0
 I+IrUpLWAAUWF2UTLPX+1NrPeD2JpK/fCKVPBHwghmjF9BXXu+ATaF3gwqnWPr1S9b+4
 sT3FPb8cIKw76NqiqmFPh7qT55JPW3jGejX7P5nU8ZuRk1XlB3yt0AtrZP9d4wREH6wh
 uuJuU2rSl+aH4nts8u3qTFdKWbPCMA9d0bCQRbOC4KUr7rIQ1j93N9AtvL9KCvz6WY4B
 wclwP8imCxo/zXbwVribfnxViXQDQhgGE6EfAerxnc9eqDSSHc/FUYULbnGjkpPdgvTk
 9idA==
X-Gm-Message-State: AGi0PuZFon3EmvwkYUF1XhK+r3HvO/N8mXQCduacbxlahiC55vtOCVB1
 hk1YUYLoraJmhenIACaeF0NUIj97uOEA3K357L68Fa4cKXJm9SOHybSlGmC6hPO7XShsQLRpYZS
 anrsuF5ag540uxDH+pDA=
X-Received: by 2002:a67:26c2:: with SMTP id m185mr3959180vsm.180.1586526355381; 
 Fri, 10 Apr 2020 06:45:55 -0700 (PDT)
X-Google-Smtp-Source: APiQypI1qQBW2mg8x6mYnOBPiGXFmMJ52L/4WpmsSZeG6WHXq1CAcgS4486CJaEbDaMKzbsUY80IfD3SDItxPPPhhUQ=
X-Received: by 2002:a67:26c2:: with SMTP id m185mr3959162vsm.180.1586526355082; 
 Fri, 10 Apr 2020 06:45:55 -0700 (PDT)
MIME-Version: 1.0
References: <20200329144342.1543749-1-jerinj@marvell.com>
 <6115809.K2JlShyGXD@thomas>
 <CALBAE1M43byd061xSiKUvtq8MxwSu41P1DTd+jHsNnWLAmo8Qg@mail.gmail.com>
 <14100064.JCcGWNJJiE@thomas>
 <CALBAE1MbxxdDv57zH3Sb3LF7z_E+3VUo_p99VogBKsvi05FMEA@mail.gmail.com>
 <CAJFAV8w_K2vwit68uhV6f3OWH+Djr8ZqroJ5XQHNCqhSQa3Dbw@mail.gmail.com>
 <CALBAE1P5BwBT7mgOH2-e9sjgpz0+z77csyQ_q4j_xtDRipwW2A@mail.gmail.com>
In-Reply-To: <CALBAE1P5BwBT7mgOH2-e9sjgpz0+z77csyQ_q4j_xtDRipwW2A@mail.gmail.com>
From: David Marchand <david.marchand@redhat.com>
Date: Fri, 10 Apr 2020 15:45:43 +0200
Message-ID: <CAJFAV8wdnkxO2O+GiFq9DBpYwJqqPhSPyJnGTx7Jrf3NAuTUEA@mail.gmail.com>
To: Jerin Jacob <jerinjacobk@gmail.com>
Cc: Thomas Monjalon <thomas@monjalon.net>, Jerin Jacob <jerinj@marvell.com>,
 dpdk-dev <dev@dpdk.org>, 
 "Richardson, Bruce" <bruce.richardson@intel.com>, 
 =?UTF-8?Q?Mattias_R=C3=B6nnblom?= <mattias.ronnblom@ericsson.com>, 
 Sunil Kumar Kori <skori@marvell.com>, Olivier Matz <olivier.matz@6wind.com>
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 v4 00/33] DPDK Trace support
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On Fri, Apr 10, 2020 at 3:30 PM Jerin Jacob <jerinjacobk@gmail.com> wrote:
>
> On Fri, Apr 10, 2020 at 6:45 PM David Marchand
> <david.marchand@redhat.com> wrote:
> >
> > On Thu, Apr 9, 2020 at 8:27 PM Jerin Jacob <jerinjacobk@gmail.com> wrot=
e:
> > > > The global level is just disabling some logs even if it is enabled
> > > > in the logtype level.
> > > > It only makes usage complicate.
> > > > We should consider only logtype levels.
> > >
> > > OK.  Do we care about the following use case?
> > > # Trace only specific types of events(example, DEBUG or CRITICAL)?
> >
> > The event types can be encoded in the tracepoint names if we want to
> > organise trace points with types (maybe as a suffix).
> >
> > >
> > > IF NOT,
> > >
> > > There is no need for,
> > > # rte_trace_global_* API
> > > # No need to introduce trace type(ie DEBUG or CRITICAL) i.e remove
> > > rte_trace_level_set() API etc
> > >
> > >
> > > # In summary:
> > > ~~~~~~~~~~~~~
> > > # In the existing code:
> > > The trace will be emitted when
> > >  a) When the trace is enabled
> > >  AND
> > > b) trace level than the global level.
> > >
> > > # in new suggestion
> > > The trace will be emitted when
> > >  a) When it is enabled
> > >
> > > And the EAL argument will be --trace=3Dregex/globbing, This EAL argum=
ent
> > > will call rte_trace_regexp() and enable the selected tracepoints.
> > >
> > > The downside will be it will not be similar to log API. I am fine wit=
h
> > > either way.
> >
> > The level notion in the traces api is artificial.
> > I prefer a simple api where tracepoints state is controlled via a
> > single criteria: with the new suggestion that would be names.
> > So +1.
>
> I thought it may be helpful to replace log and I decided to pick the
> level in the trace.
>
> Looks like the consensus is to remove "level" from Trace.
> OK. I will rework the Trace API to remove the "level" and
> rte_trace_global_* API from Trace library.
> Let me know If you have any other top-level architecture comments if any.
> I will send v5 with new changes.

Thanks Jerin.


- I am still looking at the event record mode.
I just wonder why we have this notion per tracepoint.
The documentation talks about it being an attribute of the trace
buffers, and the described behavior looks fine.
But if we can set this mode per tracepoints, once a trace buffer is
full, won't it be hard to figure out why some events have been caught
and not others?


- Another comment, on the form, I can see that we talk about dataplane
tracepoints and fastpath API.
Is there a difference? or could everything be named in a consistent
way (the headers would have to be aligned too)?


- Do we really need to export the rte_trace_lib_eal_generic_* trace points?
They seem more like examples and I don't see a usage outside of the tests.


--=20
David Marchand