On Tue, Jul 01, 2025 at 04:45:08PM -0700, Jakub Kicinski wrote: > On Mon, 30 Jun 2025 08:34:48 +0900 Harry Yoo wrote: > > > Ugh, you keep explaining the mechanics to me. Our goal here is not > > > just to move fields around and make it still compile :/ > > > > > > Let me ask you this way: you said "netmem_desc" will be allocated > > > thru slab "shortly". How will calling the equivalent of page_address() > > > on netmem_desc work at that stage? Feel free to refer me to the existing > > > docs if its covered.. > > > > https://kernelnewbies.org/MatthewWilcox/Memdescs/Path > > https://kernelnewbies.org/MatthewWilcox/Memdescs > > > > May not be the exact document you're looking for, > > but with this article I can imagine: > > > > - The ultimate goal is to shrink struct page to eventually from 64 bytes > > to 8 bytes, by allocating only the minimum required metadata per 4k page > > statically and moving the rest of metadata to dynamically-allocated > > descriptors (netmem_desc, anon, file, ptdesc, zpdesc, etc.) using slab > > at page allocation time. > > > > - We can't achieve that goal just yet, because several subsystems > > still use struct page fields for their own purposes. > > > > To achieve that, each of these subsystems needs to define > > its own descriptor, which, for now, overlays struct page, and should be > > converted to use the new descriptor. > > > > Eventually, these descriptors will be allocated using slab. > > > > - For CPU-readable buffers, page->memdesc will point to a netmem_desc, > > with a lower bit set indicating that it's a netmem_desc rather than > > other type. Networking code will need to cast it to (netmem_desc *) > > and dereference it to access networking specific fields. > > > > - The struct page array (vmemmap) will still be statically allocated > > at boot time (or during memory hotplug time). > > So no change in how page_address() works. > > > > net_iovs will continue to be not associated with struct pages, > > as the buffers don't have corresponding struct pages. > > net_iovs are already allocated using slab. > > Thanks a lot, this clarifies things for me. > > Unfortunately, I still think that it's hard to judge patches 1 and 7 > in context limited to this series, so let's proceed to reposting just > the "middle 5" patches. Just in case, I sent v8 with the "middle 5" last week as you requested. I'm convinced they are non-controversial but lemme know if any. Byungchul
