[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5653e19f-75fa-9a94-4b45-0cf110fd6e36@redhat.com>
Date: Thu, 12 Aug 2021 14:19:30 +0200
From: Jesper Dangaard Brouer <jbrouer@...hat.com>
To: Jakub Kicinski <kuba@...nel.org>, David Ahern <dsahern@...il.com>,
"Karlsson, Magnus" <magnus.karlsson@...el.com>
Cc: brouer@...hat.com, Saeed Mahameed <saeed@...nel.org>,
Alexander Lobakin <alexandr.lobakin@...el.com>,
"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>,
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
On 04/08/2021 18.44, Jakub Kicinski wrote:
> On Wed, 4 Aug 2021 10:17:56 -0600 David Ahern wrote:
>> On 8/4/21 6:36 AM, Jakub Kicinski wrote:
>
>> Does anyone have data that shows bumping a properly implemented counter
>> causes a noticeable performance degradation and if so by how much? You
>> mention 'yet another cacheline' but collecting stats on stack and
>> incrementing the driver structs at the end of the napi loop should not
>> have a huge impact versus the value the stats provide.
>
> Not sure, maybe Jesper has some numbers. Maybe Intel folks do?
(sorry, behind on emails after vacation ... just partly answering inside
this thread, not checking if you did a smart counter impl.).
I don't have exact numbers, but I hope Magnus (Intel) would be motivated
to validate performance degradation from this patchset. As I know Intel
is hunting the DPDK numbers with AF_XDP-zc, where every last cycle *do*
count.
My experience is that counters can easily hurt performance, without the
developers noticing the small degradation's. As Ahern sketch out above
(stats on stack + end of napi loop update), I do believe that a smart
counter implementation is possible to hide this overhead (hopefully
completely in the CPUs pipeline slots).
I do highly appreciate the effort to standardize the XDP stats!
So, I do hope this can somehow move forward.
--Jesper
Powered by blists - more mailing lists