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 E7139A0597; Thu, 9 Apr 2020 18:35:09 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4DF0B1D159; Thu, 9 Apr 2020 18:35:09 +0200 (CEST) Received: from mail-io1-f51.google.com (mail-io1-f51.google.com [209.85.166.51]) by dpdk.org (Postfix) with ESMTP id 3E8B81D158 for ; Thu, 9 Apr 2020 18:35:08 +0200 (CEST) Received: by mail-io1-f51.google.com with SMTP id f3so229885ioj.1 for ; Thu, 09 Apr 2020 09:35:08 -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=O8Lqu93leAqt2/CKnSFRnyJpBRxMLl2+V/hItSY6xUw=; b=dtGorIX18UUAFIEUCIxs0QmEfjzxYEDHeZC8f1X5QdAVjkWyvo6qVS7UzU18dqLdOY dEVrAr7sFEd3HmmnAYItvp9gmcQ+TAiwH5zy9iFT0VH3Uhxn2L1y4ml1hPl+MpwAzc+5 3SGJL+ACkEnjqGw6MRL5RGtCJ+01w1fHOm2koFpfVe6WkJdYa7xx9yiJ5v+qKgX+cSYj zW9eeRFkAXzLbjiurFgL8E3Zff1EXiSAYvsRB+TaZauGVQg7zh+con3pmNAYIEDdwRFg mKceZn6vqpqyX6kA0G57XTcMjJG34FtaCJhXRqGQgkBYotyWqMjZH+s2S08BRUnbzunV Mrog== 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=O8Lqu93leAqt2/CKnSFRnyJpBRxMLl2+V/hItSY6xUw=; b=pn5BOAhI515C6Ybul+Y9IJazsc4v8zx4sgnsO7NsVNJMXqR1zdIFPZxa1hvr4xOcGT LHdDgg8Ly+YKofangPPnAB0kILfAJ8S6wDqRPm7S15p8fkTrgOznAXY2FmOrOWqRx0nJ cA1aDftrjlGAvGQeCkStLhdejBg5KuBY2LIujgqiRog5duT0VNC9FqDdoiES41aDVMEa uxN3uG1VOTMXowYIRvgCCclZdtGpxVebW7nUc12+ZyuQfWbik/wzQajUMl8f1nGZ9QAz wDpsXEkD0gE1X12f5GpQNWx6nLp/rc2dvJWiOPJUBBERZnhUA2H8URPwDnCeaRtEVtCm ZlYA== X-Gm-Message-State: AGi0PuYKDN7oOxwEiwqJELR6DAokM/9CCI73PVzDpR21zHjEDd6PvN17 O56E95uRlDcDoFnkAzj7eggM9DGHTMWWtmoBE6E= X-Google-Smtp-Source: APiQypLnKE1UizM0WfoQaWY7EWQu9xEQgTEdNrX2ivnlPeHd33+gDfkMZrxZbXxia/DPxjllHlNEaeyAEa6wcjyUgxU= X-Received: by 2002:a02:3506:: with SMTP id k6mr301372jaa.104.1586450107369; Thu, 09 Apr 2020 09:35:07 -0700 (PDT) MIME-Version: 1.0 References: <20200329144342.1543749-1-jerinj@marvell.com> <2501342.7s5MMGUR32@thomas> <6115809.K2JlShyGXD@thomas> In-Reply-To: <6115809.K2JlShyGXD@thomas> From: Jerin Jacob Date: Thu, 9 Apr 2020 22:04:50 +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 9:30 PM Thomas Monjalon wrote: > > 09/04/2020 17:36, Jerin Jacob: > > On Thu, Apr 9, 2020 at 7:30 PM Thomas Monjalon wrote: > > > 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? > > Completely remove global level. > Why would we need 2 levels of level? > > > If we remove, then I dont know, how we can map --log-level or > > --trace-level EAL command-line argument. > > They are setting levels with regex or globbing. > --log-level supports 3 syntaxes today: > - int (global level) > - globbing:int > - regex,int Here is my understanding. IMO, Actual Syntax is - int (global level) - globbing: int (global level) - regex: int (global level) i.e 1) Each log/trace has a "level" 2) There is a global level. See [1] 3) The trace will be emitted when a) When it is enabled(not applicable for log as it is always enabled) AND b) it is less than the global level. The global level will be useful to control what category of trace "level" needs to enable. I think, it is useful to trace only DEBUG or CRITICAL events, Any reason for thinking, it is not. [1] /** * Set the global log level. * * After this call, logs with a level lower or equal than the level * passed as argument will be displayed. * * @param level * Log level. A value between RTE_LOG_EMERG (1) and RTE_LOG_DEBUG (8). */ void rte_log_set_global_level(uint32_t level); > I propose to drop the first syntax because it became useless > now that we have powerful globbing and regex. > > > > > 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. > > Yes I think globbing is more accurate than "shell pattern", > because we can use regex pattern in shell as well. I will change to "gloabbing" in trace and submit a patch for the same for rte_log as well. > > > > > > - 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. > > OK I think it would be good to have only one system. Yes. We can switch over to rte_trace when it is decided. > > > > > > - 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. > > That would be a nice feature. > > > > > > - 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. > > OK makes sense. > > Note: I prefer rte_get_timer_cycles() because rdtsc is an x86 instruction. Code is using rte_get_tsc_cycles() public API as wall clock is based on tsc clock( Which is available in the system in all the cases) > > > > > > - 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). > > I can understand the performance reason. OK > But if another library can provide the same performance, > I don't see any reason not depending on it. > If the dependency is not found, the feature can be disabled. Yes. But, if we replace rte_log with trace, it can not be just an optional component and it can run wherever EAL can run(i.e Windows OS). Trace format will be the same across all the EAL environments a.k.a common post trace analysis tools. > >