On Wed, 11 Dec 2024 09:53:36 -0800 Mina Almasry wrote: > Drivers doing their own recycling is not currently supported, AFAICT. > Adding support for it in the future and maintaining it is doable, but > a headache. I also noticed with IDPF you're nacking drivers doing > their own recycling anyway, so I thought why not just declare all such > use cases as not supported to make the whole thing much simpler. > Drivers can deprecate their recycling while adding support for netmem > which brings them in line with what you're enforcing for new drivers > anyway. IIRC IDPF was doing recycling based on the old page ref tricks, without any use of page pool at all. But without using page pool the driver will never acquire a netmem_ref in the first place. > The specific reason: currently drivers will get_page pp pages to hold > on to them to do their own recycling, right? We don't even have a > get_netmem equivalent. We could add one (and for the TX path, which is > coming along, I do add one), but even then, the pp needs to detect > elevated references on net_iovs to exclude them from pp recycling. The > mp also needs to understand/keep track of elevated refcounts and make > sure the page is returned to it when the elevated refcounts from the > driver are dropped. No? It should all just work. The page may get split / fragmented by the driver or page_pool_alloc_netmem() which you're adding in this series. A fragmented net_iov will have an elevated refcount in exactly the same way as if the driver was stashing one ref to release later.
