From: Guillaume Nault <gnault@redhat.com>
To: David Ahern <dsahern@kernel.org>
Cc: Jakub Kicinski <kuba@kernel.org>,
David Miller <davem@davemloft.net>,
Paolo Abeni <pabeni@redhat.com>,
Eric Dumazet <edumazet@google.com>,
netdev@vger.kernel.org,
Martin Varghese <martin.varghese@nokia.com>,
Willem de Bruijn <willemb@google.com>
Subject: Re: [PATCH net] bareudp: Fix device stats updates.
Date: Fri, 6 Sep 2024 12:30:27 +0200 [thread overview]
Message-ID: <ZtrZw8UdMXAJT5GR@debian> (raw)
In-Reply-To: <3aaa7117-ded8-4d3d-acdc-82a1e9fb73b8@kernel.org>
On Wed, Sep 04, 2024 at 07:50:55PM -0600, David Ahern wrote:
> On 9/4/24 11:54 AM, Guillaume Nault wrote:
> > [Adding David Ahern for the vrf/dstats discussion]
> >
> > On Wed, Sep 04, 2024 at 07:57:32AM -0700, Jakub Kicinski wrote:
> >> On Wed, 4 Sep 2024 14:29:44 +0200 Guillaume Nault wrote:
> >>>> The driver already uses struct pcpu_sw_netstats, would it make sense to
> >>>> bump it up to struct pcpu_dstats and have per CPU rx drops as well?
> >>>
> >>> Long term, I was considering moving bareudp to use dev->tstats for
> >>> packets/bytes and dev->core_stats for drops. It looks like dev->dstats
> >>> is only used for VRF, so I didn't consider it.
> >>
> >> Right, d stands for dummy so I guess they also were used by dummy
> >> at some stage? Mostly I think it's a matter of the other stats being
> >> less recent.
> >
> > Looks like dummy had its own dstats, yes. But those dstats were really
> > like the current lstats (packets and bytes counters, nothing for
> > drops). Dummy was later converted to lstats by commit 4a43b1f96b1d
> > ("net: dummy: use standard dev_lstats_add() and dev_lstats_read()").
> >
> > The dstats we have now really come from vrf (different counters for tx
> > and rx and counters for packet drops), which had its own implementation
> > at that time.
> >
> > My understanding is that vrf implemented its own dstats in order to
> > have per-cpu counters for regular bytes/packets counters and also for
> > packet drops.
>
> VRF was following other per-cpu counters that existed in 2015-2016
> timeframe.
Thanks. That was my impression as well.
> I have no preference on the naming; just wanted per-cpu counters.
>
next prev parent reply other threads:[~2024-09-06 10:30 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-30 15:31 [PATCH net] bareudp: Fix device stats updates Guillaume Nault
2024-08-31 14:56 ` Willem de Bruijn
2024-09-03 18:34 ` Jakub Kicinski
2024-09-04 12:29 ` Guillaume Nault
2024-09-04 14:57 ` Jakub Kicinski
2024-09-04 17:54 ` Guillaume Nault
2024-09-04 21:48 ` Jakub Kicinski
2024-09-06 10:42 ` Guillaume Nault
2024-09-06 12:47 ` Eric Dumazet
2024-09-10 10:28 ` Guillaume Nault
2024-09-05 1:50 ` David Ahern
2024-09-06 10:30 ` Guillaume Nault [this message]
2024-09-04 22:10 ` patchwork-bot+netdevbpf
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=ZtrZw8UdMXAJT5GR@debian \
--to=gnault@redhat.com \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=martin.varghese@nokia.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=willemb@google.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.