[<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
Powered by blists - more mailing lists