Lorenzo Bianconi <lorenzo.bianconi@xxxxxxxxxx> writes: >> >> >> 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? Deferring the export API to a separate series after this is merged is fine with me. In which case the *gathering* of statistics could also be deferred (it's not really useful if it can't be exported). -Toke
