lkml.org 
[lkml]   [2021]   [Nov]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH net-next 03/21] ethtool, stats: introduce standard XDP statistics
Date
From: Toke Høiland-Jørgensen <toke@redhat.com>
Date: Mon, 08 Nov 2021 12:37:54 +0100

> Alexander Lobakin <alexandr.lobakin@intel.com> writes:
>
> > From: Alexander Lobakin <alexandr.lobakin@intel.com>
> > Date: Tue, 26 Oct 2021 11:23:23 +0200
> >
> >> From: Saeed Mahameed <saeed@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".

> 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

\
 
 \ /
  Last update: 2021-11-08 14:22    [W:0.589 / U:1.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site