From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id EB956C5AE59 for ; Thu, 29 May 2025 04:47:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8394F6B00E3; Thu, 29 May 2025 00:47:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 810876B00E4; Thu, 29 May 2025 00:47:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 726A26B00E5; Thu, 29 May 2025 00:47:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 535D56B00E3 for ; Thu, 29 May 2025 00:47:01 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id EAC11140571 for ; Thu, 29 May 2025 04:47:00 +0000 (UTC) X-FDA: 83494710600.02.4F8F0D6 Received: from invmail4.hynix.com (exvmail4.skhynix.com [166.125.252.92]) by imf13.hostedemail.com (Postfix) with ESMTP id 6C9AC20008 for ; Thu, 29 May 2025 04:46:58 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=none; spf=pass (imf13.hostedemail.com: domain of byungchul@sk.com designates 166.125.252.92 as permitted sender) smtp.mailfrom=byungchul@sk.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1748494019; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Q09FdAMGF14m3wGUhWEYb+VP100iVZQuVrnsMwUQgGI=; b=uGKeky0HabyRgN7h7BfEi/h8IdlFx8/9UV/6zInXrDCtCIusajySlt1afEZ3NrgctxBuX7 C2Ocj7zWqsVBYO2hlXQCb7KOwib/ed7oMKDcofblTflLkht/zrKNTS7PJ17pFwq2Fhft++ v91NhahY/pQJcH707OEaNlsVqTC4nfg= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=none; spf=pass (imf13.hostedemail.com: domain of byungchul@sk.com designates 166.125.252.92 as permitted sender) smtp.mailfrom=byungchul@sk.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1748494019; a=rsa-sha256; cv=none; b=5p+Jk0cHpMYOxDH2wH25BNFwZEPh1PRIZRxyxv4HwIm/hACaoLaGR5SoCwiEpZdA3Dhgb7 Ft67jlsXBUmPw+iPag4uRg/otH8r0CDZzbben8h/+BX2NpRGCkOivnrughpoPDoDja7K/b DEFgsne0yhtj2/STTjh0R0TjN1VMN1c= X-AuditID: a67dfc5b-669ff7000002311f-ff-6837e6be8606 Date: Thu, 29 May 2025 13:46:48 +0900 From: Byungchul Park To: Mina Almasry Cc: willy@infradead.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, kernel_team@skhynix.com, kuba@kernel.org, ilias.apalodimas@linaro.org, harry.yoo@oracle.com, hawk@kernel.org, akpm@linux-foundation.org, davem@davemloft.net, john.fastabend@gmail.com, andrew+netdev@lunn.ch, asml.silence@gmail.com, toke@redhat.com, tariqt@nvidia.com, edumazet@google.com, pabeni@redhat.com, saeedm@nvidia.com, leon@kernel.org, ast@kernel.org, daniel@iogearbox.net, 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, linux-rdma@vger.kernel.org, bpf@vger.kernel.org, vishal.moola@gmail.com Subject: Re: [PATCH v2 01/16] netmem: introduce struct netmem_desc struct_group_tagged()'ed on struct net_iov Message-ID: <20250529044648.GA1148@system.software.com> References: <20250528022911.73453-1-byungchul@sk.com> <20250528022911.73453-2-byungchul@sk.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0iTYRTHe/ZeHY7eltpTQdlCRCm7YHk+hAYRvgSBIhGkYCtf3PK2NjWN ClNLkrQrmOst1s3mrcEqnTUk19i0y7SFMTOdmkrRxdQyU9FaEvntxzn/c37nw2EJ+U1qBavO zBa0mcp0BS0lpV/8b65vHo5SbXz5ajGIpjoaaifz4G6fhQKxpgHB91/dDIzbnTTcujFBgNhe TMIP0xQBQ44BBrxVwyRYSxoJGDjXSkNZ8TQBhRajBDoayim4PHWHgMaCPgZePxJp6K2bo2DY VkZCm76aBG/5dnAYgmDi+WcEdlOjBCbOXqPhkttAw/tiLwL30wESrp4sR2Bq9lAwPSnS29fw D6q7JHyTvofhDeYc/r4xnC/1uAneXHOG5s1jFxn+3RsrzbdemSb5Jsu4hC8r+krzo0NvSX6k uZPmTQ86Sf6Fwc7w4+ZVcdw+6bYUIV2dK2g3RO+XqnpHHZTGG5ZnsrroAvRxVSnyYzEXid/W i8Q/trSUU6WIZUkuBLc/D/aVaS4Uezy//kYCuDB8u/kC5WOC81LYJR7y8VIuCw/+nKJ9LOOi cPe5wT95KSvnjAjPzRZK5htLcFvlIDk/HIpnrrsJn4vgVuK7s+x8eTUuenj1r8uPi8eVtysY Hwdya/GTBqfEtxNzVhZ7az9T8zcvxy1GD3keLdEvUOgXKPT/FfoFCgMia5BcnZmboVSnR0ao 8jPVeREHszLM6M/nVB2fSbSgsY4EG+JYpPCXtaIolZxS5uryM2wIs4QiQFYYs1Ull6Uo848K 2qxkbU66oLOhlSypWCbbPHEkRc6lKrOFNEHQCNp/XQnrt6IAlaS66hepu57N1sasPfBtyJk0 ImNdk2Rv3GHFiRnTljpN9OYWqzFw59HkgU/fQmJeOroflxTtZbSHqpyivUyMnN67Izjr62ys cLrLfqFiZ9xw8R7Nves6VVDlOqUuKWV3f//IB4FjiF3E+UnDUMKptO7YxMHoxfE9ck9I7JNj JxSkTqXcFE5odcrf0V1RuTUDAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTcRiH+5/bjqvFcWmeki6swhtaQeUbhhYEHvzQRSrBL3XKQ1vqlE1F o9DUsCxXllSuGaupmQknvM5Ykhe8oGhONEtzMi8USWWWlluWSyK/Pfx+7/u8X14al18m19Mq dZKgUfNxCkpKSA+FZAW+mAxW7ih7vhcMYgUFT3+kwuNRMwmG8loE334OSWCmpY0C08NZHAw9 2QR8F+dxmGi1S8BWOkmAJacOB/uNdgrysh04ZJrLMGgu6iDhVa2OhIL5EhzqMkYl0PfcQMFI xW8SJpvyCOjQPyHAptsPrca1MNs5haBFrMNg9noRBbetRgrGsm0IrM12Au5f0iEQGwZJcPww UPsVXPWTNxhXr38n4YyVyVxVmT+XO2jFucryqxRX+fWWhBsesFBc+z0HwdWbZzAuL+sTxU1P vCW4zw39FGd6/wXjxOp+gusytkiOuEdL98UIcaoUQbM99JRUOTLdSiba/FJFSzeVgT5szEVu NMvsYs2NOjIX0TTBbGN7Oje7YorxYQcHf+Iu9mD82OKGfNLFOGMj2W7DORevYRLY8bl5ysUy JpgdujG+OC+l5UwZYn8vZGJLhTvbUThOLC37sM4HVtx1C2e82ccL9FK8ic2quf/3lhtzlC0s vitxsSezhX1Z24bdRKv1y0z6ZSb9f5N+mcmIiHLkoVKnxPOquN1B2lhlmlqVGnQmIb4SLT5H 6UVnvhl96wtvQgyNFKtk7ShYKSf5FG1afBNiaVzhIcsM26OUy2L4tPOCJuGkJjlO0DYhb5pQ eMkiooRTcuYsnyTECkKioPnXYrTb+gwUE+L0nQvzXffwUVCB6JTVn7bzEb7DCxMrMfHTnjYh ei7KUhQg20K+FtOPaq8NZPkfXOE8fueK2uvX1YBGY6TDP9KvKun22ArrR5M69PCGktDiGpPm WtcJTx4pTAdUKU8dObqpksBnqq3TLXJ722Gv+mNh+VWW3uIL0tnw3qh0BaFV8jv9cY2W/wNU cGkJGAMAAA== X-CFilter-Loop: Reflected X-Rspamd-Queue-Id: 6C9AC20008 X-Stat-Signature: stb477zpq8eqbg7hqbqqcqeb43ip8hiq X-Rspam-User: X-Rspamd-Server: rspam04 X-HE-Tag: 1748494018-838504 X-HE-Meta: U2FsdGVkX1+LPgBn/mu/sM6ldT8KiMrBVhNbFaIPGn8xuMErhP4zK27/PDSW75selXwn1mn5CIbTtN7Mv7tXprfqLMoTpRfK/w9Profx2i6fNIZ7VCIclAD6lb+8IJCdg8cRrfTNachMOvgABbfNADxHZoZNmnXUUIEbgebN3ab1JNIzdzIhnA7O2Oquj+V1foYzmWX6kR55hJHBpvcWXfyJ7T28AU6JibiKuKJbkgER11kvBFTChXadLZjm2A4RjXEJQ4bPMC6t16jKX4jpmRTSkKIb/C3f2JYg15DIRFn11hO76XcZn6tOj4BRUaBRe5WA76z+bEq/4zB7Y5DlFUzwx3GJz0ubt4K4H5KoU5jG2/CSMUkk0VOBsGJ7yslANt11j1xF4QtQ5XdoXF+zZntu9khvfCWxrS+oeTh5/Uc1vIPULx/6+2Zq5kfC9rRB9703Z2YIhT/Urm+YoLnSe8q3uCRlhBQ52QYio4zEY1MAOowzKHsGho/KsOfG8/nhUTxbJt3rhxXsh6/J2xs9Hu6ROMVQvI9xmc0akBo6QGRzYtdVd7E3hRpPT6AyN/skuH6p1Dj6a07pO5Z//zf3kSCLiIi60uOwj74h68snn4TSAWnJjLa3ip3X3mYG7AGOBJpcJnavIz/XGr/NMmVSTBfzEYMgiFI19qRHhSBvh3hwJO1gD+py0v33Ajq1aYmvNUbYIAhGNb/0r+mFGWwXk7sTH9zAxufyJBno0Bc3J+AothH9pQB1BcugD0GWZRJAP93iljC+zFufk1nwYnGi19MEjbUNVzc/+5l6s80zgrcGwyLhzgYRV/dyIQF3H3HJS3YBOD8RJvQGKL5VinFXjtPNtv+EKWHGBDmJnqHOJfANiVUtwznPvRlY1Bi71ZvBW3mm24PMhOktvSnUN4R/OwzjzXPHjmoEsG81Uf3B6u5EcW4A0LutA+Gv2DNM5ZYlW57xB5WoK9xj1ZFWow7 hf8BEzF1 Hl/rV/gFYghhSeTMynAhaPgMdxCwmNei4za1DC7ev8NLiE1DTFZqkcgmFsm+qVX4xe4kz++EEywqm0fGAKEW4cSMqgPW/QPqb9GRN5eXrSZyhKAYbwhkTNrBuWtDAFbAViAqpHSn5sl2BOOPkCzb0eFTYFfYoZf/1sxxD2HmqOY/uH9NuGMOCKC/RjQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, May 27, 2025 at 08:39:43PM -0700, Mina Almasry wrote: > On Tue, May 27, 2025 at 7:29 PM 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, reusing struct net_iov that already mirrored struct page. > > > > While at it, add a static assert to prevent the size of struct > > netmem_desc from getting bigger that might conflict with other members > > within struct page. > > > > Signed-off-by: Byungchul Park > > This patch looks fine to me, but as of this series this change seems > unnecessary, no? You're not using netmem_desc for anything in this > series AFAICT. It may make sense to keep this series as > straightforward renames, and have the series that introduces > netmem_desc be the same one that is removing the page_pool fields from > struct page or does something useful with it? I didn't document well nor even work quite well for my purpose. I have to admit I was also confused because the network code already had a struct mirroring struct page, net_iov, so I thought it could be the descriptor along with struct netmeme_desc until the day for page pool. However, thanks to you, Pavel, and all, I understand better what net_iov is for. I posted v3 with all the feedbacks applied, I guess the changes in v3 are going to meet what you guys asked me. On the top of v3, I think we can work on organizing struct net_iov to make it look like: struct net_iov { struct netmem_desc desc; net_iov_field1; net_iov_field2; net_iov_field3; ... }; In order to make it, we should convert all the references to the existing fields in struct net_iov, to access them indirectly using desc field like e.g. 'net_iov->pp' to 'net_iov->desc.pp'. Once the conversion is completed, we can make net_iov look better, which is not urgent and I will not include the work in this series. Please check v3: https://lore.kernel.org/all/20250529031047.7587-1-byungchul@sk.com/ https://lore.kernel.org/all/20250529031047.7587-2-byungchul@sk.com/ Thanks to all. Byungchul > > --- > > include/net/netmem.h | 41 +++++++++++++++++++++++++++++++++++------ > > 1 file changed, 35 insertions(+), 6 deletions(-) > > > > diff --git a/include/net/netmem.h b/include/net/netmem.h > > index 386164fb9c18..a721f9e060a2 100644 > > --- a/include/net/netmem.h > > +++ b/include/net/netmem.h > > @@ -31,12 +31,34 @@ enum net_iov_type { > > }; > > > > struct net_iov { > > - enum net_iov_type type; > > - unsigned long pp_magic; > > - struct page_pool *pp; > > - struct net_iov_area *owner; > > - unsigned long dma_addr; > > - atomic_long_t pp_ref_count; > > + /* > > + * XXX: Now that struct netmem_desc overlays on struct page, > > This starting statement doesn't make sense to me TBH. netmem_desc > doesn't seem to overlay struct page? For example, enum net_iov_type > overlays unsigned long page->flags. Both have very different semantics > and usage, no? > > > + * struct_group_tagged() should cover all of them. However, > > + * a separate struct netmem_desc should be declared and embedded, > > + * once struct netmem_desc is no longer overlayed but it has its > > + * own instance from slab. The final form should be: > > + * > > Honestly I'm not sure about putting future plans that aren't > completely agreed upon in code comments. May be better to keep these > future plans to the series that actually introduces them? > > > + * struct netmem_desc { > > + * unsigned long pp_magic; > > + * struct page_pool *pp; > > + * unsigned long dma_addr; > > + * atomic_long_t pp_ref_count; > > + * }; > > + * > > + * struct net_iov { > > + * enum net_iov_type type; > > + * struct net_iov_area *owner; > > + * struct netmem_desc; > > + * }; > > + */ > > + struct_group_tagged(netmem_desc, desc, > > + enum net_iov_type type; > > + unsigned long pp_magic; > > + struct page_pool *pp; > > + struct net_iov_area *owner; > > + unsigned long dma_addr; > > + atomic_long_t pp_ref_count; > > + ); > > }; > > > > struct net_iov_area { > > @@ -73,6 +95,13 @@ NET_IOV_ASSERT_OFFSET(dma_addr, dma_addr); > > NET_IOV_ASSERT_OFFSET(pp_ref_count, pp_ref_count); > > #undef NET_IOV_ASSERT_OFFSET > > > > +/* > > + * Since struct netmem_desc uses the space in struct page, the size > > + * should be checked, until struct netmem_desc has its own instance from > > + * slab, to avoid conflicting with other members within struct page. > > + */ > > +static_assert(sizeof(struct netmem_desc) <= offsetof(struct page, _refcount)); > > + > > static inline struct net_iov_area *net_iov_owner(const struct net_iov *niov) > > { > > return niov->owner; > > -- > > 2.17.1 > > > > > -- > Thanks, > Mina