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

Alexander Lobakin <alexandr.lobakin at intel.com> writes:
> From: Toke H?iland-J?rgensen <toke at redhat.com>
> Date: Mon, 08 Nov 2021 12:37:54 +0100
>
>> Alexander Lobakin <alexandr.lobakin at intel.com> writes:
>> 
>> > From: Alexander Lobakin <alexandr.lobakin at intel.com>
>> > Date: Tue, 26 Oct 2021 11:23:23 +0200
>> >
>> >> From: Saeed Mahameed <saeed at kernel.org>
>> >> 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".
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...
>> 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