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
