netdev - Re: [Intel-wired-lan] [PATCH net-next 10/11] libie: add per-queue Page Pool stats

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <74679c26-19b1-65fc-a986-8b4a20794327@intel.com>
Date: Mon, 22 May 2023 17:32:33 +0200
From: Alexander Lobakin <aleksander.lobakin@...el.com>
To: Paul Menzel <pmenzel@...gen.mpg.de>
CC: "David S. Miller" <davem@...emloft.net>, Eric Dumazet
	<edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni
	<pabeni@...hat.com>, Jesper Dangaard Brouer <hawk@...nel.org>, Larysa Zaremba
	<larysa.zaremba@...el.com>, <netdev@...r.kernel.org>, Ilias Apalodimas
	<ilias.apalodimas@...aro.org>, <linux-kernel@...r.kernel.org>, Michal Kubiak
	<michal.kubiak@...el.com>, <intel-wired-lan@...ts.osuosl.org>, "Christoph
 Hellwig" <hch@....de>, Magnus Karlsson <magnus.karlsson@...el.com>
Subject: Re: [Intel-wired-lan] [PATCH net-next 10/11] libie: add per-queue
 Page Pool stats

From: Paul Menzel <pmenzel@...gen.mpg.de>
Date: Mon, 22 May 2023 17:05:28 +0200

> Dear Alexander,
> 
> 
> Thank you for your patch.
> 
> Am 16.05.23 um 18:18 schrieb Alexander Lobakin:
>> Expand the libie generic per-queue stats with the generic Page Pool
>> stats provided by the API itself, when CONFIG_PAGE_POOL is enable.
> 
> enable*d*

Oof, nice catch, thanks! I rely on codespell and checkpatch too much,
but from standalone-word-spelling PoV everything is fine here :s :D

> 
>> When it's not, there'll be no such fields in the stats structure, so
>> no space wasted.
>> They are also a bit special in terms of how they are obtained. One
>> &page_pool accumulates statistics until it's destroyed obviously,
>> which happens on ifdown. So, in order to not lose any statistics,
>> get the stats and store in the queue container before destroying
>> a pool. This container survives ifups/downs, so it basically stores
>> the statistics accumulated since the very first pool was allocated
>> on this queue. When it's needed to export the stats, first get the
>> numbers from this container and then add the "live" numbers -- the
>> ones that the current active pool returns. The result values will
>> always represent the actual device-lifetime* stats.
>> There's a cast from &page_pool_stats to `u64 *` in a couple functions,
>> but they are guarded with stats asserts to make sure it's safe to do.
>> FWIW it saves a lot of object code.

[...]

> Reviewed-by: Paul Menzel <pmenzel@...gen.mpg.de>
> 
> 
> Kind regards,
> 
> Paul

Thanks,
Olek