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 24A0DC3ABC9 for ; Fri, 9 May 2025 19:48:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 62AD46B00E5; Fri, 9 May 2025 15:48:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5D7316B00E6; Fri, 9 May 2025 15:48:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 49F226B00E7; Fri, 9 May 2025 15:48:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 2D0056B00E5 for ; Fri, 9 May 2025 15:48:39 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 192071CC6BD for ; Fri, 9 May 2025 19:48:41 +0000 (UTC) X-FDA: 83424406842.24.9839D4F Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf23.hostedemail.com (Postfix) with ESMTP id 5BCBA14000F for ; Fri, 9 May 2025 19:48:38 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=JtkAbn2m; spf=none (imf23.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1746820119; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=LHzIEA61Md5/xpeDzeP5A1UdrB0NGR5BHd5W1xhlBOs=; b=w5HA/1qVKqBD98upSzM1OeFcgnU3GmkjbahpJh+KEwcRldiI8seExFDiFvMTfQ8fsXhi7E ePJaRbATfeZJypVh+mCf0zzWylq1cMD+jkz/Dt/DO5FA3+oi8bhyTF5XvBzd6GkpIYS/jw 8rJ9ky+YztvlLLY4sUnyCsqWVRtkunY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1746820119; a=rsa-sha256; cv=none; b=K1MKfGpQDv5Ex7P0JyUBUr6+477IlEi6yYi7Lv3H/6W+R+Q+UuO1HEGiI31lKFQOPO72VE kV9EWlVEscfdYfbfsmrMmQVtY8NmOzT+tbXGNvkpAxgpHQLu6P24P3OYBVg58wE48kSE+B 4GrEIW4/li/zTkB0lCp17Uk7IOWC8lw= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=JtkAbn2m; spf=none (imf23.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=LHzIEA61Md5/xpeDzeP5A1UdrB0NGR5BHd5W1xhlBOs=; b=JtkAbn2mI5hQHgI6W7flVzUtrh mpI1gsSyMvrONBoXr3Zj/SOFDfINrQ4etEVWyKOw8ZuwruWJJ2depHPJc6SbVr6digw77yzcyQhLe pZ37NhsrRcVzroJdOhFDB2qvriramcVdh2Y8a5pBw05k/p2J4U3AFiZFb0H5ssU80NoSj2lachYXK fWHuJeSvmJuwSLqHbeqSZPCnmqbLqEftte0N6IGtrjeH02unmwWnkdvWjts06PMAU1U9Igz7WAXtD 4lp8YFtAYhnQV46q8I90J9k8nU3Xxn5icnEKgJNBZWk37Xv1QwCOOIKH1wNwl8eorM8VJJ+ouFwQs Fs6mNgZQ==; Received: from willy by casper.infradead.org with local (Exim 4.98.2 #2 (Red Hat Linux)) id 1uDThc-0000000H3Vg-1HTz; Fri, 09 May 2025 19:48:12 +0000 Date: Fri, 9 May 2025 20:48:12 +0100 From: Matthew Wilcox To: Mina Almasry Cc: Byungchul Park , 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, ast@kernel.org, daniel@iogearbox.net, davem@davemloft.net, john.fastabend@gmail.com, andrew+netdev@lunn.ch, edumazet@google.com, pabeni@redhat.com, vishal.moola@gmail.com Subject: Re: [RFC 19/19] mm, netmem: remove the page pool members in struct page Message-ID: References: <20250509115126.63190-1-byungchul@sk.com> <20250509115126.63190-20-byungchul@sk.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: 34tit3bshudbkcjaewj6rooz1wpdcpsi X-Rspamd-Queue-Id: 5BCBA14000F X-Rspam-User: X-Rspamd-Server: rspam02 X-HE-Tag: 1746820118-2490 X-HE-Meta: U2FsdGVkX18/4cPPAtPK6H2XmhfRuX8T90ZjHxWRdOPqrXdMp+YjV9EluXlVuQhOaBOQeGVrFuAapHspWwkUvy/XD94rBi5hVrNhunkkBhBpCevKIp7a4VRTiSm50R1ze1vQfWcsJ3MGJXyDNZNbtJetwM695EAL1rvJkp7FgUrXYhDMwKZGcYmtSZsyzfm3IqK9PvIjAsWGMEqsUIBXQ5EmcwSstmVjiDNWDJXoSYTh+CGQnjhjxA/I3x//YtyXnJmlz1IwFiVhsoYkSBw1XoJ4N8JUkVDxAo5iDjCwAYY0HSYV8vPSpJaQHh37rhIWG0SD+RQGsCIcJefheRxlE+7RtO10y1U5c76NV3UwfEjjXbBCT0BUxttAWk6e5Kum2QgOyeLLpIYr8UxS9cn28dor2yKl6Rkjtxd9Qtv8jn9h6qj5sGEDYZQlB2QCmxUCuy8IatNoysvVI62CUnyqdKdUiXkGvOTlB7DzgmHPZc9lFHBEIjHj56BiqFx5K+u7vOX6DggwB+mIGqxKx/82CFJwNOkrq1CaN/Y6AIlodRZzjuL6eA0GWu/5DTp9ZNjH4lGSC5DQKuOd3hLOVEW7kzeT+HxkVigK+1ruj4JRRaNOnJ/MSdmL0NBwkYTZGPIvGxbTNqyZW0NoHKVFpSVL19In2lRKplRkwskXljncbe/xEJih7u6NcHZUn7Rs7OsfZNarDbDS70Mw8+JTj02jXG7Z5+XOaV6aZQuwloFhxtHjDr1Q+iC2D8VYJj4SHk8ii8S1frHiDpuDKUJzk4rAM1L9py9Qg8UO5L7UA+uWoH5+0etcZ3rqu/tar+9hfCpIUeAk34+nV0hMWeiMLFI9JEx1j/6Kq1Rvct0lBCjdwGXPJcqTHBMxIQrl8kMVh+ZLdZ2tTXG9Wj62mtiufmpCl7Rm66bZ6tQoNwKD6yik/9IoE6RicBYKzfpOY8RTw8Avz0CUKu7o7xD/cJ44mOM g3RzkkPb r5+lWZOXNw8EkIxmR3ZeDtZvpsFTSvtKC0Bqpz6r99t0aRd9JQ34eZxzEY2u3EViVjD/E6LZMT5NNyGL1yCNOKkh1YDdSNFF8cmNh1sjKTqJhKXHgT8sECAxlkQXzzhMXIaPVj9/aiDbhtJMtzQC7Pizs7vthD9zgIzrASaY3EE7A1iSyBli0xjoLEoCVD6x0NoxYUWyGmjCTMEgDzksjVmx85trOqhXGs4DrcttEv+8jx3I/H0g8+FHNzj0zcWZs0TTZbm/h20XVej1mCpJhBk+0BtqRO2Pixv9SNMbrl9x5qDpvGCobg6pWDtu6WLrdrAEJtYacYVqX7h/Ew+rAPCcJW692uahYMyxRuo3c2JY0Up064+OFknO7FQ== 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 Fri, May 09, 2025 at 12:04:37PM -0700, Mina Almasry wrote: > Right, all I'm saying is that if it's at all possible to keep net_iov > something that can be extended with fields unrelated to struct page, > lets do that. net_iov already has fields that should not belong in > struct page like net_iov_owner and I think more will be added. Sure, that's fine. > I'm thinking netmem_desc can be the fields that are shared between > struct net_iov and struct page (but both can have more specific to the > different memory types). As you say, for now netmem_desc can currently > overlap fields in struct page and struct net_iov, and a follow up > change can replace it with something that gets kmalloced and (I > guess?) there is a pointer in struct page or struct net_iov that > refers to the netmem_desc that contains the shared fields. I'm sure I've pointed you at https://kernelnewbies.org/MatthewWilcox/Memdescs before. But I wouldn't expect to have net_iov contain a pointer to netmem_desc, rather it would embed a netmem_desc. Unless there's a good reason to separate them. Actually, I'd hope to do away with net_iov entirely. Networking should handle memory-on-PCI-devices the same way everybody else does (as hotplugged memory) rather than with its own special structures.