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 F1F4041D53; Thu, 23 Feb 2023 19:09:23 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 43B7B40ED6; Thu, 23 Feb 2023 19:09:23 +0100 (CET) Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.173]) by mails.dpdk.org (Postfix) with ESMTP id C490A40693 for ; Thu, 23 Feb 2023 19:09:21 +0100 (CET) Received: by mail-pl1-f173.google.com with SMTP id e9so8986350plh.2 for ; Thu, 23 Feb 2023 10:09:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; 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=0XtoMKVH8oSzxVJ7FrsoMHxPsYTsl+YVcwmPJQ2+NJU=; b=zvkvVqJErwp3gPddyN2kYtzY3LUcRjBrvvuDBqzpot1A7SnKh1UTcBYieZfIniffYa LEyB0WahD0CtPOzVY3QG5mCfdTtkuC7ETKvhADKNMZgGpOHMhn64yFkX/p6X7sSKnYDo 9cfLTwy3VFe29BIsWP4d4FrczlrtHfH9stxHcscAMK3k8O+creTU+y9VNba3hehn7Cuq BkTR0ebGtWhOsqAg7hrBupMJuRD4vQjEuotJ+qtomOCHgIOUOol4p3h3zxoTMbZttJQZ hhLU+uVVgl3DzbVbUtbIUwA/kaSfPMDQmGWvK2chHfXFkjwhQT85SiLr7WQo3cvYMjJW 6UNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=0XtoMKVH8oSzxVJ7FrsoMHxPsYTsl+YVcwmPJQ2+NJU=; b=Wg3YnsZNQYxQyf+zD7WYIsB5q5fV+8GFm2kFlxxEN57hiy0aproC8jqLuzHf0yH+kh QjrDzfxCSZEjWrEbYTrOje1EY3bSGZo0RSbhaYDdixaXWTTk3aIFgy9xIB764UhgGl3/ T5YuwOfqiIEcIX3ZS1psX5laTJaiIufFKJCn0oZzGZFrFaQY8s1SwqHxopsdGqnuOzSC mebPwoTlQjPSwmomkHC/yZwn+/Jhl8N3rBQRx6g7Sir0X6PNAUkAAojH27CTsyHCKQR9 Nmk8bRv4DS9BRK/yAX5eX5CXlSiu7OgRDaXGnDow7thu1pjh2NreM5bz+cQVGn6DrzLi OM/w== X-Gm-Message-State: AO0yUKXqqbK1D2eubyaP2Hf+GUixGVI7n4RBbDOyXlxO+d9d/fi9G3Ht xzpGxijbqtWrqjzdzPMjc4RIFA== X-Google-Smtp-Source: AK7set+xampv7LzpyYh3o3AQR1IAD/nmdkdLSYuvbqY5MBJMnvBHmpL53XAkt4LsADrtbDcpD9sk9A== X-Received: by 2002:a05:6a21:338d:b0:bc:333f:b958 with SMTP id yy13-20020a056a21338d00b000bc333fb958mr14459737pzb.30.1677175760789; Thu, 23 Feb 2023 10:09:20 -0800 (PST) Received: from hermes.local (204-195-120-218.wavecable.com. [204.195.120.218]) by smtp.gmail.com with ESMTPSA id s19-20020a63af53000000b00502f1256674sm1959973pgo.41.2023.02.23.10.09.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Feb 2023 10:09:20 -0800 (PST) Date: Thu, 23 Feb 2023 10:09:17 -0800 From: Stephen Hemminger To: Ferruh Yigit Cc: longli@linuxonhyperv.com, Thomas Monjalon , Andrew Rybchenko , Jerin Jacob Kollanukkaran , David Marchand , dev@dpdk.org, Ajay Sharma , Long Li , stable@dpdk.org, Luca Boccassi , Qi Z Zhang , Ajit Khaparde , Bruce Richardson , Konstantin Ananyev , Olivier Matz , Honnappa Nagarahalli Subject: Re: [PATCH] net/mana: use RTE_LOG_DP for logs on datapath Message-ID: <20230223100917.282f191c@hermes.local> In-Reply-To: References: <1677012145-3559-1-git-send-email-longli@linuxonhyperv.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 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.