From: Jamal Hadi Salim <jhs@mojatatu.com>
To: Eric Dumazet <eric.dumazet@gmail.com>,
Cong Wang <xiyou.wangcong@gmail.com>
Cc: netdev <netdev@vger.kernel.org>,
John Fastabend <john.fastabend@gmail.com>,
Kevin Athey <kda@google.com>, Xiaotian Pei <xiaotian@google.com>
Subject: Re: [RFC net-next] net: sched: do not acquire qdisc spinlock in qdisc/class stats dump
Date: Sun, 22 May 2016 12:35:07 -0400 [thread overview]
Message-ID: <5741DFBB.8040003@mojatatu.com> (raw)
In-Reply-To: <1463723432.18194.274.camel@edumazet-glaptop3.roam.corp.google.com>
On 16-05-20 01:50 AM, Eric Dumazet wrote:
> It wont be inaccurate (no drift), as the writers hold the qdisc
> spinlock.
>
> It it the same with say IP/TCP SNMP counters :
>
> When an incoming frame is handled, it might change many SNMP counters,
> but an SNMP agent might fetch the whole set of SNMP values in the middle
> of the changes.
>
> IpInReceives
> IpInDelivers
> TcpInSegs
> IpExtInOctets
> IpExtInNoECTPkts
> ...
>
> The only 'problem' can be a off-by-one (or off-by-bytes-in-the-packet)
> transient error, that all SNMP agents are normally handling just fine.
>
I think qdisc stats being off by a bit are ok - hence the rcu
suggestion. I would have problems with action stats being off
(where they are used for billing).
cheers,
jamal
next prev parent reply other threads:[~2016-05-22 16:47 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-19 12:35 [RFC net-next] net: sched: do not acquire qdisc spinlock in qdisc/class stats dump Eric Dumazet
2016-05-19 16:08 ` Alexei Starovoitov
2016-05-19 17:02 ` Eric Dumazet
2016-05-20 1:50 ` Cong Wang
2016-05-20 2:45 ` Eric Dumazet
2016-05-20 5:23 ` Cong Wang
2016-05-20 5:50 ` Eric Dumazet
2016-05-22 16:35 ` Jamal Hadi Salim [this message]
2016-05-20 12:44 ` Eric Dumazet
2016-05-20 13:01 ` Eric Dumazet
2016-05-20 13:09 ` Eric Dumazet
2016-05-20 23:38 ` David Miller
2016-05-22 16:30 ` Jamal Hadi Salim
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=5741DFBB.8040003@mojatatu.com \
--to=jhs@mojatatu.com \
--cc=eric.dumazet@gmail.com \
--cc=john.fastabend@gmail.com \
--cc=kda@google.com \
--cc=netdev@vger.kernel.org \
--cc=xiaotian@google.com \
--cc=xiyou.wangcong@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.