netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Guillaume Nault <gnault@redhat.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: 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>,
	David Ahern <dsahern@kernel.org>
Subject: Re: [PATCH net] bareudp: Fix device stats updates.
Date: Wed, 4 Sep 2024 19:54:40 +0200	[thread overview]
Message-ID: <Ztie4AoXc9PhLi5w@debian> (raw)
In-Reply-To: <20240904075732.697226a0@kernel.org>

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

But when vrf's dstats got moved to the core (commits
79e0c5be8c73 ("net, vrf: Move dstats structure to core") and
34d21de99cea ("net: Move {l,t,d}stats allocation to core and convert
veth & vrf")), the networking core had caught up and had also gained
support for pcpu drop counters (commit 625788b58445 ("net: add per-cpu
storage and net->core_stats")).

In this context, I feel that dstats is now just a mix of tstats and
core_stats.

> > Should we favour dev->dstats for tunnels instead of combining ->tstats
> > and ->core_stats? (vxlan uses the later for example).
> 
> Seems reasonable to me. Not important enough to convert existing
> drivers, maybe, unless someone sees contention. But in new code,
> or if we're touching the relevant lines I reckon we should consider it?

Given that we now have pcpu stats for packet drops anyway, what does
dstats bring compared to tstats?

Shouldn't we go the other way around and convert vrf to tstats and
core_stats? Then we could drop dstats entirely.

Back to bareudp, for the moment, I'd prefer to convert it to tstats
rather than dstats. The reason is that vxlan (and geneve to a lesser
extent) use tstats and I'd like to ease potential future code
consolidation between those three modules.

> No strong feelings tho, LMK if you want to send v2 or keep this patch
> as is.

I'd prefer to have this patch merged as is in -net. I have other
patches pending that have to update stats and I'd like to do that
correctly (that is, in a non-racy way) and consistently with existing
code. I feel that converting bareudp to either tstats or dstats is
something for net-next.

After -net will merge into net-next, I'll can convert bareudp to either
dstats or tstats, depending on the outcome of this conversation.


  reply	other threads:[~2024-09-04 17:54 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 [this message]
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
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=Ztie4AoXc9PhLi5w@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 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).