From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH v4] doc: guidelines for library statistics Date: Thu, 18 Jun 2015 17:12:21 +0200 Message-ID: <3520895.7kc6tpDi1L@xps13> References: <98CBD80474FA8B44BF855DF32C47DC358AF171@smartserver.smartshare.dk> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: Morten =?ISO-8859-1?Q?Br=F8rup?= To: dev@dpdk.org Return-path: Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) by dpdk.org (Postfix) with ESMTP id 126E3C42A for ; Thu, 18 Jun 2015 17:13:24 +0200 (CEST) Received: by wgfq1 with SMTP id q1so19840366wgf.1 for ; Thu, 18 Jun 2015 08:13:24 -0700 (PDT) In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC358AF171@smartserver.smartshare.dk> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" We need a conclusion here. It seems the policy proposed by Cristian is the best consensus. If nobody nack in this thread with a counter-proposal, it will be adopted on Monday. 2015-06-18 16:38, Morten Br=F8rup: > The suggested solution with only one single flag per library prevents= > implementing statistics with varying granularity for different purpos= es. > E.g. a library could have one set of statistics counters for ordinary= > SNMP purposes, and another set of statistics counters for > debugging/optimization purposes. It would be difficult to sort a statistic in a category or another. By the way, it's often better to add its own stats for debugging/optim.= > Multiple flags per library should be possible. A hierarchy of flags p= er > library is probably not required. > And since the compile time flag > CONFIG_RTE_[_]_STATS_COLLECT alr= eady > tells the application if the statistics are present or not, the appli= cation > should simply use this flag to determine if statistics are accessible= or not. Yes