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 5CE4BA059F; Fri, 10 Apr 2020 15:15:37 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 33BF71C0B8; Fri, 10 Apr 2020 15:15:36 +0200 (CEST) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by dpdk.org (Postfix) with ESMTP id 113021C0B7 for ; Fri, 10 Apr 2020 15:15:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1586524533; 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=nsSfYcEByqZQBA9LrQRTHZv5bJ68y05QK1O3KVhv574=; b=Kvl8NeXs+mz9z8TbNcvrMBXbWfhAnrQliINiLBBks/aNDs69AeEpqpHu44uRlDZ7Qfk+VR pboaYhC1xc6VQWToNOyPD9gbm8/MY8fhKZuAvsGXLEVlCDhWR8Uw+6FRwzuzqew52tl4g6 ABdxz75eo5dqz5NH1AQfxn1j/r3cAlI= Received: from mail-vk1-f198.google.com (mail-vk1-f198.google.com [209.85.221.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-10-6ONh3IRdMny_bvNQUrx5Ng-1; Fri, 10 Apr 2020 09:15:29 -0400 X-MC-Unique: 6ONh3IRdMny_bvNQUrx5Ng-1 Received: by mail-vk1-f198.google.com with SMTP id 66so855122vkr.16 for ; Fri, 10 Apr 2020 06:15:29 -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=ArHYPQVRQ7b1mMVsGudDpAok/Ilve7AetWSRWGwlDgQ=; b=gwjspI8xKN2ZeE67PsgCXXq31Eio4HM25toKqTZ8KbHRWN2Yb8mkOt3mRJZDpCfilN YYryxjOXsRBohcMxtg85GkLUPR4TBB2bzvLT+4Xj4UbrXccqnMuYo1t3FhX63Z+g919m Ya+ofO4hC1iSLQD/EfUp4KrCW9YPkD89cXll6Bph8G5lUQnB2JVPHoC9zWcaL6C6psb9 QD69td/gQACcapRQnCxPGYdobqeCGSFT8QMAbc0ik8QzgurKMmuticvJcfLCQdG8L6fC Xpeq+RwISRE8OPwgnr+fB6Qj4UWSzB5+seh1GSaVC36Bv0ooGLMyx4KOvoXgGIgfWBDB 9tXw== X-Gm-Message-State: AGi0PuY4Z/bizZwiFuuM3MhgdKMTkcIDX7QOuxpHAY3MvcznP0HlE6YB IJpTANXT6uJlGBgd6z52C8BZm1m9tehtA9Wkiwa/BpYEJeNxVqMYf8g+yWFMWsgTmSFrN0cWX1l BycaJpumqOfU5yV2PdnQ= X-Received: by 2002:a67:8dc8:: with SMTP id p191mr3709413vsd.198.1586524529146; Fri, 10 Apr 2020 06:15:29 -0700 (PDT) X-Google-Smtp-Source: APiQypL2r/szz9Qe/2m47kZDQP/+olUraf+3LOEhs0+C4273JUm0vBQgzPKxwmUHrFLgnoo8qXuIm73gAAvNZYAfO3Y= X-Received: by 2002:a67:8dc8:: with SMTP id p191mr3709386vsd.198.1586524528857; Fri, 10 Apr 2020 06:15:28 -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:15:17 +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 Thu, Apr 9, 2020 at 8:27 PM Jerin Jacob wrote: > > 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 argument > 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 with > 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. Afaiu, for logs, if we wanted to make use of the trace api, the level notion can be done in the rte_log layer. --=20 David Marchand