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.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=almasrymina@google.com \
--cc=andrew+netdev@lunn.ch \
--cc=ap420073@gmail.com \
--cc=asml.silence@gmail.com \
--cc=ast@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=bpf@vger.kernel.org \
--cc=brauner@kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=david@redhat.com \
--cc=dtatulea@nvidia.com \
--cc=dw@davidwei.uk \
--cc=edumazet@google.com \
--cc=hannes@cmpxchg.org \
--cc=harry.yoo@oracle.com \
--cc=hawk@kernel.org \
--cc=horms@kernel.org \
--cc=ilias.apalodimas@linaro.org \
--cc=jackmanb@google.com \
--cc=john.fastabend@gmail.com \
--cc=kas@kernel.org \
--cc=kernel_team@skhynix.com \
--cc=kuba@kernel.org \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-rdma@vger.kernel.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mbloch@nvidia.com \
--cc=mhocko@suse.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=rppt@kernel.org \
--cc=saeedm@nvidia.com \
--cc=sdf@fomichev.me \
--cc=sfr@canb.auug.org.au \
--cc=surenb@google.com \
--cc=tariqt@nvidia.com \
--cc=toke@redhat.com \
--cc=usamaarif642@gmail.com \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
--cc=yuzhao@google.com \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.