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 D4209C7EE31 for ; Fri, 27 Jun 2025 03:54:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CF69A6B0095; Thu, 26 Jun 2025 23:54:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CA53C6B00B3; Thu, 26 Jun 2025 23:54:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B945F6B00B4; Thu, 26 Jun 2025 23:54:18 -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 A246B6B0095 for ; Thu, 26 Jun 2025 23:54:18 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id C805F8050E for ; Fri, 27 Jun 2025 03:54:17 +0000 (UTC) X-FDA: 83599812954.25.EC54936 Received: from invmail4.hynix.com (exvmail4.skhynix.com [166.125.252.92]) by imf03.hostedemail.com (Postfix) with ESMTP id 1840220003 for ; Fri, 27 Jun 2025 03:54:14 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; spf=pass (imf03.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=1750996456; a=rsa-sha256; cv=none; b=h37ZPDknXG9Tphfa4D+uPbCnJB8ldpWGHJujWPXVTY9P/NKd6bA/XXSvRZJ7+mXuCp4Hql kCd2lqNl9pkWOR3lTK0OTBM/rG4GEkqEDMue//YHqdNumRXzXI9Yndi/pYMsckFy+2XH02 uodvTQxUtvoScqtcNP10xa4ZnQzEUN4= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf03.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=1750996456; 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; bh=Ptx7nSH4UY8iGP4Jx5RT9n1JGYKmJcVfhe4Jgq++/FY=; b=3Q3mpoCgirGRTwjculcVig8y3E2FmiFEx6+DLy9nNR4ot0ukge8FuG1UGaywlCrXF8pQ/5 OZGQUyhzqb5N4IUYrZQq5WL25hfEDLiNXCwvwfx2hUReX1zIJymcYyoD9c0KyMD0/lA2L0 WKrFt9ln1YWIwivyd3DGEIV1QTmrHOI= X-AuditID: a67dfc5b-669ff7000002311f-b5-685e15e2381c Date: Fri, 27 Jun 2025 12:54:05 +0900 From: Byungchul Park To: Jakub Kicinski Cc: willy@infradead.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, kernel_team@skhynix.com, almasrymina@google.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, hannes@cmpxchg.org, ziy@nvidia.com, jackmanb@google.com Subject: Re: [PATCH net-next v7 1/7] netmem: introduce struct netmem_desc mirroring struct page Message-ID: <20250627035405.GA4276@system.software.com> References: <20250625043350.7939-1-byungchul@sk.com> <20250625043350.7939-2-byungchul@sk.com> <20250626174904.4a6125c9@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250626174904.4a6125c9@kernel.org> User-Agent: Mutt/1.9.4 (2018-02-28) X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHec85O+e4Wh3nrFf9EsuohDJD6iG6GAQdiiiQIhLTUzu41TSZ lzRITKWLqd1Ec7OYRrmWNZvhVkytqVmYFZaxbmrrQpktLBuppW2K5Lcf/+f//Hg+PCwp10tC WU1KuqhLEbRKWkpJv82sXuIO3q1e1mpaBJWWWhqu/c6Cmj67BCrNDQiGhl8z8LO1nYZLVV4S Kp8UUPDLMkLCx/tuBq5Zt0DvlU8UOI7ZSHCfekBDccEoCY3DHgby7CYCnjaUSKB05DIJttw+ Bp7dqaShp3ZcAp+cxRQ81F+loLckBu4b54C3YwBBq8VGgLfoAg3nuow0vC/oRdDV4qbAcKQE gaXJJYHR3z6Hoa2HiQnnWwa+k/ytqy8J/rb+LcMbrRl8vSmCL3R1kbzVfILmrT/OMvybFw6a f3B+lOJv238SfHG+h+YHP76i+O9N3TRvudVN8Y+Mrcy2wF3S1SpRq8kUdZFrE6XqzrHU1DJF lvP1YyIXDc8uRAEs5qKxNb9TMsV/y0YYP1PcAjxoez/BNLcQu1zDpJ8VXDguqK+gCpGUJbkq GhvLHROlIE7ADvcQ4WcZtxL3egaRvyTnjiLc/vcPPTkIxA8rPlB+JrkI7Br74ltgfRyGa8ZY fxzAReGeurYJTzA3H99taCf8HszZWVxuyCcmLw3B90wu6jTi9NO0+mla/X+tEZFmJNekZCYL Gm30UnV2iiZr6d4DyVbk+5grh//E2dGPp7FOxLFIOVMGkfFquUTITMtOdiLMkkqFTPbCF8lU QvYhUXcgQZehFdOcKIyllHNly70HVXIuSUgX94tiqqibmhJsQGguqh5fMn55lmFASLz5anvF RvWOFfuDjElNbS2bPMkrYj6c6Xt+z1bSfD3rRkh6R96Q1/A1pCbOGj508eChvC/xOfnanFX9 /SfvzD5uXluxWfHZY1l8rK/fZG5+1xwl3VnduHVfUUMd+UaVvj7uVFFsRlhdqWJeQtjGPd9m sGvWBedoNjiVVJpaiIogdWnCP+YTlCAtAwAA X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTcRjG+59zds7ZaHRasw5WRLMLCKVC0QtGaRT9CbKgD4WUeWgHN9Jp m5cZBGpWJGllUTqVJtbyFqspOmtKTE1NummXleVkphSIZl5wOq3NiPr243mf3/PpZUmFjwpm tbpUUa8TElW0jJLFRJ7f4gmK04TPTy2HUmstDTUzRrg/YJdAaXUDgklvHwMTbR00VJRPk1D6 KpeCKessCUPPPAzU2A6C2zJMgeNSIwmeq5005OfOkdDsHWUgx15JQGtZlwReNxRI4ObsPRIa swYY6H1cSkN/7S8JDDvzKegyVVHgLoiCZ+aVMN09gqDN2kjA9JUyGm70mGkYzHUj6Gn1UFCS XYDA2uKSwNyMf6OkvZ+J2ohbR8ZIXF/1kcBNpi8MNtvScF1lKM5z9ZDYVn2ZxrafhQz+/N5B 486iOQo32ScInH9+lMbjQ58oPNbyjsYV334Q2Fr/jjqsiJXtVIuJ2nRRH7YrXqZ5sZCScktp dPa9JLKQd1kekrI8t42fvzXLBJjiNvLjjYOLTHObeZfLSwZYyW3gc+uKqTwkY0munObNtx2L pRWcwDs8k0SA5dwO3j06jgIlBXcR8R3zPvrPYTnfVfyVCjDJhfKuhe9+gfXzav7+AhuIpVwE 3/+wfXEniAvhnzZ0ENeQ3PSfbfrPNv2zzYisRkqtLj1J0CZu32o4rcnUaY1bTyUn2ZD/Jyzn fNftaLJ3vxNxLFItlUPYCY1CIqQbMpOciGdJlVIuf++P5Goh86yoTz6pT0sUDU60mqVUq+QH jorxCi5BSBVPi2KKqP97JVhpcBb6kO5u3hO3e2/LnoLI4dCcwyOFwZbxyDMZIeua7Z2HXsbi 48mOu1NrpSHMvti3j2a6pc0Pomq8tRHdRypLBt8svMkr0s2uWXKkzfVELxo3FR6LUSh3L2GU FkF7Y29/X/QFaVjCnO/j83D1g+hstTmDbcLrM3y8uvfmHUtyNFW1RkUZNEJEKKk3CL8BPOu0 Jg8DAAA= X-CFilter-Loop: Reflected X-Stat-Signature: uai375gmxn86nstacw6bzyupjawzm1cn X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 1840220003 X-Rspam-User: X-HE-Tag: 1750996454-531730 X-HE-Meta: U2FsdGVkX1/uqt7WAFyDToEcSphaxs5f3uB7k99R7JuR8PMhM19fnZuPQTdMSqAH0ZT2cP3P6RgjwnplfB/uuN/rXMtDNeSAUp5R9TJv0ZEgXjvQ186L6uzN4fTXQeWflAG9A7KcibtVJT5NNlHCmyZG5w7n1fpHyUa3DXyBO7uAx1/RyByWf0dzrMylKODFzYuErjZMW6Pqt7R8twwm/j+T5FhQBZm11anKVKkJ6EZaHIGThyPHyDe03Ja0kkv2BANVgYlSKdhe1IoGD0Gphl9bRSnoZGQn7E5IxbFr9VoKDeEBxXrVaBXOOLL6/hMLUF6Q7GpvKbBEZL/5nJJ0PuZAyJgBpVw0fp2pQ1qPNzmtaPSZAu6l/oqjGI42ADbwodhlRdwHj1NaQXMEStlgTH8nGv5hXuWcNLLcUQHpopQqM+r30BF8w3ebF48Sj3tkjJ5FPsWTYPZFToR8/aSAQEOuzOP7Frp05COeTm2e27BnEZiDHcLs99YqNLfYWZvO1QhNUeoWckD175n5v/3SU54h4KaOLeoaXb4EBndOPBORlZOlLbNieTlSnawZdhCWlpHJnJHcm6XVGgONpn3GJvzWg6UndQXEen4qZP80KenI1P/MkLqjvonLsMhvjSi/0q6mhOdE2qIJR6zm196DZLyTQZflY3iDG6bg5JknzOpgz9ADC9X1TtUfRrRIh11rxsCe+uj0rSTavm8tM1lfNBikS4MiL6hFk+JK0FVuY0d6m4jHcdxfSia7GLqLE1sWxMiecOdcEMa0oOy3poDd/TE97Kc9C2Mc+ahBQUXdDHNC+gzDUFoDAIfjUusnhO1wTWgIfM8WEeEDgMpgKxruN657BHgjoA/WXXAzXtVd2OHFqrjB2s34cVkrmdhi4CcNL+itNrFIBTaA+obhwNG+d9++fjHcaftgXDtkbLT/VGh2XPs7zi/SHDqA12QPGUXQiFm/4klJyGP04g9DXL2 OpLTaO1i iCT0YhGuzXUGmTSlz14XqkZ3DGjT1kY+kE0/9 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 Thu, Jun 26, 2025 at 05:49:04PM -0700, Jakub Kicinski wrote: > On Wed, 25 Jun 2025 13:33:44 +0900 Byungchul Park wrote: > > +/* A memory descriptor representing abstract networking I/O vectors, > > + * generally for non-pages memory that doesn't have its corresponding > > + * struct page and needs to be explicitly allocated through slab. > > I still don't get what your final object set is going to be. The ultimate goal is: Remove the pp fields from struct page The second important goal is: Introduce a network pp descriptor, netmem_desc While working on these two goals, I added some extra patches too, to clean up related code if it's obvious e.g. patches for renaming and so on. > We have > - CPU-readable buffers (struct page) > - un-readable buffers (struct net_iov) > - abstract reference which can be a pointer to either of the > above two (bitwise netmem_ref) > > You say you want to evacuate page pool state from struct page > so I'd expect you to add a type which can always be fed into > some form of $type_to_virt(). A type which can always be cast > to net_iov, but not vice versa. So why are you putting things > inside net_iov, not outside. The type, struct netmem_desc, is declared outside. Even though it's used overlaying on struct page *for now*, it will be dynamically allocated through slab shortly - it's also one of mm's plan. As you know, net_iov is working with the assumption that it overlays on struct page *for now* indeed, when it comes to netmem_ref. See the following APIs as example: static inline struct net_iov *__netmem_clear_lsb(netmem_ref netmem) { return (struct net_iov *)((__force unsigned long)netmem & ~NET_IOV); } static inline void netmem_set_pp(netmem_ref netmem, struct page_pool *pool) { __netmem_clear_lsb(netmem)->pp = pool; } I'd say, I replaced the overlaying (on struct page) part with a well-defined struct, netmem_desc that will play the role of struct page for pp usage, instead of a set of the current overlaying fields of net_iov. This 'introduction of netmem_desc' patch can be the base for network code to use netmem_desc as pp descriptor instead of struct page. That's what I meant. Am I missing something or got you wrong? If yes, please explain in more detail then I will get back with the answer. Byungchul > > + * net_iovs are allocated and used by networking code, and the size of > > + * the chunk is PAGE_SIZE. > > FWIW not for long. Patches to make the size of net_iov configurable > are in progress.