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 70EBAA059F; Fri, 10 Apr 2020 17:01:14 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4386C1D5B0; Fri, 10 Apr 2020 17:01:14 +0200 (CEST) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [207.211.31.81]) by dpdk.org (Postfix) with ESMTP id 68F131D54D for ; Fri, 10 Apr 2020 17:01:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1586530872; 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=FbFGvksWv8av3wygfysg7uWApX7GkpnEg2M9cjxRdlY=; b=LxslXd11fN3mAJbkCJ2UrpmhXviM7lTOT2jpsRO/cYOcscIKi4aAWeAV/tq+Afl5ue6IU3 MjWxFScPLZfzqMje3HJl0gm2sxIDSwZAVZqaopYQY5OCDZQFnz9Os21ZYnR8dOTvqukXgK Crs5S5FKKVa683NfHFG5qxA6sC667JA= Received: from mail-ua1-f70.google.com (mail-ua1-f70.google.com [209.85.222.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-343-oJ-YTLGFNS6Y7UjslXLmfw-1; Fri, 10 Apr 2020 11:01:11 -0400 X-MC-Unique: oJ-YTLGFNS6Y7UjslXLmfw-1 Received: by mail-ua1-f70.google.com with SMTP id f45so756468uae.10 for ; Fri, 10 Apr 2020 08:01:11 -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=0lmb34SHg+VWB1McFpbpOkk4HSR82OXzCsJ1Pli56G0=; b=AWGMhLHloVelC4CQLoVmSWYr6r/lUVn/Y1nAw9iKoncsOXGnSfTmPXvfcpnFpDjSYU ySlOE/ojnpj3sVJSFpuE6SalAMlOz9jeQbxhFjctzsjPzw1H6UUoLcspD6rDq93FnkUy qa066/hpJGGcJv40oX7nO9MunLRer6OIr4xut+UpAStI4sddZFkQ4b2Zjg5yrOQ3zFSw b7hxCpyAt8uE1z+vEsqorF8pqoN1KPW9S3H3y47pUGtEhFRyV2psqrdBj2F6bJ0jkWUT OLyUzFtPInEGv+f958OWp6DxJtkJ4EiOAqc6rD4/AaV31pkY1e9ywj5vbTuz//ne9GJ2 l9Ag== X-Gm-Message-State: AGi0PuY8r29LrGLGvFWgelFo89yE9nyrTqp63+QNqnxSqRi09NlMUrXr MYSi+MuFXOXykIUue7bXNcsd5pNqUpPsBvhcVMD3A/q6xX467V4i+OA8XAU7/WRb9xzP90T6HH3 Koxy3QIbBEJuK59/x0Os= X-Received: by 2002:a67:e995:: with SMTP id b21mr4073089vso.105.1586530870384; Fri, 10 Apr 2020 08:01:10 -0700 (PDT) X-Google-Smtp-Source: APiQypL0NrRr+1cIrQRsQZuYE7OX7WUjVkHNRsX7sYh3Ie943WIqMUp30YWSExjPAhQPzmsxbKcTex5+FWpmgLbYyQM= X-Received: by 2002:a67:e995:: with SMTP id b21mr4073029vso.105.1586530869908; Fri, 10 Apr 2020 08:01:09 -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 17:00:58 +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 4:38 PM Jerin Jacob wrote: > > - 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? > > In fastpath, I tried to avoid reading multiple control variables to > improve performance. > i.e the tracepoint(uint64_t) has all control information. So it has > given a feature to control mode per tracepoint. > I thought it may be useful. No strong option here. > > If you think, it is not usefull and creates more problems, I will > change to the following: > > 1) Remove int rte_trace_mode_set(rte_trace_t trace, enum rte_trace_mode_e= mode); > 2) Change > From: > void rte_trace_global_mode_set(enum rte_trace_mode_e mode); > to: > void rte_trace_mode_set(enum rte_trace_mode_e mode); Yes, you can keep the information in the tracepoint descriptor and expose a single api that impacts all tracepoints. +1 for me. > > - 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 > > No. Both are the same. > > > way (the headers would have to be aligned too)? > > Personally I like the fast path. The log calls it as DP( see RTE_LOG_DP). > In order to have consistency, I will pick the DP and change it everywhere= to DP, > and header files to xxxxx_dp.h from xxxx_fp.h. I too have a preference for "fast path". Thomas ? > > - Do we really need to export the rte_trace_lib_eal_generic_* trace poi= nts? > > They seem more like examples and I don't see a usage outside of the tes= ts. > > This generic tracepoint for any quick debug, For example, if some need to= add > tracepoint to just emit string in the middle of debugging a problem, > they can use rte_trace_lib_eal_generic_str. > That's the reason for exporting it. Ok, let's leave it as is, I need to think about it. --=20 David Marchand