On Mon, Nov 11, 2024 at 1:15 PM David Wei <dw@xxxxxxxxxxx> wrote: > > Is it very complicated to napi_pp_put_page() niovs as the user puts > > them in the refill queue without adding a new syscall? If so, is it > > possible to do a niov equivalent of page_pool_put_page_bulk() of the > > refill queue while/as you process the RX path? > > > > If you've tested the generic code paths to be performance deficient > > and your recycling is indeed better, you could improve the page_pool > > to pull netmems when it needs to like you're doing here, but in a > > generic way that applies to the page allocator and other providers. > > Not a one-off implementation that only applies to your provider. > > > > If you're absolutely set on ignoring the currently supported reffing > > and implementing your own reffing and recycling for your use case, > > sure, that could work, but please don't overload the > > niov->pp_ref_count reserved for the generic use cases for this. Add > > io_zcrx_area->io_uring_ref or something and do whatever you want with > > it. Since it's not sharing the pp_ref_count with the generic code > > paths I don't see them conflicting in the future. > > Why insist on this? Both page/niov and devmem/io_uring niov are mutually > exclusive. There is no strong technical reason to not re-use > pp_ref_count. > Conflict between devmem (specifically) and io_uring is not my concern. My concern is possible future conflict between io_uring refcounting and page/devmem refcounting. Currently net_iov refcounting and page refcounting is unified (as much as possible). net_iov->pp_ref_count is an exact mirror in usage of page->pp_ref_count and the intention is for it to remain so. This patch reuses net_iov->pp_ref_count in a way that doesn't really apply to page->pp_ref_count and already some deviation in use case is happening which may lead to conflicting requirements in the future (and to be fair, may not). But I've been bringing this up a lot in the past (and offering alternatives that don't introduce this overloading) and I think this conversation has run its course. I'm unsure about this approach and this could use another pair of eyes. Jakub, sorry to bother you but you probably are the one that reviewed the whole net_iov stuff most closely. Any chance you would take a look and provide direction here? Maybe my concern is overblown... -- Thanks, Mina
