From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bbn0105.outbound.protection.outlook.com [157.56.111.105]) by dpdk.org (Postfix) with ESMTP id 382634A63 for ; Thu, 28 May 2015 00:44:46 +0200 (CEST) Received: from BLUPR05MB1875.namprd05.prod.outlook.com (25.162.215.149) by BLUPR05MB136.namprd05.prod.outlook.com (10.255.190.143) with Microsoft SMTP Server (TLS) id 15.1.172.22; Wed, 27 May 2015 22:44:45 +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; Wed, 27 May 2015 22:44:44 +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; Wed, 27 May 2015 22:44:44 +0000 From: Rajagopalan Sivaramakrishnan To: "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH v3] pipeline: add statistics for librte_pipeline Thread-Index: AQHQmM652FttWDxm/02UWehTOpnofQ== Date: Wed, 27 May 2015 22:44:43 +0000 Message-ID: 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:BLUPR05MB136; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520003)(3002001); SRVR:BLUPR05MB1875; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB1875; x-forefront-prvs: 05891FB07F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(51704005)(189002)(189998001)(110136002)(86362001)(107886002)(16236675004)(46102003)(19580395003)(64706001)(83506001)(101416001)(4001350100001)(54356999)(5001830100001)(5001960100002)(97736004)(5001860100001)(4001540100001)(50986999)(81156007)(19617315012)(87936001)(2656002)(2501003)(2351001)(106356001)(77156002)(122556002)(66066001)(15975445007)(450100001)(105586002)(102836002)(62966003)(2900100001)(99286002)(92566002)(36756003)(68736005)(106116001)(40100003)(5002640100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB1875; H:BLUPR05MB1874.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 May 2015 22:44:43.6296 (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 09:27:51 +0200 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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: Wed, 27 May 2015 22:44:46 -0000 > > 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 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 count= ers > (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 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 on= e > too. > > I want to see DPDK get out of the config madness. > This is real code, not an Intel benchmark special. I agree that statistics will definitely be required in most real-world prod= uction environments and the overhead from per-core stats gathering will be minimal if the data structures are su= ch 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 comprom= ise. Raja