[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87v912ri7h.fsf@toke.dk>
Date: Mon, 08 Nov 2021 12:37:54 +0100
From: Toke Høiland-Jørgensen <toke@...hat.com>
To: Alexander Lobakin <alexandr.lobakin@...el.com>,
Saeed Mahameed <saeed@...nel.org>
Cc: Alexander Lobakin <alexandr.lobakin@...el.com>,
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
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".
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...
-Toke
Powered by blists - more mailing lists