DPDK patches and discussions
 help / color / mirror / Atom feed
From: Rajagopalan Sivaramakrishnan <raja@juniper.net>
To: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v3] pipeline: add statistics for librte_pipeline
Date: Wed, 27 May 2015 22:44:43 +0000	[thread overview]
Message-ID: <D18B972F.4C52E%raja@juniper.net> (raw)


> > 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

             reply	other threads:[~2015-05-27 22:44 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-27 22:44 Rajagopalan Sivaramakrishnan [this message]
2015-05-28 19:26 ` Dumitrescu, Cristian
2015-05-28 19:50   ` Rajagopalan Sivaramakrishnan
2015-05-29  4:47   ` Ramia, Kannan Babu
2015-06-05 10:30   ` Thomas Monjalon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=D18B972F.4C52E%raja@juniper.net \
    --to=raja@juniper.net \
    --cc=dev@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).