On 30/01/2024 14.52, Lorenzo Bianconi wrote:

quoted

quoted

On 2024/1/29 21:07, Lorenzo Bianconi wrote:

quoted

quoted

On 2024/1/28 22:20, Lorenzo Bianconi wrote:

quoted

Move page_pool stats allocation in page_pool_create routine and get rid
of it for percpu page_pools.

Is there any reason why we do not need those kind stats for per cpu
page_pool?

IIRC discussing with Jakub, we decided to not support them since the pool is not
associated to any net_device in this case.

It seems what jakub suggested is to 'extend netlink to dump unbound page pools'?

I do not have a strong opinion about it (since we do not have any use-case for
it at the moment).
In the case we want to support stats for per-cpu page_pools, I think we should
not create a per-cpu recycle_stats pointer and add a page_pool_recycle_stats field
in page_pool struct since otherwise we will endup with ncpu^2 copies, right?
Do we want to support it now?

@Jakub, Jesper: what do you guys think?

I do see an need for being able to access page_pool stats for all
page_pool's in the system.
And I do like Jakub's netlink based stats.

ack from my side if you have some use-cases in mind.
Some questions below:
- can we assume ethtool will be used to report stats just for 'global'
  page_pool (not per-cpu page_pool)?
- can we assume netlink/yaml will be used to report per-cpu page_pool stats?

I think in the current series we can fix the accounting part (in particular
avoiding memory wasting) and then we will figure out how to report percpu
page_pool stats through netlink/yaml. Agree?

Regards,
Lorenzo

--Jesper
(p.s. I'm debugging some production issues with page_pool and broadcom
bnxt_en driver).