lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250624011744.GA5820@system.software.com>
Date: Tue, 24 Jun 2025 10:17:44 +0900
From: Byungchul Park <byungchul@...com>
To: Mina Almasry <almasrymina@...gle.com>
Cc: Harry Yoo <harry.yoo@...cle.com>, David Hildenbrand <david@...hat.com>,
	willy@...radead.org, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	kernel_team@...ynix.com, kuba@...nel.org,
	ilias.apalodimas@...aro.org, hawk@...nel.org,
	akpm@...ux-foundation.org, davem@...emloft.net,
	john.fastabend@...il.com, andrew+netdev@...n.ch,
	asml.silence@...il.com, toke@...hat.com, tariqt@...dia.com,
	edumazet@...gle.com, pabeni@...hat.com, saeedm@...dia.com,
	leon@...nel.org, ast@...nel.org, daniel@...earbox.net,
	lorenzo.stoakes@...cle.com, Liam.Howlett@...cle.com, vbabka@...e.cz,
	rppt@...nel.org, surenb@...gle.com, mhocko@...e.com,
	horms@...nel.org, linux-rdma@...r.kernel.org, bpf@...r.kernel.org,
	vishal.moola@...il.com, hannes@...xchg.org, ziy@...dia.com,
	jackmanb@...gle.com
Subject: Re: [PATCH net-next v6 1/9] netmem: introduce struct netmem_desc
 mirroring struct page

On Mon, Jun 23, 2025 at 12:09:09PM -0700, Mina Almasry wrote:
> On Mon, Jun 23, 2025 at 5:18 AM Harry Yoo <harry.yoo@...cle.com> wrote:
> > On Mon, Jun 23, 2025 at 07:28:21PM +0900, Byungchul Park wrote:
> > > On Mon, Jun 23, 2025 at 11:32:16AM +0200, David Hildenbrand wrote:
> > > > On 20.06.25 06:12, Byungchul Park wrote:
> > > > > To simplify struct page, the page pool members of struct page should be
> > > > > moved to other, allowing these members to be removed from struct page.
> > > > >
> > > > > Introduce a network memory descriptor to store the members, struct
> > > > > netmem_desc, and make it union'ed with the existing fields in struct
> > > > > net_iov, allowing to organize the fields of struct net_iov.
> > > >
> > > > It would be great adding some result from the previous discussions in
> > > > here, such as that the layout of "struct net_iov" can be changed because
> > > > it is not a "struct page" overlay, what the next steps based on this
> > >
> > > I think the network folks already know how to use and interpret their
> > > data struct, struct net_iov for sure.. but I will add the comment if it
> > > you think is needed.  Thanks for the comment.
> >
> > I agree with David - it's not immediately obvious at first glance.
> > That was my feedback on the previous version as well :)
> >
> > I think it'd be great to add that explanation, since this is where MM and
> > networking intersect.
> >
> 
> I think a lot of people are now saying the same thing: (1) lets keep
> net_iov and page/netmem_desc separate, and (2) lets add comments
> explaining their relation so this intersection between MM and
> networking is not confused in the long term .
> 
> For #1, concretely I would recommend removing the union inside struct
> net_iov? And also revert all the changes to net_iov for that matter.

It seems like many got it wrong.  I didn't change the layout of net_iov
much.  I did nothing but replaced the existing pp fields in net_iov with
a wrapper, netmem_desc that still has the same fields.  Even with
net_iov reverted, net_iov still has the fields of netmemdesc.

Just to clarify, netmem_desc is the intersection but net_iov is not.
net_iov is a network's thing.

> They are all to bring netmem_desc and net_iov closer together, but the

It was already closer together even before this series, since netmem_ref
is used to unify the related usages.

> feedback is that we should keep them separate, and I kinda agree with
> that. The fact that net_iov includes a netmem_desc in your patch makes
> readers think they're very closely related.

Again, they were already very closely related before this series.  Of
course I agree with that it should be kept separated but it's another
issue.  It can be done on top of this series by e.g. Pavel as he said.

> For #2, add this comment (roughly) on top of struct net_iov? Untested
> with kdoc and spell checker:
> 
> diff --git a/include/net/netmem.h b/include/net/netmem.h
> index 7a1dafa3f080..8fb2b294e5f2 100644
> --- a/include/net/netmem.h
> +++ b/include/net/netmem.h
> @@ -30,6 +30,25 @@ enum net_iov_type {
>         NET_IOV_MAX = ULONG_MAX
>  };
> 
> +/* A memory descriptor representing abstract networking I/O vectors.
> + *
> + * net_iovs are allocated by networking code, and generally represent some
> + * abstract form of non-paged memory used by the networking stack. The size
> + * of the chunk is PAGE_SIZE.
> + *
> + * This memory can be any form of non-struct paged memory. Examples include
> + * imported dmabuf memory and imported io_uring memory. See
> net_iov_type for all
> + * the supported types.

The description should be changed depending on the result of discussion.
However, I will basically add this doc with some adjustment.

Thanks Mina.

	Byungchul

> + *
> + * @type: the type of the memory. Different types of net_iovs are supported.
> + * @pp_magic: pp field, similar to the one in struct page/struct netmem_desc.
> + * @pp: the pp this net_iov belongs to, if any.
> + * @owner: the net_iov_area this net_iov belongs to, if any.
> + * @dma_addr: the dma addrs of the net_iov. Needed for the network card to
> + * send/receive this net_iov.
> + * @pp_ref_count:  the pp ref count of this net_iov, exactly the same usage as
> + * struct page/struct netmem_desc.
> + */
> 
> 
> 
> 
> 
> --
> Thanks,
> Mina

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ