On Sat, Dec 16, 2023 at 11:47 AM Shakeel Butt <shakeelb@xxxxxxxxxx> wrote: > > On Fri, Dec 15, 2023 at 7:01 PM Jakub Kicinski <kuba@xxxxxxxxxx> wrote: > > > > On Fri, 15 Dec 2023 02:11:14 +0000 Shakeel Butt wrote: > > > > 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. > > > > > 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
