Re: [dpdk-dev] [PATCH v3] pipeline: add statistics for librte_pipeline

[Rajagopalan Sivaramakrishnan <raja@juniper.net>]

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"
<cristian.dumitrescu@intel.com> 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
>> 
>> 
>> > > 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.
>> 
>> 
>> 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.
>> 
>> Raja