From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 1EB5241DCB for ; Sat, 4 Mar 2023 01:16:26 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 110BB427F2; Sat, 4 Mar 2023 01:16:26 +0100 (CET) Received: from mail-pj1-f42.google.com (mail-pj1-f42.google.com [209.85.216.42]) by mails.dpdk.org (Postfix) with ESMTP id 9D60140EE3 for ; Sat, 4 Mar 2023 01:16:24 +0100 (CET) Received: by mail-pj1-f42.google.com with SMTP id x34so4379371pjj.0 for ; Fri, 03 Mar 2023 16:16:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; t=1677888983; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=u/gktD55/+svylhNnPkCmrZoBx2jS5ktmbg6wLonypg=; b=EoV3J2EzjXxryfDujI4nJRMcpMwQZLSmx7EYcuLw8DtxiB+174/ZA1XnzDNV8GOObf Ldqs3bmqozV4+Tx00OwZsWoX/aPuZbtAUu3/yk3ydTnU78kuXIER8lgh4Mn0F2ZmXFX0 R8ebk7CUneddNgOrz/ugvb/0iOA2LG1YzMS0V+7SuttklzXFTqD3A8BkDk2CXdXREVvP THm6GXsoSPR374BiDzL7WIAdpn57830o9IewyOQV48YsItCigFO0T0JKO+aB6I816wSH jQjyqSxPdpFal4sbTfYM3LnWhaC+mbdY+LZY6EtW5Yjg5Yp4SzOsbZlf8yb/a/GzCW7w 3KkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677888983; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=u/gktD55/+svylhNnPkCmrZoBx2jS5ktmbg6wLonypg=; b=nw1x/AZERvpUhNvSlMG1ZK1dFfMsSPXe12/v2i7TPJqVTlAYdL4Uthry1zlhnJZWdj UdCLaFlwxJWrwe9aNN3hjAPeb1jpxGMNsjS7Dp7ytdjJRlu7jDwefRhJ2xmhbAuuXssx lgmZ84ULiGXWm693E57AQE75TSGW96k6NHASG12J8dgNizlx6yrop5V5anfYO6QQ0BTY hL4feqC0uEEqQGAIQgPtQ9ZWnYL61zE3l+OdDuSCojGhzdgM0Ku5cotXmMQKItVaD2If oisVRblSCLt0EYThDMgJqSwVZb9lqpY7GDS9EktzXraFRmxnbI02+zKvGOE72kM2ZTfi 5oCg== X-Gm-Message-State: AO0yUKWoStPz5LwD3zVTa0fXdjDVJ9HENt+F4kdN5X1yolcAUcxApz0C wo08yv5E5dgnThLJH+nBU8f5sQ== X-Google-Smtp-Source: AK7set/tnY1A530XPr19TJ4ZIsaQdZG7iBT0h3vL52/86gEAbnZC3tdeCML1QtqjpKYahz8H4LnwRg== X-Received: by 2002:a17:902:e5c2:b0:19a:a650:ac55 with SMTP id u2-20020a170902e5c200b0019aa650ac55mr8211688plf.23.1677888983367; Fri, 03 Mar 2023 16:16:23 -0800 (PST) Received: from hermes.local (204-195-120-218.wavecable.com. [204.195.120.218]) by smtp.gmail.com with ESMTPSA id g15-20020a17090a300f00b00233aacab89esm1972489pjb.48.2023.03.03.16.16.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Mar 2023 16:16:23 -0800 (PST) Date: Fri, 3 Mar 2023 16:16:21 -0800 From: Stephen Hemminger To: Ferruh Yigit Cc: Long Li , "longli@linuxonhyperv.com" , Thomas Monjalon , Andrew Rybchenko , Jerin Jacob Kollanukkaran , David Marchand , "dev@dpdk.org" , Ajay Sharma , "stable@dpdk.org" , Luca Boccassi , Qi Z Zhang , Ajit Khaparde , Bruce Richardson , Konstantin Ananyev , Olivier Matz , Honnappa Nagarahalli , "techboard@dpdk.org" Subject: Re: [PATCH] net/mana: use RTE_LOG_DP for logs on datapath Message-ID: <20230303161621.2aaec899@hermes.local> In-Reply-To: References: <1677012145-3559-1-git-send-email-longli@linuxonhyperv.com> <20230223100917.282f191c@hermes.local> <20230224095120.32c25481@hermes.local> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org On Fri, 3 Mar 2023 13:54:23 +0000 Ferruh Yigit wrote: > On 3/3/2023 2:16 AM, Long Li wrote: > >> Subject: Re: [PATCH] net/mana: use RTE_LOG_DP for logs on datapath > >> > >> On Thu, 23 Feb 2023 10:09:17 -0800 > >> Stephen Hemminger wrote: > >> > >>> On Thu, 23 Feb 2023 14:07:25 +0000 > >>> Ferruh Yigit wrote: > >>> > >>>> Overall I am not sure if anyone is interested in driver datapath > >>>> logs other than driver developers themselves. > >>>> > >>>> For datapath logging I think there are two concerns, > >>>> 1) It should not eat *any* cycles unless explicitly enabled > >>>> 2) Capability of enable/disable them because of massive amount of > >>>> log it can generate > >>>> > >>>> > >>>> Currently there are two existing approaches for driver datapath logging: > >>>> i) Controlled by 'RTE_ETHDEV_DEBUG_RX/TX' compile time flag, > >>>> when enabled 'rte_log()' is used with Rx/Tx specific log type. > >>>> ii) 'RTE_LOG_DP' ', compile time control per logtype via > >>>> 'RTE_LOG_DP_LEVEL', > >>>> when enabled 'rte_log()' is used with PMD logtype. > >>>> > >>>> > >>>> In (ii), need to re-compile code when you need to increase the log > >>>> verbosity, and it leaks to production code as mentioned above. > >>>> > >>>> For (i), developer compiles once enabling debug, later can fine > >>>> grain log level dynamically. This is more DPDK developer focused approach. > >>>> > >>>> > >>>> [1] > >>>> According above, what do you think to retire 'RTE_LOG_DP', (at least > >>>> within ethdev datapath), and chose (i) as preferred datapath logging? > >>> > >>> I agree, the current tx/rx logging is a mess. > >>> Each driver is different, each driver has to have something to enable > >>> it; and it really isn't useful beyond the driver developer. > >>> > >>> Using tracing seems like a much better option. Could we agree on a > >>> common set of trace points for drivers and fix all drivers to use the same > >> thing. > >>> Probably will cause some upset among driver developers: > >>> "where did my nice printf's go, now I have to learn tracing" > >>> but DPDK has a good facility here, lets use it. > >>> > >>> My proposal would be: > >>> - agree on common set of trace points > >>> - apply to all drivers > >>> - remove RTE_LOG_DP() > >>> - remove per driver RX/TX options > >>> - side effect, more uses of RTE_LOGTYPE_PMD go away. > >> > >> Here is an example of using tracepoints instead. > >> Compile tested for example only. > >> > >> Note: using tracepoints it is possible to keep some of the tracepoints even if > >> fastpath is not enabled. Things like running out of Tx or Mbuf is not something > >> that is perf critical; but would be good for application to see. > > > > Thank you for the example. > > > > I sent another patch converting data path logs (mana) to trace points. > > > > Hi Long, > > Thanks for the effort, you were quick on this while discussion is going on. > > Although tracepoint is a good feature, I am not sure if it can fully > replace the logging. > I think usage is slightly different, trace is missing custom human > readable message, which can be very helpful for end user. Agree in theory, but looking at existing drivers the datapath log messages are all just printf's of existing variables. Plus the interpretation of what those fields and offsets only has meaning and context for someone familiar with the driver. > > And overall, it is a high level decision to switch logging to trace, it > is inconsistent to switch only single driver, perhaps techboard (cc'ed) > can discuss this. Code in existing datapath logging can be easily converted driver by driver. The problem is the lack of testing.