Re: [RFC] shrinking struct page (part of page pool)

[Byungchul Park <byungchul@sk.com>]

On Mon, Apr 14, 2025 at 04:30:02PM -0700, Jakub Kicinski wrote:
> On Mon, 14 Apr 2025 10:52:07 +0900 Byungchul Park wrote:
> > > Fortunately, many prerequisite works have been done by Mina but I guess
> > > he or she has done it for other purpose than 'shrinking struct page'.
> > > 
> > > I'd like to just finalize the work so that the fields above can be
> > > removed from struct page.  However, I need to resolve a curiousity
> > > before starting.
> 
> I don't understand what the question is but FWIW from my perspective
> the ZC APIs are fairly contained, or at least we tried to make sure
> that net_iov pages cannot reach random parts of the stack.
> 
> Replacing all uses of struct page would require converting much more
> of the stack, AFAIU. But that's best discussed over posted patches.

Okay.  Let's discuss it once posting patches.

> > >    Network guys already introduced a sperate strcut, struct net_iov,
> > >    to overlay the interesting fields.  However, another separate struct
> > >    for system memory might be also needed e.g. struct bump so that
> > >    struct net_iov and struct bump can be overlayed depending on the
> > >    source:
> > > 
> > >    struct bump {
> > > 	unsigned long _page_flags;
> > > 	unsigned long bump_magic;
> > > 	struct page_pool *bump_pp;
> > > 	unsigned long _pp_mapping_pad;
> > > 	unsigned long dma_addr;
> > > 	atomic_long_t bump_ref_count;
> > > 	unsigned int _page_type;
> > > 	atomic_t _refcount;
> > >    };
> > > 
> > > To netwrok guys, any thoughts on it?
> > > To Willy, do I understand correctly your direction?
> > > 
> > > Plus, it's a quite another issue but I'm curious, that is, what do you
> > > guys think about moving the bump allocator(= page pool) code from
> > > network to mm?  I'd like to start on the work once gathering opinion
> > > from both Willy and network guys.
> 
> I don't see any benefit from moving page pool to MM. It is quite
> networking specific. But we can discuss this later. Moving code
> is trivial, it should not be the initial focus.

I think so.

	Byungchul