From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 8DEE258D8 for ; Tue, 26 May 2015 23:35:25 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 26 May 2015 14:35:24 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,501,1427785200"; d="scan'208";a="700592630" Received: from irsmsx153.ger.corp.intel.com ([163.33.192.75]) by orsmga001.jf.intel.com with ESMTP; 26 May 2015 14:35:23 -0700 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.59]) by IRSMSX153.ger.corp.intel.com ([169.254.9.95]) with mapi id 14.03.0224.002; Tue, 26 May 2015 22:35:22 +0100 From: "Dumitrescu, Cristian" To: Stephen Hemminger , "Gajdzica, MaciejX T" Thread-Topic: [dpdk-dev] [PATCH v3] pipeline: add statistics for librte_pipeline ports and tables Thread-Index: AQHQl8RXd7p4Z3r9hEW+IUJr9z/taZ2Ovb8Q Date: Tue, 26 May 2015 21:35:22 +0000 Message-ID: <3EB4FA525960D640B5BDFFD6A3D891263236CA70@IRSMSX108.ger.corp.intel.com> References: <1432647558-9062-1-git-send-email-maciejx.t.gajdzica@intel.com> <20150526075719.24bed9cf@urahara> In-Reply-To: <20150526075719.24bed9cf@urahara> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v3] 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: Tue, 26 May 2015 21:35:26 -0000 > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Stephen > Hemminger > Sent: Tuesday, May 26, 2015 3:57 PM > To: Gajdzica, MaciejX T > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v3] pipeline: add statistics for librte_pi= peline > ports and tables >=20 > On Tue, 26 May 2015 15:39:18 +0200 > Maciej Gajdzica wrote: >=20 > > +#if RTE_LOG_LEVEL =3D=3D RTE_LOG_DEBUG > > +#define RTE_PIPELINE_STATS_ADD(counter, val) \ > > + ({ (counter) +=3D (val); }) > > + > > +#define RTE_PIPELINE_STATS_ADD_M(counter, mask) \ > > + ({ (counter) +=3D __builtin_popcountll(mask); }) > > +#else > > +#define RTE_PIPELINE_STATS_ADD(counter, val) > > +#define RTE_PIPELINE_STATS_ADD_M(counter, mask) > > +#endif >=20 > This is worse idea than the previous one. > I want statistics done on a per lcore basis, and always available > because real users on production system want statistics (but they > don't want log spam). Stephen, Thomas and myself converged towards this solution, Thomas asked if anybody = objects, you did not (http://www.dpdk.org/ml/archives/dev/2015-May/018099.h= tml) . You say this idea is bad, but what exactly is your objection? Do you= have an alternative proposal? You already mentioned in the previous thread you would like to have per lco= re statistics. I was kindly asking you to describe your idea, but you did n= ot do this yet (http://www.dpdk.org/ml/archives/dev/2015-May/017956.html ).= Can you please describe it? Each port instance has its own statistics coun= ters. Each lcore can run one or more pipeline instances, therefore each lco= re typically runs several port instances of the same or different type (eac= h port instance with its own statistics), so how is "per lcore stats" requi= rement applicable here? You also reiterate that you would like to have the stats always enabled. Yo= u can definitely do this, it is one of the available choices, but why not a= lso accommodate the users that want to pick the opposite choice? Why force = apps to spend cycles on stats if the app either does not want these counter= s (library counters not relevant for that app, maybe the app is only intere= sted in maintaining some other stats that it implements itself) or do not w= ant them anymore (maybe they only needed them during debug phase), etc? Jay= asked this question, and I did my best in my reply to describe our motivat= ion (http://www.dpdk.org/ml/archives/dev/2015-May/017992.html). Maybe you m= issed that post, it would be good to get your reply on this one too. Thanks, Cristian