From: Byungchul Park <byungchul@sk•com>
To: Jakub Kicinski <kuba@kernel•org>
Cc: linux-mm@kvack•org, netdev@vger•kernel.org,
linux-kernel@vger•kernel.org, kernel_team@skhynix•com,
harry.yoo@oracle•com, ast@kernel•org, daniel@iogearbox•net,
davem@davemloft•net, hawk@kernel•org, john.fastabend@gmail•com,
sdf@fomichev•me, saeedm@nvidia•com, leon@kernel•org,
tariqt@nvidia•com, mbloch@nvidia•com, andrew+netdev@lunn•ch,
edumazet@google•com, pabeni@redhat•com,
akpm@linux-foundation•org, david@redhat•com,
lorenzo.stoakes@oracle•com, Liam.Howlett@oracle•com,
vbabka@suse•cz, rppt@kernel•org, surenb@google•com,
mhocko@suse•com, horms@kernel•org, jackmanb@google•com,
hannes@cmpxchg•org, ziy@nvidia•com, ilias.apalodimas@linaro•org,
willy@infradead•org, brauner@kernel•org, kas@kernel•org,
yuzhao@google•com, usamaarif642@gmail•com,
baolin.wang@linux•alibaba.com, almasrymina@google•com,
toke@redhat•com, asml.silence@gmail•com, bpf@vger•kernel.org,
linux-rdma@vger•kernel.org, sfr@canb•auug.org.au, dw@davidwei•uk,
ap420073@gmail•com, dtatulea@nvidia•com
Subject: Re: [RFC mm v5 1/2] page_pool: check nmdesc->pp to see its usage as page pool for net_iov not page-backed
Date: Sat, 8 Nov 2025 11:29:04 +0900 [thread overview]
Message-ID: <20251108022904.GA1450@system.software.com> (raw)
In-Reply-To: <20251108022458.GA65163@system.software.com>
On Sat, Nov 08, 2025 at 11:24:58AM +0900, Byungchul Park wrote:
> On Fri, Nov 07, 2025 at 05:41:29PM -0800, Jakub Kicinski wrote:
> > On Fri, 7 Nov 2025 13:47:08 +0900 Byungchul Park wrote:
> > > The offset of page_type in struct page cannot be used in struct net_iov
> > > for the same purpose, since the offset in struct net_iov is for storing
> > > (struct net_iov_area *)owner.
> >
> > owner does not have to be at a fixed offset. Can we not move owner
> > to _pp_mapping_pad ? Or reorder it with type, enum net_iov_type
> > only has 2 values we can smoosh it with page_type easily.
>
> I'm still confused. I think you probably understand what this work is
> for. (I've explained several times with related links.) Or am I
^
Please don't mind. It's not a blame.
Byungchul
> missing something from your questions?
>
> I've answered your question directly since you asked, but the point is
> that, struct net_iov will no longer overlay on struct page.
>
> Instead, struct netmem_desc will be responsible for keeping the pp
> fields while struct page will lay down the resonsibility, once the pp
> fields will be removed from struct page like:
>
> <before> (the current form is:)
>
> struct page {
> memdesc_flags_t flags;
> union {
> ...
> struct {
> unsigned long pp_magic;
> struct page_pool *pp;
> unsigned long _pp_mapping_pad;
> unsigned long dma_addr;
> atomic_long_t pp_ref_count;
> };
> ...
> };
> unsigned int page_type;
> ...
> };
>
> struct net_iov {
> union {
> struct netmem_desc desc;
> struct
> {
> unsigned long _flags;
> unsigned long pp_magic;
> struct page_pool *pp;
> unsigned long _pp_mapping_pad;
> unsigned long dma_addr;
> atomic_long_t pp_ref_count;
> };
> };
> struct net_iov_area *owner;
> enum net_iov_type type;
> };
>
> <after> (the final form should be, just around the corner:)
>
> struct page {
> memdesc_flags_t flags;
> union {
> ...
> /* pp fields are gone. */
> ...
> };
> unsigned int page_type;
> ...
> };
>
> struct net_iov {
> struct netmem_desc desc;
> struct net_iov_area *owner;
> enum net_iov_type type;
> };
>
> After that, struct page and struct net_iov(or struct netmem_desc) will
> not share any fields with each other, probably they will be connected
> e.i. through some ways between struct page and netmem_desc tho.
>
> Byungchul
>
> > > Yeah, you can tell 'why don't we add the field, page_type, to struct
> > > net_iov (or struct netmem_desc)' so as to be like:
> > >
> > > struct net_iov {
> > > union {
> > > struct netmem_desc desc;
> > > struct
> > > {
> > > unsigned long _flags;
> > > unsigned long pp_magic;
> > > struct page_pool *pp;
> > > unsigned long _pp_mapping_pad;
> > > unsigned long dma_addr;
> > > atomic_long_t pp_ref_count;
> > > + unsigned int page_type; // add this field newly
> > > };
> > > };
> > > struct net_iov_area *owner; // the same offet of page_type
> > > enum net_iov_type type;
> > > };
> > >
> > > I think we can make it anyway but it makes less sense to add page_type
> > > to struct net_iov, only for PGTY_netpp.
> > >
> > > It'd be better to use netmem_desc->pp for that purpose, IMO.
next prev parent reply other threads:[~2025-11-08 2:29 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-03 7:51 [RFC mm v5 0/2] mm, page_pool: introduce a new page type for page pool in page type Byungchul Park
2025-11-03 7:51 ` [RFC mm v5 1/2] page_pool: check nmdesc->pp to see its usage as page pool for net_iov not page-backed Byungchul Park
2025-11-03 12:24 ` Toke Høiland-Jørgensen
2025-11-06 11:07 ` Pavel Begunkov
2025-11-07 1:33 ` Jakub Kicinski
2025-11-07 1:59 ` Byungchul Park
2025-11-07 2:08 ` Jakub Kicinski
2025-11-07 4:47 ` Byungchul Park
2025-11-08 1:41 ` Jakub Kicinski
2025-11-08 2:24 ` Byungchul Park
2025-11-08 2:29 ` Byungchul Park [this message]
2025-11-08 2:37 ` Jakub Kicinski
2025-11-10 1:09 ` Byungchul Park
2025-11-11 1:40 ` Byungchul Park
2025-11-11 1:56 ` Jakub Kicinski
2025-11-11 2:17 ` Byungchul Park
2025-11-11 2:45 ` Byungchul Park
2025-11-11 12:36 ` Toke Høiland-Jørgensen
2025-11-12 7:41 ` Byungchul Park
2025-11-15 1:23 ` Jakub Kicinski
2025-11-17 4:25 ` Byungchul Park
2025-11-03 7:51 ` [RFC mm v5 2/2] mm: introduce a new page type for page pool in page type Byungchul Park
2025-11-03 12:26 ` Toke Høiland-Jørgensen
2025-11-03 12:39 ` Byungchul Park
2025-11-03 14:50 ` Toke Høiland-Jørgensen
2025-11-06 11:08 ` Pavel Begunkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251108022904.GA1450@system.software.com \
--to=byungchul@sk$(echo .)com \
--cc=Liam.Howlett@oracle$(echo .)com \
--cc=akpm@linux-foundation$(echo .)org \
--cc=almasrymina@google$(echo .)com \
--cc=andrew+netdev@lunn$(echo .)ch \
--cc=ap420073@gmail$(echo .)com \
--cc=asml.silence@gmail$(echo .)com \
--cc=ast@kernel$(echo .)org \
--cc=baolin.wang@linux$(echo .)alibaba.com \
--cc=bpf@vger$(echo .)kernel.org \
--cc=brauner@kernel$(echo .)org \
--cc=daniel@iogearbox$(echo .)net \
--cc=davem@davemloft$(echo .)net \
--cc=david@redhat$(echo .)com \
--cc=dtatulea@nvidia$(echo .)com \
--cc=dw@davidwei$(echo .)uk \
--cc=edumazet@google$(echo .)com \
--cc=hannes@cmpxchg$(echo .)org \
--cc=harry.yoo@oracle$(echo .)com \
--cc=hawk@kernel$(echo .)org \
--cc=horms@kernel$(echo .)org \
--cc=ilias.apalodimas@linaro$(echo .)org \
--cc=jackmanb@google$(echo .)com \
--cc=john.fastabend@gmail$(echo .)com \
--cc=kas@kernel$(echo .)org \
--cc=kernel_team@skhynix$(echo .)com \
--cc=kuba@kernel$(echo .)org \
--cc=leon@kernel$(echo .)org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-mm@kvack$(echo .)org \
--cc=linux-rdma@vger$(echo .)kernel.org \
--cc=lorenzo.stoakes@oracle$(echo .)com \
--cc=mbloch@nvidia$(echo .)com \
--cc=mhocko@suse$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=pabeni@redhat$(echo .)com \
--cc=rppt@kernel$(echo .)org \
--cc=saeedm@nvidia$(echo .)com \
--cc=sdf@fomichev$(echo .)me \
--cc=sfr@canb$(echo .)auug.org.au \
--cc=surenb@google$(echo .)com \
--cc=tariqt@nvidia$(echo .)com \
--cc=toke@redhat$(echo .)com \
--cc=usamaarif642@gmail$(echo .)com \
--cc=vbabka@suse$(echo .)cz \
--cc=willy@infradead$(echo .)org \
--cc=yuzhao@google$(echo .)com \
--cc=ziy@nvidia$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox