Alexander Lobakin [off-list ref] writes:

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

quoted

Alexander Lobakin [off-list ref] writes:

quoted

From: Alexander Lobakin <redacted>
Date: Tue, 26 Oct 2021 11:23:23 +0200

quoted

From: Saeed Mahameed <saeed@kernel.org>
Date: Tue, 03 Aug 2021 16:57:22 -0700

[ snip ]

quoted

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

Yeah, don't really see why it would have to: to me, one of the benefits
of XDP is being integrated closely with the kernel so we can have a
"fast path" *without* reinventing everything...

quoted

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.

Awesome!

-Toke