> -----Original Message-----
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Stephen
> Hemminger
> Sent: Tuesday, May 26, 2015 3:57 PM
> To: Gajdzica, MaciejX T
> Cc: dev at 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 <maciejx.t.gajdzica at intel.com> 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?

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?

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.

Thanks,
Cristian

Reply via email to