netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Guillaume Nault <gnault@redhat.com>
To: Eric Dumazet <edumazet@google.com>
Cc: Jakub Kicinski <kuba@kernel.org>,
	David Miller <davem@davemloft.net>,
	Paolo Abeni <pabeni@redhat.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: Tue, 10 Sep 2024 12:28:16 +0200	[thread overview]
Message-ID: <ZuAfQFbzYchyrybw@debian> (raw)
In-Reply-To: <CANn89iJ-K82U8mSNW_NGQtzKr70weHrWiFqnBEj-ehhWRHveFg@mail.gmail.com>

On Fri, Sep 06, 2024 at 02:47:15PM +0200, Eric Dumazet wrote:
> On Fri, Sep 6, 2024 at 12:42 PM Guillaume Nault <gnault@redhat.com> wrote:
> >
> > On Wed, Sep 04, 2024 at 02:48:39PM -0700, Jakub Kicinski wrote:
> > > On Wed, 4 Sep 2024 19:54:40 +0200 Guillaume Nault wrote:
> > > > In this context, I feel that dstats is now just a mix of tstats and
> > > > core_stats.
> > >
> > > I don't know the full background but:
> > >
> > >  *    @core_stats:    core networking counters,
> > >  *                    do not use this in drivers
> >
> > Hum, I didn't realise that :/.
> >
> > I'd really like to understand why drivers shouldn't use core_stats.
> >
> > I mean, what makes driver and core networking counters so different
> > that they need to be handled in two different ways (but finally merged
> > together when exporting stats to user space)?
> >
> > Does that prevent any contention on the counters or optimise cache line
> > access? I can't see how, so I'm probably missing something important
> > here.
> 
> Some archeology might help.
> 
> Before we had tracing, having separate fields could help for diagnostics.

Interesting, I didn't think about it from a diagnostic perspective.

Considering that we now have tracing and skb_drop_reason, does it still
make sense to keep this distinction between core and driver stats?

I find this approach elegant, but since no UDP tunnel respects it and
that dstats are only used by one driver (vrf) I wonder what's the best
path forward.

I'm restricting this discussion to UDP tunnels, as I'd like them to
keep their implementation as consistent as possible (to hopefully ease
code consolidation in the future). But feel free to broaden the scope
if necessary.

I can think of two possibilities:

  1- Follow the core/driver stats policy and convert vxlan, geneve and
     bareudp to dstats (NETDEV_PCPU_STAT_DSTATS).

  2- Give up on that policy, let vxlan and geneve as is and convert
     bareudp to tstats (NETDEV_PCPU_STAT_TSTATS). Then convert vrf to
     tstats too and drop NETDEV_PCPU_STAT_DSTATS which becomes unused.

Any opinion?

> commit caf586e5f23cebb2a68cbaf288d59dbbf2d74052
> Author: Eric Dumazet <eric.dumazet@gmail.com>
> Date:   Thu Sep 30 21:06:55 2010 +0000
> 
>     net: add a core netdev->rx_dropped counter
> 
>     In various situations, a device provides a packet to our stack and we
>     drop it before it enters protocol stack :
>     - softnet backlog full (accounted in /proc/net/softnet_stat)
>     - bad vlan tag (not accounted)
>     - unknown/unregistered protocol (not accounted)
> 
>     We can handle a per-device counter of such dropped frames at core level,
>     and automatically adds it to the device provided stats (rx_dropped), so
>     that standard tools can be used (ifconfig, ip link, cat /proc/net/dev)
> 
>     This is a generalization of commit 8990f468a (net: rx_dropped
>     accounting), thus reverting it.
> 
>     Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>     Signed-off-by: David S. Miller <davem@davemloft.net>
> 


  reply	other threads:[~2024-09-10 10:28 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 [this message]
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=ZuAfQFbzYchyrybw@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).