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 AE08DA0597; Thu, 9 Apr 2020 17:37:06 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id ABB1A1C29F; Thu, 9 Apr 2020 17:37:05 +0200 (CEST) Received: from mail-io1-f50.google.com (mail-io1-f50.google.com [209.85.166.50]) by dpdk.org (Postfix) with ESMTP id B94E31C29B for ; Thu, 9 Apr 2020 17:37:03 +0200 (CEST) Received: by mail-io1-f50.google.com with SMTP id w20so25567iob.2 for ; Thu, 09 Apr 2020 08:37:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VKYMu9RhIjIZU48Yr66jDQiDYo99RszDYIbl6qSockQ=; b=Arv4sF4HbREXBamyGA6Uv6HQ2Evmr/f73sj6RlRp74VsOMP1/zszinmQ/h1sFRaWMy Qganh1LFVQdAIK1qtGDBBP/tLxpcKmEE0vO1yU2uxBYMqIGAm0agFd04hKkh1PxKrqfN zIuXUPhHpsrg4EVuIAt7hIOd3JHz9P6WzOpFdXvTjcNcnfePkXhixYnB3UMfuq5N0I96 gJtSxH4ZmDBGsUGYs6UfGamHx32WpyyENimjKAhRNWFJiWUT4HpJ6ML6Px0lyfqBQ4/O S1AM4fgpCFqLYm8AuK5QaPgiz+ToecFOVVOegD7VrPO+lYesSr0fDsaEXudZrNZ4jW3g TM7g== 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=VKYMu9RhIjIZU48Yr66jDQiDYo99RszDYIbl6qSockQ=; b=RuacI+BTDpFXQ8cRK9tIh5ceYduGPqXFQnU2X1vO17C2r21AJGowMSmemvf3RjuTCN gNAmpJT2/SnWAlriV8pv5m9a6PVTxw9lNj87YRkMHyRNcLWr0CDvv5IFhqtSt8YsV4Qt b7QgMu0ugXr2w2C0FvTj44jBfiuxzu5R6Ms79cStNwHmQZ7zvHWwnLZoMqYSKLp8kepc L9OQ7HARsxw+ECjc4MAzr9WOiW/F6PNcMIpkQJuZQHKvRCabRbgxNA5x4kjBAF80RTZe hQZzGAdW5ZO403XQacoue3NPerVm7fc9xHyz2ggXYvkUjK+O5PzAWavnGIbx3RcL7D/v mRGA== X-Gm-Message-State: AGi0PuawPuRjOaGZR0SM6SRDstXSD6jMM4kBS7s/eIUMh5SRpKnUgPS3 2TUhLpEE4yL1Pqbel/Vx6b9aJbpYgg06VOcj3n4= X-Google-Smtp-Source: APiQypLOSMZq+JdSS1/gzbCfR6TeitcPep20agUgyQby8fCcbWLouteuZ00u4JDPmQF+FPTosnR0pGRe/PnbOfk1bv8= X-Received: by 2002:a5e:8815:: with SMTP id l21mr5247652ioj.59.1586446621616; Thu, 09 Apr 2020 08:37:01 -0700 (PDT) MIME-Version: 1.0 References: <20200329144342.1543749-1-jerinj@marvell.com> <20200403153709.3703448-1-jerinj@marvell.com> <2501342.7s5MMGUR32@thomas> In-Reply-To: <2501342.7s5MMGUR32@thomas> From: Jerin Jacob Date: Thu, 9 Apr 2020 21:06:45 +0530 Message-ID: To: Thomas Monjalon Cc: Jerin Jacob , dpdk-dev , "Richardson, Bruce" , David Marchand , =?UTF-8?Q?Mattias_R=C3=B6nnblom?= , Sunil Kumar Kori , Olivier Matz Content-Type: text/plain; charset="UTF-8" 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 7:30 PM Thomas Monjalon wrote: > > Hi, > > 03/04/2020 17:36, jerinj@marvell.com: > > Features: > > ~~~~~~~~~ > > - APIs and Features are similar to rte_log dynamic framework > > API(expect log prints on stdout vs it dumps on trace file) > > A log can print to syslog as well. > > As discussed somewhere else, please do not introduce global level > in rte_trace. I think it is useless. If we need to change the level > of all trace types, we can just use a wildcard (globbing or regexp). Currently, In the log library, when EAL command-line argument specifies the "--log-level=val" it, will call the rte_log_global_level_set(val) Is the suggestion to make rte_log_global_level_set() as an internal EAL API or remove that feature? If we remove, then I dont know, how we can map --log-level or --trace-level EAL command-line argument. > > And about wording, "pattern" is too vague and should be replaced > with "globbing". Currently, we are using the word "shell pattern" in log and trace. According to man 3 fnmatch, both being used. I can send a patch for changing the "shell pattern" to "glob" in rte_log.h and update the trace if needed. Let me know?. IMO, Both has to use same word. > > > > - No specific limit on the events. A string-based event like rte_log > > for pattern matching > > Would it be possible to replace rte_log with rte_trace? Yes, I kept public API similar to log to have that use case in mind. > > > > - Dynamic enable/disable support. > > How dynamic it is? Can we start/stop a trace after starting DPDK? Yes, we have fine control enabling and disabling a specific or group of events. See rte_trace_enable(), rte_trace_disable() and rte_trace_pattern() > I think we need a control channel for this. > I propose to introduce a general control channel in DPDK. Yes. Once we have a general control channel in DPDK. We can hook rte_trace_enable() and friends in the message handler. > > > > - Instructmention overhead is ~1 cycle. i.e cost of adding the code > > Nice > > > > wth out using trace feature. > > - Timestamp support for all the events using DPDK rte_rtdsc > > Could we use other timestamp sources, like the mbuf timestamp > for Rx traces? Trace will be running at the global wall clock. Rx specific tracepoint can add mbuf->timestamp as FIELD in the future if needed. > > > > - No dependency on another library. Clean room native implementation of > > CTF. > > No benefit of using an external CTF library maintained somewhere else? See performance data comparison with LTTng in the cover letter. We discussed this enough in the mailing list on RFC and decide to use Faster trace support for Fastpath use case and avoid any external library to EAL (We need tracepoints in the EAL too for tracing). > > >