On Tue, Dec 10, 2024 at 7:55 PM Jakub Kicinski <kuba@xxxxxxxxxx> wrote: > > On Mon, 9 Dec 2024 17:23:08 +0000 Mina Almasry wrote: > > +================ > > +Memory providers > > +================ > > + > > + > > +Intro > > +===== > > + > > +Device memory TCP, and likely more upcoming features, are reliant in memory > > +provider support in the driver. > > Are "memory providers" something driver authors care about? > I'd go with netmem naming in all driver facing APIs. > Or perhaps say placing data into unreable buffers? > Sure, I can center the docs around netmem rather than 'memory providers'. > > +Driver support > > +============== > > + > > +1. The driver must support page_pool. The driver must not do its own recycling > > + on top of page_pool. > > I like the rule, but is there a specific reason driver can't do its own > recycling? > 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. 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. -- Thanks, Mina
