From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) by dpdk.org (Postfix) with ESMTP id 8FAE4C2FC for ; Tue, 26 May 2015 23:47:39 +0200 (CEST) Received: by paza2 with SMTP id a2so93025079paz.3 for ; Tue, 26 May 2015 14:47:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=wkyqfHdSkfAR2SEmqbj42LfOfxZz3wGBAsn9ZZ7gBhc=; b=AU7g8xwF2yieBnUBr/4Ay4VGgP8QP2/W9SoPFjnBS7XTL76aoC08Q9bqPEADiINttd HJrsOMqD9Bbn86UGvvOR0FpL9YsdpBqMnek4TKHZLBySq8Q5hatuQd9lG0VN/FVFiLj3 hM2gRSUrTYh55QBObPoUWR5R3tToA1Y7F2XsoBroPcRBVcclq/3KK/idByne3SzpdttC SJvvLaIHFHVGD9lUb8AHvE7AKFQ3mEm9awJPM90TTg4NKYLROpZJBu8z5k9R8MTmcDcU y8x+tdhxpIaSKGgf8+TLRFknbijWnvMc4RiCuNrbxrrt99E9LmIldd2fBsFhJAJlIuyq jUeQ== X-Gm-Message-State: ALoCoQnViZPv88OZi/5tkk3NDNlZOuhw4qhIcJzPa2iwjMm3NHbUPiH3n3Mxn64+kQvFpC7Gn4QJ X-Received: by 10.69.10.196 with SMTP id ec4mr53135517pbd.69.1432676858916; Tue, 26 May 2015 14:47:38 -0700 (PDT) Received: from urahara (static-50-53-82-155.bvtn.or.frontiernet.net. [50.53.82.155]) by mx.google.com with ESMTPSA id d12sm14003904pbu.14.2015.05.26.14.47.38 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 May 2015 14:47:38 -0700 (PDT) Date: Tue, 26 May 2015 14:47:42 -0700 From: Stephen Hemminger To: "Dumitrescu, Cristian" Message-ID: <20150526144742.04debea8@urahara> In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D891263236CA70@IRSMSX108.ger.corp.intel.com> References: <1432647558-9062-1-git-send-email-maciejx.t.gajdzica@intel.com> <20150526075719.24bed9cf@urahara> <3EB4FA525960D640B5BDFFD6A3D891263236CA70@IRSMSX108.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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:47:40 -0000 On Tue, 26 May 2015 21:35:22 +0000 "Dumitrescu, Cristian" wrote: > > > > -----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_pipeline > > ports and tables > > > > On Tue, 26 May 2015 15:39:18 +0200 > > Maciej Gajdzica wrote: > > > > > +#if RTE_LOG_LEVEL == RTE_LOG_DEBUG > > > +#define RTE_PIPELINE_STATS_ADD(counter, val) \ > > > + ({ (counter) += (val); }) > > > + > > > +#define RTE_PIPELINE_STATS_ADD_M(counter, mask) \ > > > + ({ (counter) += __builtin_popcountll(mask); }) > > > +#else > > > +#define RTE_PIPELINE_STATS_ADD(counter, val) > > > +#define RTE_PIPELINE_STATS_ADD_M(counter, mask) > > > +#endif > > > > 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.html) . You say this idea is bad, but what exactly is your objection? Do you have an alternative proposal? Yes. Always keep statistics. We use functions like this internally. struct xxx_stats { uint64_t mib[XXX_MIB_MAX]; }; extern struct xxx_stats xxx_stats[RTE_MAX_LCORE]; #define XXXSTAT_INC(type) xxxstats[rte_lcore_id()].mibs[type]++ > You already mentioned in the previous thread you would like to have per lcore statistics. I was kindly asking you to describe your idea, but you did not 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 counters. Each lcore can run one or more pipeline instances, therefore each lcore typically runs several port instances of the same or different type (each port instance with its own statistics), so how is "per lcore stats" requirement applicable here? I thought you were familiar with technique of having per-cpu structures and variables widely used in Linux kernel to prevent cache thrashing. Although you call it false sharing, it isn't false., it happens when same counter ping-pongs between multiple threads for no added benefit. > 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.