Re: [PATCH net-next 03/21] ethtool, stats: introduce standard XDP statistics

From: Alexander Lobakin
Date: Mon Nov 08 2021 - 08:21:54 EST


From: Toke Høiland-Jørgensen <toke@xxxxxxxxxx>
Date: Mon, 08 Nov 2021 12:37:54 +0100

> Alexander Lobakin <alexandr.lobakin@xxxxxxxxx> writes:
>
> > From: Alexander Lobakin <alexandr.lobakin@xxxxxxxxx>
> > Date: Tue, 26 Oct 2021 11:23:23 +0200
> >
> >> From: Saeed Mahameed <saeed@xxxxxxxxxx>
> >> Date: Tue, 03 Aug 2021 16:57:22 -0700
> >>
> >> [ snip ]
> >>
> >> > XDP is going to always be eBPF based ! why not just report such stats
> >> > to a special BPF_MAP ? BPF stack can collect the stats from the driver
> >> > and report them to this special MAP upon user request.
> >>
> >> I really dig this idea now. How do you see it?
> >> <ifindex:channel:stat_id> as a key and its value as a value or ...?
> >
> > Ideas, suggestions, anyone?
>
> I don't like the idea of putting statistics in a map instead of the
> regular statistics counters. Sure, for bespoke things people want to put
> into their XDP programs, use a map, but for regular packet/byte
> counters, update the regular counters so XDP isn't "invisible".

I wanted to provide an `ip link` command for getting these stats
from maps and printing them in a usual format as well, but seems
like that's an unneeded overcomplication of things since using
maps for "regular"/"generic" XDP stats really has no reason except
for "XDP means eBPF means maps".

> As Jesper pointed out, batching the updates so the global counters are
> only updated once per NAPI cycle is the way to avoid a huge performance
> overhead of this...

That's how I do things currently, seems to work just fine.

> -Toke

Thanks,
Al