From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rajagopalan Sivaramakrishnan Subject: Re: [PATCH v3] pipeline: add statistics for librte_pipeline Date: Wed, 27 May 2015 22:44:43 +0000 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To: "dev@dpdk.org" 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) Content-Language: en-US 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" > > 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