Re: [RFC PATCH net-next v1 4/4] net: page_pool: use netmem_t instead of struct page in API

On Sat, Dec 16, 2023 at 11:47 AM Shakeel Butt [off-list ref] wrote:

On Fri, Dec 15, 2023 at 7:01 PM Jakub Kicinski [off-list ref] wrote:

quoted

On Fri, 15 Dec 2023 02:11:14 +0000 Shakeel Butt wrote:

quoted

quoted

From my POV it has to be the first one. We want to abstract the memory
type from the drivers as much as possible, not introduce N new memory
types and ask the driver to implement new code for each of them
separately.

Agree with Mina's point. Let's aim to decouple memory types from
drivers.

What does "decouple" mean? Drivers should never convert netmem
to pages. Either a path in the driver can deal with netmem,
i.e. never touch the payload, or it needs pages.

I'm guessing the paths in the driver that need pages will have to be
disabled for non-paged netmem, which is fine.

One example that I ran into with GVE is that it calls page_address()
to copy small packets instead of adding them as a frag. I can add a
netmem_address() that returns page_address() for pages, and NULL for
non-pages (never passing non-pages to mm code). The driver can detect
that the netmem has no address, and disable the optimization for
non-paged netmem.

"Decouple" might not be the right word. What I wanted to say was to
avoid too much specialization such that we have to have a new API for
every new fancy thing.

quoted

Perhaps we should aim to not export netmem_to_page(),
prevent modules from accessing it directly.

+1.

This is an aggressive approach and I like it. I'll try to make it work
(should be fine).


--
Thanks,
Mina