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 23F41C71155 for ; Fri, 20 Jun 2025 04:12:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5BA346B007B; Fri, 20 Jun 2025 00:12:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 591D06B0089; Fri, 20 Jun 2025 00:12:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 480DA6B008A; Fri, 20 Jun 2025 00:12:21 -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 37ECF6B007B for ; Fri, 20 Jun 2025 00:12:21 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id D44E21D396E for ; Fri, 20 Jun 2025 04:12:20 +0000 (UTC) X-FDA: 83574456840.05.0B5A18F Received: from invmail4.hynix.com (exvmail4.hynix.com [166.125.252.92]) by imf22.hostedemail.com (Postfix) with ESMTP id 4498AC0007 for ; Fri, 20 Jun 2025 04:12:17 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf22.hostedemail.com: domain of byungchul@sk.com designates 166.125.252.92 as permitted sender) smtp.mailfrom=byungchul@sk.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750392739; a=rsa-sha256; cv=none; b=66jeoqkl+CfEBTpf5DKd9eWyOVuC8WiEYMCRJ35VxSP0GGs4rfx3DHZveejpj1H396uyEG OgewnQk+REBmd4HAYUjkpP75B7LrS24bkvLKeIaHh6QWBTQKuZTdcBxUacc83EB46VFgRM KCS3GTspFiepWSy4eh+x5Pe+5eh+q04= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf22.hostedemail.com: domain of byungchul@sk.com designates 166.125.252.92 as permitted sender) smtp.mailfrom=byungchul@sk.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750392739; 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=D41LMJhbt8+U3eBiFmdTG/4c/mmR4U2gOr9xCqjWS6U=; b=U7yp70ExcFDEz7nCYogWo5n4WJpKHSminmXLdgv0EEeamQ4QPZ8tWaVWH7MxOyu1FR6750 woSrHSV2jE5v4RI5wrbFZK4C/msU5biUY65jTCceqapb8TrIVzYDzAcz1lUd2aLVtG4Xkn iDZfH+X4YsMq0SlZCOxh30/6mhIyo4Q= X-AuditID: a67dfc5b-681ff7000002311f-1d-6854df9d3c68 Date: Fri, 20 Jun 2025 13:12:08 +0900 From: Byungchul Park To: Mina Almasry Cc: Jakub Kicinski , willy@infradead.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, kernel_team@skhynix.com, 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 net-next 1/9] netmem: introduce struct netmem_desc mirroring struct page Message-ID: <20250620041208.GA11405@system.software.com> References: <20250609043225.77229-1-byungchul@sk.com> <20250609043225.77229-2-byungchul@sk.com> <20250609123255.18f14000@kernel.org> <20250610013001.GA65598@system.software.com> <20250611185542.118230c1@kernel.org> <20250613011305.GA18998@system.software.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: H4sIAAAAAAAAA02Sa2yLYRTH87y3vuvW5FXDsxGigliCbRk5RGTxQV6XCOELEtT2Rkt3SWs3 IcY6l7JhJqwr6YxdukUpum6qY8YuNqZ2qW3WZbZFxAydsUuMdhH79sv5n3N+58NhSelNOphV xh4W1LFylYwRU+KBgJtLr7t3KEIrny8Cg7mUgZJfyVDYbaPBYLIiGBrpEIGnuoaB/LxhEgyv tRT8MI+S0PeiRwTugn4K7KfLSOi5UMtAhnaMhJO2IgKarJk0ZI/eJqEstVsEbysMDHSVTtDQ X5VBQZ2+mAJ3ZiS8MM6E4ZefEVSbywgYPn+dgctOIwMftG4Ezmc9FOSeyERgdrhoGPtlYCLn 8w+K3xF8uf69iDdaEvj7RSG8zuUkeYvpLMNbvmeJ+M5WO8PXXhuj+HKbh+Az0r4w/Le+doof dLQwvPlBC8U3GKtFvMcydyu3S7wmWlApEwX18rX7xIrBiQE6/vyc5Po7a1PRwAwdYlnMReBH nuM65OfD0TNXSS9T3ELcWNxLeJnhFmOXa8RXD+SW4FuOS7QOiVmS+0rj8u4R5A2mc3uwqeOn b0DCAR4w2X1NUq6ZwFmXO0STwTRcl9NLeZn8u3X8hpP0HkFys3Hhb3ayPA+nPcz1yfy4bThP 20p7eQa3AD+x1hDenZizs/jNxSto8uog/LTIRV1E0/RTFPopCv1/hX6KwogoE5IqYxNj5EpV xDJFSqwyeVlUXIwF/f2cgmPju23oe9P2KsSxSBYgsQ1tV0hpeaImJaYKYZaUBUrya7copJJo ecoRQR23V52gEjRVaDZLyWZJwoeToqXcAflh4ZAgxAvqfynB+gWnovznOfeafxjtESuJivSk KP8n+rvGBQEP6wW6rz1RGxC+vj9Ymr45lGtqUTuzqq+kZx892BTpEAdtmG9oK4ymE8ZHT6lW 6bLjz3WuGKLdobs+dTrOpD2+uvXQGwvVteHj+LqJyooG6U6XFQVa7fvbxvzTdJWrwzZu8pwe 0byKKmmUURqFPCyEVGvkfwDhqzvKNQMAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTcRTH+d3X7mar61K7ZFCtFwmZQcIRxaLnDwsxDMyCdNXNDR+TOxXt AZbaQ3LlI7K51WLlY2WLVTpLJKb5qCzRCtNSMYuK1tOsqT2cEfnfh+/3nM/557Ck4gg9m9Wk pAliiipJycgoWWRozjJT/1Z10M9fvmC0XWHg8o9MqBhw0GC01iAYdvdK4GtTCwOWCyMkGB/l UvDNNkrCq+ZBCfSXv6ag/mgtCYMnWxkoyB0j4bCjkoBGUxsNHTV6GkpGL5FQmz0gga5bRgb6 rvym4bWzgII2QxUF/frV0Gz2g5H77xE02WoJGDlhYqC408zAy9x+BJ2NgxSUHdIjsDV00zD2 w8isVuIbVc8IXGd4IcFmezq+XhmA87s7SWy3Hmew/UuRBD9/Ws/g1tIxCtc5vhK4IOcDgz+/ 6qHwx4YnDLa8+URg240nFH5gbpJEeW+Xhe0RkjQZgrg8PF6m/vjbRaeemJN572p4NnL55iMp y3Mr+dFjZ0gPU9wivr1qiPAwwy3hu7vdk7kPt5S/2FBI5yMZS3KfaL5uwI08xUxuJ2/t/T65 IOeAd1nrJ4cU3GOCLyrulfwtvPm2s0OUh8kJ6/i5zgkrO8H+fMUv9m88l8+5WTZ5TMpt4S/k PqU97Mst4O/UtBCn0HTDFJNhisnw32SYYjIjyop8NCkZySpNUnCgLlGdlaLJDNytTbajie8o Pzhe6EDDXRudiGORcprcMRytVtCqDF1WshPxLKn0kVtaI9UK+R5V1j5B1MaJ6UmCzon8WUo5 Sx4RI8QruARVmpAoCKmC+K8lWOnsbEQOBSyK9fIPW6W9G6JXhESutUSN6/e/lfyUds0r8pLF H1il1YbfXGDwjV33vfehGOquM2ryNkffCR7aIO4tOf1ubV79jF1Cn7ojdr4u5tCavMUuhbjN YqoujXCtKLu2e+F5R2D0pqDivdXtfd6nMNmz/vbnxq4dFS1E3EiMX0Jfo5LSqVUrAkhRp/oD 2SBXbxkDAAA= X-CFilter-Loop: Reflected X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 4498AC0007 X-Stat-Signature: qgembr39g3aqyeqpf59imeyp6fct4jtg X-Rspam-User: X-HE-Tag: 1750392737-250225 X-HE-Meta: U2FsdGVkX1/HZIjIJ9LFXJvle4C9foE/PgXkH0YIqAPPBa3/yrg+Pq460ALIDoeaTn8n+hQYR2ZWh1PIMbcMQ2gnwwrIQrHlU4R1uG2bOgZKJygP6rJo0aPYtw3ueJD5w5hi+0rMv78aZaHwwSkB6rfEne7fayrkZjEfT8q+qTf4Tslv8pMo9EsoVjSFi1WyVktN41OlFnyHc3czDKAhjgdJCqp3Zfi4QPWzXktIr8UWxKmPR75Npk8gJu0sS+ctY9HTKbHB9MzGa9UW9DmJV8zlAu4ISbRLU7A9AhuLXwT4g21HAHCMcKpr5AcQgqdUzBSHkpFWH1lVYHEZYSNvE+Y7K+7JC8WSbfvIJ+pk7WzcEGSjVlHv0X4DGTMfRPe0mvmuATnYQUPTiQ1nk7TWEWAikcRPF6NmZGLeu2dti8teplQrHolvLBw++0HlUr3YlmhldJY5lymo+0y5LoNDbM0A/SEFfgXtzL0T+T0O8UvlQhNuIYZnVSN0NgzUsEkLxoaxG0SvTFQ3ZuE6y66Nm+DfY5EabRSSrseYGdOogj0g1eRMt5BTWXEqk78ECJus4bME2jyuOP1Lsm/CVvEBg2UnSdvrCOJ1OjNIbc4SL9UuBe39OaHCMVb1YtEbwkcu81CK0h3VnirgykhGP78yE7SecTXhaF3q2wZAJxAoHih/noIf8PhmwSgR9Qy42EuomfMe2KMPUItL83MTephnu1g5IBLqEQvPGjUjsuFyoppIz73J5vBPUplrGK+v0y1QVNMhmZu/T/c/nQb8a/wGEbXOw68R4xWkn3FomUc4YwM= 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, Jun 13, 2025 at 07:19:07PM -0700, Mina Almasry wrote: > On Thu, Jun 12, 2025 at 6:13 PM Byungchul Park wrote: > > > > On Wed, Jun 11, 2025 at 06:55:42PM -0700, Jakub Kicinski wrote: > > > On Tue, 10 Jun 2025 10:30:01 +0900 Byungchul Park wrote: > > > > > What's the intended relation between the types? > > > > > > > > One thing I'm trying to achieve is to remove pp fields from struct page, > > > > and make network code use struct netmem_desc { pp fields; } instead of > > > > sturc page for that purpose. > > > > > > > > The reason why I union'ed it with the existing pp fields in struct > > > > net_iov *temporarily* for now is, to fade out the existing pp fields > > > > from struct net_iov so as to make the final form like: > > > > > > I see, I may have mixed up the complaints there. I thought the effort > > > was also about removing the need for the ref count. And Rx is > > > relatively light on use of ref counting. > > > > > > > > netmem_ref exists to clearly indicate that memory may not be readable. > > > > > Majority of memory we expect to allocate from page pool must be > > > > > kernel-readable. What's the plan for reading the "single pointer" > > > > > memory within the kernel? > > > > > > > > > > I think you're approaching this problem from the easiest and least > > > > > > > > No, I've never looked for the easiest way. My bad if there are a better > > > > way to achieve it. What would you recommend? > > > > > > Sorry, I don't mean that the approach you took is the easiest way out. > > > I meant that between Rx and Tx handling Rx is the easier part because > > > we already have the suitable abstraction. It's true that we use more > > > fields in page struct on Rx, but I thought Tx is also more urgent > > > as there are open reports for networking taking references on slab > > > pages. > > > > > > In any case, please make sure you maintain clear separation between > > > readable and unreadable memory in the code you produce. > > > > Do you mean the current patches do not? If yes, please point out one > > as example, which would be helpful to extract action items. > > > > I think one thing we could do to improve separation between readable > (pages/netmem_desc) and unreadable (net_iov) is to remove the struct > netmem_desc field inside the net_iov, and instead just duplicate the > pp/pp_ref_count/etc fields. The current code gives off the impression > that net_iov may be a container of netmem_desc which is not really > accurate. > > But I don't think that's a major blocker. I think maybe the real issue > is that there are no reviews from any mm maintainers? So I'm not 100% > sure this is in line with their memdesc plans. I think probably > patches 2->8 are generic netmem-ifications that are good to merge > anyway, but I would say patch 1 and 9 need a reviewed by from someone > on the mm side. Just my 2 cents. > > Btw, this series has been marked as changes requested on patchwork, so > it is in need of a respin one way or another: Some can be improved but the others not. For example: +static noinline netmem_ref __page_pool_alloc_netmems_slow(struct page_pool *pool, + gfp_t gfp) It complains about the long line length but no idea how to avoid it :( I can do nothing but to ignore.. Byungchul > https://patchwork.kernel.org/project/netdevbpf/list/?series=&submitter=byungchul&state=*&q=&archive=&delegate= > > https://docs.kernel.org/process/maintainer-netdev.html#patch-status > > -- > Thanks, > Mina