From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0116.outbound.protection.outlook.com [65.55.169.116]) by dpdk.org (Postfix) with ESMTP id 228FEC390 for ; Thu, 28 May 2015 21:50:20 +0200 (CEST) Received: from BLUPR05MB1875.namprd05.prod.outlook.com (25.162.215.149) by BLUPR05MB182.namprd05.prod.outlook.com (10.255.190.142) with Microsoft SMTP Server (TLS) id 15.1.172.22; Thu, 28 May 2015 19:50:19 +0000 Received: from BLUPR05MB1874.namprd05.prod.outlook.com (25.162.215.148) by BLUPR05MB1875.namprd05.prod.outlook.com (25.162.215.149) with Microsoft SMTP Server (TLS) id 15.1.172.22; Thu, 28 May 2015 19:50:18 +0000 Received: from BLUPR05MB1874.namprd05.prod.outlook.com ([25.162.215.148]) by BLUPR05MB1874.namprd05.prod.outlook.com ([25.162.215.148]) with mapi id 15.01.0172.012; Thu, 28 May 2015 19:50:17 +0000 From: Rajagopalan Sivaramakrishnan To: "Dumitrescu, Cristian" , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH v3] pipeline: add statistics for librte_pipeline Thread-Index: AQHQmM652FttWDxm/02UWehTOpnofZ2RxAew//+UXwA= Date: Thu, 28 May 2015 19:50:17 +0000 Message-ID: References: <3EB4FA525960D640B5BDFFD6A3D891263236E6CA@IRSMSX108.ger.corp.intel.com> In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D891263236E6CA@IRSMSX108.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.0.150423 authentication-results: spf=none (sender IP is ) smtp.mailfrom=raja@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.12] x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB1875; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB182; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:BLUPR05MB1875; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB1875; x-forefront-prvs: 0590BBCCBC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(51704005)(189002)(24454002)(13464003)(199003)(377454003)(102836002)(1720100001)(77156002)(105586002)(106356001)(2656002)(2501003)(87936001)(68736005)(40100003)(2950100001)(66066001)(106116001)(5002640100001)(99286002)(36756003)(122556002)(2900100001)(92566002)(15975445007)(62966003)(46102003)(19580395003)(19580405001)(83506001)(64706001)(189998001)(86362001)(5001770100001)(4001540100001)(5001860100001)(97736004)(81156007)(54356999)(76176999)(101416001)(5001830100001)(5001960100002)(50986999)(4001350100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB1875; H:BLUPR05MB1874.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-ID: <6FA727828278F7408EA952FBF34819E2@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2015 19:50:17.3073 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB1875 X-OriginatorOrg: juniper.net X-Mailman-Approved-At: Thu, 28 May 2015 23:27:52 +0200 Subject: Re: [dpdk-dev] [PATCH v3] pipeline: add statistics for librte_pipeline 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: Thu, 28 May 2015 19:50:20 -0000 My first preference would be to enable stats always. However, if the majority feels that it should be optional, your preference of 3, 2, 1 seems fine to me. I hope the same decision will apply to port/table/other stats. Raja On 5/28/15, 12:26 PM, "Dumitrescu, Cristian" wrote: >Hi Raja, > >Thanks for your input. > >I think we have the following options identified so far for stats >collection configuration: > >1. Stats configuration through the RTE_LOG_LEVEL >2. Single configuration flag global for all DPDK libraries >3. Single configuration flag per DPDK library > >It would be good if Thomas and Stephen, as well as others, would reply >with their preference order. > >My personal preference order is: 3., 2., 1., but I can work with any of >the above that is identified by the majority of the replies. My goal >right now is reaching a conclusion on this item as soon as we can. > >Regards, >Cristian > > > >> -----Original Message----- >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Rajagopalan >> Sivaramakrishnan >> Sent: Wednesday, May 27, 2015 11:45 PM >> To: dev@dpdk.org >> Subject: Re: [dpdk-dev] [PATCH v3] pipeline: add statistics for >>librte_pipeline >>=20 >>=20 >> > > You also reiterate that you would like to have the stats always >>enabled. >> You >> > can definitely do this, it is one of the available choices, but why >>not also >> > 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 >> counters >> > (library counters not relevant for that app, maybe the app is only >> interested >> > in maintaining some other stats that it implements itself) or do not >>want >> > 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 >> > motivation (http://www.dpdk.org/ml/archives/dev/2015- >> May/017992.html). >> > Maybe you missed that post, it would be good to get your reply on >>this one >> > too. >> > >> > I want to see DPDK get out of the config madness. >> > This is real code, not an Intel benchmark special. >>=20 >>=20 >> I agree that statistics will definitely be required in most real-world >>production >> environments and the overhead >> from per-core stats gathering will be minimal if the data structures >>are such >> that CPU cache thrashing is avoided. >> However, if there are scenarios where it is desirable to turn stats >>off, I think >> we can live with a config option. >> I am not comfortable with using the log level to enable/disable >>statistics as >> they are not really related. A >> separate config option for stats collection seems like a reasonable >> compromise. >>=20 >> Raja