Re: [PATCH net-next v3 5/5] net: Document memory provider driver support

[Jakub Kicinski]

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.