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 C137EA0597; Thu, 9 Apr 2020 18:00:14 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 461221C43D; Thu, 9 Apr 2020 18:00:14 +0200 (CEST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 1A85C1C29F for ; Thu, 9 Apr 2020 18:00:13 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id B4F855C29FA; Thu, 9 Apr 2020 12:00:10 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Thu, 09 Apr 2020 12:00:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=daHcgvR6ksw10OA6RrDfzkdG18s8ghzj97how1GvDSI=; b=L2q3uO8VnDxW +8LI1s7S/nZjHnWP+fBp175/gcPpuYg1WHi8aiV9sie/3FCdZ/Kl+7J1QjNYIDBA FO5i5PYuRafsoG9Idsa4DXxgYhq3AdHHpwA+y7VdzYbzyvhGkwJ6v1Wy/n/cjQeS AGy62cJQ/O+5UJxpH5TNSiH3gBM0OSk= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=daHcgvR6ksw10OA6RrDfzkdG18s8ghzj97how1GvD SI=; b=xo8Io7Ts0xDd+hSUb70K7bi1Om8wNLe8ex9Xj538O57UCOXZFnM2PRa1n leXEuSycTs8lCF1eXYPlAd4ap480YO0vCcHIR4KOIbzfp+17c5BT2QVuuopeTQS1 kgPAp/0Zb6/Qh5/DEpBA4YlaVebvvdzGFxmPPvvRuBngIsx7IqG2MxkG/RBk3Pxj DeD7EKK+l3JjpUaOY4nuugmPG5Wsh60s5IZlOMCHnjvxELCMxCWnlbiA9dT7LPj8 U5s8iKYxLnoOe4qRc/t/2bBSPxLjoChdvsSjWgbRphLG5sqJFQ76WaAC/sK161S9 1Ke3GYWp1WHieIqXIpnfpksyQ0WQQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudelgdeklecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucfkph epjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghr rghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 973293060064; Thu, 9 Apr 2020 12:00:08 -0400 (EDT) From: Thomas Monjalon To: Jerin Jacob Cc: Jerin Jacob , dpdk-dev , "Richardson, Bruce" , David Marchand , Mattias =?ISO-8859-1?Q?R=F6nnblom?= , Sunil Kumar Kori , Olivier Matz Date: Thu, 09 Apr 2020 18:00:07 +0200 Message-ID: <6115809.K2JlShyGXD@thomas> In-Reply-To: References: <20200329144342.1543749-1-jerinj@marvell.com> <2501342.7s5MMGUR32@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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" 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 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. > > > - 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. > > > - 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. > > > - 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. 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.