> > > On 30/01/2024 14.52, Lorenzo Bianconi wrote: > > > On 2024/1/29 21:07, Lorenzo Bianconi wrote: > > > > > On 2024/1/28 22:20, Lorenzo Bianconi wrote: > > > > > > 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). >
Attachment:
signature.asc
Description: PGP signature
