[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20211108132113.5152-1-alexandr.lobakin@intel.com>
Date: Mon, 8 Nov 2021 14:21:13 +0100
From: Alexander Lobakin <alexandr.lobakin@...el.com>
To: Toke Høiland-Jørgensen <toke@...hat.com>
Cc: Alexander Lobakin <alexandr.lobakin@...el.com>,
Saeed Mahameed <saeed@...nel.org>,
Jakub Kicinski <kuba@...nel.org>,
"David S. Miller" <davem@...emloft.net>,
Jesse Brandeburg <jesse.brandeburg@...el.com>,
Lukasz Czapnik <lukasz.czapnik@...el.com>,
Marcin Kubiak <marcin.kubiak@...el.com>,
Michal Kubiak <michal.kubiak@...el.com>,
Michal Swiatkowski <michal.swiatkowski@...el.com>,
Jonathan Corbet <corbet@....net>,
Netanel Belgazal <netanel@...zon.com>,
Arthur Kiyanovski <akiyano@...zon.com>,
Guy Tzalik <gtzalik@...zon.com>,
Saeed Bishara <saeedb@...zon.com>,
Ioana Ciornei <ioana.ciornei@....com>,
Claudiu Manoil <claudiu.manoil@....com>,
Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
Marcin Wojtas <mw@...ihalf.com>,
Russell King <linux@...linux.org.uk>,
Edward Cree <ecree.xilinx@...il.com>,
Martin Habets <habetsm.xilinx@...il.com>,
"Michael S. Tsirkin" <mst@...hat.com>,
Jason Wang <jasowang@...hat.com>,
Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Jesper Dangaard Brouer <hawk@...nel.org>,
John Fastabend <john.fastabend@...il.com>,
Andrii Nakryiko <andrii@...nel.org>,
Martin KaFai Lau <kafai@...com>,
Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
KP Singh <kpsingh@...nel.org>,
Shay Agroskin <shayagr@...zon.com>,
Sameeh Jubran <sameehj@...zon.com>,
Alexander Duyck <alexanderduyck@...com>,
Danielle Ratson <danieller@...dia.com>,
Ido Schimmel <idosch@...dia.com>, Andrew Lunn <andrew@...n.ch>,
Vladyslav Tarasiuk <vladyslavt@...dia.com>,
Arnd Bergmann <arnd@...db.de>,
Andrew Morton <akpm@...ux-foundation.org>,
Jian Shen <shenjian15@...wei.com>,
Petr Vorel <petr.vorel@...il.com>, Dan Murphy <dmurphy@...com>,
Yangbo Lu <yangbo.lu@....com>,
Michal Kubecek <mkubecek@...e.cz>,
Zheng Yongjun <zhengyongjun3@...wei.com>,
Heiner Kallweit <hkallweit1@...il.com>,
YueHaibing <yuehaibing@...wei.com>,
Johannes Berg <johannes@...solutions.net>,
Maciej Fijalkowski <maciej.fijalkowski@...el.com>,
netdev@...r.kernel.org, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org,
virtualization@...ts.linux-foundation.org, bpf@...r.kernel.org
Subject: Re: [PATCH net-next 03/21] ethtool, stats: introduce standard XDP statistics
From: Toke Høiland-Jørgensen <toke@...hat.com>
Date: Mon, 08 Nov 2021 12:37:54 +0100
> Alexander Lobakin <alexandr.lobakin@...el.com> writes:
>
> > From: Alexander Lobakin <alexandr.lobakin@...el.com>
> > Date: Tue, 26 Oct 2021 11:23:23 +0200
> >
> >> From: Saeed Mahameed <saeed@...nel.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
Powered by blists - more mailing lists