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 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 ; 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 ; 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> <14100064.JCcGWNJJiE@thomas> In-Reply-To: From: David Marchand Date: Fri, 10 Apr 2020 15:45:43 +0200 Message-ID: To: Jerin Jacob Cc: Thomas Monjalon , Jerin Jacob , dpdk-dev , "Richardson, Bruce" , =?UTF-8?Q?Mattias_R=C3=B6nnblom?= , Sunil Kumar Kori , 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Fri, Apr 10, 2020 at 3:30 PM Jerin Jacob wrote: > > On Fri, Apr 10, 2020 at 6:45 PM David Marchand > wrote: > > > > On Thu, Apr 9, 2020 at 8:27 PM Jerin Jacob 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