From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) by dpdk.org (Postfix) with ESMTP id 24C71C314 for ; Mon, 25 May 2015 12:49:08 +0200 (CEST) Received: by wgbgq6 with SMTP id gq6so69980154wgb.3 for ; Mon, 25 May 2015 03:49:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=NYBfKq+3Juz3PMerwOUyDeFW8OjbUAq5JJmOC1g4Nfc=; b=VltRpmfWC0wFrb8/Bit7ecQrSxa33MEl4sAQ1SVbaykcSiBmB7Y752b0DSCsYBzC2a FWt7UZgL5+ifGOfxFdzCS4kGtE0fpELzeKY1Z9JJntfi88Yi8Snjf2fKSJLCAYPxbcD0 MSwHgsBXLzmHSUJfXdesS3pAgsLlXWfSUhgz+YyZXf4o+1gd+m95bb7ErqxEDXXnIvN7 xfox7KXjAvd2Knd4325C6Sbh1vr/AfuyDi/QOgJ38JK/uia+GwNC06ga1V5oQwV96zKk 8TpiVzkcgQcsSAQy5nECLouzPAb6n5gt9CRAzfQyn7zwQRrEkE9ouZYegDmOn4swJ0Pt cwGQ== X-Gm-Message-State: ALoCoQkkypxi5D+YZWsXgx58u5o0/RIdFYpNKaS7ph8tqhieIf2Z1xXyZl2md0nGGQKvj6sy9BAA X-Received: by 10.180.187.170 with SMTP id ft10mr19360718wic.75.1432550946707; Mon, 25 May 2015 03:49:06 -0700 (PDT) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by mx.google.com with ESMTPSA id x10sm16139560wjf.45.2015.05.25.03.49.05 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 May 2015 03:49:05 -0700 (PDT) From: Thomas Monjalon To: "Dumitrescu, Cristian" Date: Mon, 25 May 2015 12:48:19 +0200 Message-ID: <4548332.fAEkNqmUPJ@xps13> Organization: 6WIND User-Agent: KMail/4.14.7 (Linux/4.0.1-1-ARCH; KDE/4.14.7; x86_64; ; ) In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D891263236AF3D@IRSMSX108.ger.corp.intel.com> References: <1430396143-10936-1-git-send-email-michalx.k.jastrzebski@intel.com> <1677593.4Cv3TcNdFE@xps13> <3EB4FA525960D640B5BDFFD6A3D891263236AF3D@IRSMSX108.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v2] pipeline: add statistics for librte_pipeline ports and tables X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2015 10:49:08 -0000 2015-05-21 13:33, Dumitrescu, Cristian: > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > 2015-05-20 23:41, Dumitrescu, Cristian: > > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > > > I think that counting stats is a kind of logging. > > > > Some stats are always counted (see drivers) and you want to use these > > > > ones only for debugging (after rebuilding DPDK with some debug options). > > > > So I suggest, as second solution, to check CONFIG_RTE_LOG_LEVEL is at > > > > debug level instead of having one option per module. > > > > It would be implemented with "#if RTE_LOG_LEVEL == RTE_LOG_DEBUG" > > > > in RTE_PIPELINE_STATS_ADD. > > > > > > The problem I see with this approach is that you cannot turn off debug > > > messages while still having the statistics collected. We should allow > > > people to collects the stats without getting the debug messages. How do > > > we do this? > > > > By setting build-time log level to debug, you would enable stats and debug > > messages. Then you can adjust the log messages level with the run-time > > option --log-level. > > This is a really clever trick! I have to say it took me some time to > make sure I got it right :) > So when RTE_LOG_LEVEL (build time option) is set to DEBUG (i.e. 8), > then we get both the stats and the debug messages, but then we can > adjust the level of debug messages at run-time through the --log-level > EAL option. > I can work with this option, thank you! > > There is one more simple proposal that came to my mind late last night: > how about single config file option RTE_COLLECT_STATS=y/n that should > be used by all the libs across the board to indicate whether stats > should be enabled or not? Stats in drivers must be always collected because they are not considered as debug information (until now). So I think a global option RTE_COLLECT_STATS would be confusing. > This is logically very similar to the solution above, as they both look > at a single option in the config file, but maybe it is also more > intuitive for people. > > I will go with your choice. Which one do you pick? I prefer we choose on a per-lib basis which information are considered for debug or not. But it's only my opinion. So if nobody disagrees, I'd prefer going with RTE_LOG_LEVEL.