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 EDA71C77B7F for ; Sat, 28 Jun 2025 00:37:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 34EB86B00A9; Fri, 27 Jun 2025 20:37:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2FE8F6B00AA; Fri, 27 Jun 2025 20:37:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1EE576B00AB; Fri, 27 Jun 2025 20:37:36 -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 0A5AE6B00A9 for ; Fri, 27 Jun 2025 20:37:36 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 31A63B95A9 for ; Sat, 28 Jun 2025 00:37:35 +0000 (UTC) X-FDA: 83602946070.22.A15EE16 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf22.hostedemail.com (Postfix) with ESMTP id 7A524C0008 for ; Sat, 28 Jun 2025 00:37:33 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=is9ZQW5S; spf=pass (imf22.hostedemail.com: domain of kuba@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=kuba@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751071053; 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:dkim-signature; bh=KL+GQUh5LamtbgH3O4tfjGxEKy6du6D6WKwbbHOTl2k=; b=M1StcvDE2LZ0gm7jWa7Qdz3voAi+EScFzTJ72UW+BOknJOH0VQC+9ua1zEcArQOoWQpkAy jNbizs8/81mZTvRoxcaamp0Z2KfKJmA6y/rc2X2K2M8Bb1hvPloZAXdjb944YnvTGYFBp1 U5cjA1P4yYCVN9ZPWOxRCKVnQVEOSXk= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=is9ZQW5S; spf=pass (imf22.hostedemail.com: domain of kuba@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=kuba@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751071053; a=rsa-sha256; cv=none; b=YRXcdoI2/P6nYAOYBSQPx7dwIK6ZMU6AMbTR+evDqajuFn4i4H0OITWPg2X5678WELsLGY 7zym3gp0+e3LsK//ah0cnhFVRLolKph2e4I0uMQWZmIIm3wQJ7HZKqOT1/BZrRXAa0HuQt NB4mtGUWZxTrcN8yToq4wgbtyFUeub4= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 191B45C5AF5; Sat, 28 Jun 2025 00:37:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C330AC4CEE3; Sat, 28 Jun 2025 00:37:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1751071051; bh=tBZzo3Vernjc/RqLkt5V8ZGDjHbDEERaWaQdG3x/eHc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=is9ZQW5S9yroLWwxDcQ2Vxz+Dg5Y50/NyQBvJwjq5cDM1u51Bvk5Cs9/lFSIE85jJ EV1+RIIonsc367dy6yP/idPDFgr6//xfQlVccl7agu2V2Q3+nSw0HqSQzJy/Ws4x85 XyV9cF86Q+a0q6WEyplKPawW8vsbH54tVyMecukC+IqEIzYXn75h/C1Lcvf4Is4uDr lJ52UeZLlgHJ6/I7fuqzz8U430UyFRX7eVcTMu+FL7v+mHAR9q6aM7DA4cUV6pl0o7 w3UqoSNnFp0wIsJSzfYwHB6ye62zLTsYGZaMEGE7CW6jC4fdVac34dRgfi1QCh0Dzu /15NohvMHz1dA== Date: Fri, 27 Jun 2025 17:37:30 -0700 From: Jakub Kicinski To: Byungchul Park 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: <20250627173730.15b25a8c@kernel.org> In-Reply-To: <20250627035405.GA4276@system.software.com> References: <20250625043350.7939-1-byungchul@sk.com> <20250625043350.7939-2-byungchul@sk.com> <20250626174904.4a6125c9@kernel.org> <20250627035405.GA4276@system.software.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 7A524C0008 X-Stat-Signature: ik33ski8zcm8gxx3isgpiji4cqyf3jzp X-HE-Tag: 1751071053-317346 X-HE-Meta: U2FsdGVkX19v2J08F13vaX6FHT+PDPZGaKnhLKkjRYOK8ci/n5ewqeiSOoWDbAlJ8vQhVg/zvuyZ7esdliPtjxuZna133OQ86H5XomzGyeAn39WsoMeF8r3HaHWPhmBB8ZyytPBXj49k9RSVGD1xsW095nHuy0fPRi2Y/4l1PvcCsSScMZ05BhbwbccxcHdmwkaIcV9NaLJtn+6bSS2v7ywEW2xdpX+VLlJdkzVljbzyUND+p+0MOGsuRSOVOFveyGno7Rbu0QiZ0IsV8nQN7vMW70fSC0lKh7XKHY3imaQDCSzd4eG72uBMgkJWTLJ4lM44ghzaKbhZ3UResk7NLBxzCa189RB1SW5Z3wHdqWsk1g8dz0O7mD5APcwI+HNBMHQr5HKfpDV4trhNR3BpDx7chXfBz9LFyjgYhrSRxCwSFa8KzZXt90djYtgM8ExIqHLYYbVeu9acKJnd2y8ClsZ+eIDA6qLewjogrND1uTzLpUAZd5vfIulPlgCLHq777UESWsyInPvIDWOiXg3oeqdDMCXpfzjgZUzM1EgA8dBOWqQ6U75z2Ww5fO4rMQpcA1cfOqh52X3vpZltgxBS1LOqPwAqQmsUfIt2/jOSZzPa9RSPaolbYl7YjrBp4EfnHVE2g6f4OuPNwyRnl9YaYfDQUaxWoApnMyKM6anv25VtoH5Zh4TqEe/KApkUC3HAsO3MSKUed4tp09xp3Wv1AJrOptDCUGS+xPvXCSVOA/pfwIkeaskaqh1PZlBRYxLO1PH+KFeHK6PTNUOGNm1a1MFcrdUrHf8xDOtZeVAuUdbYvTxGZMG0fn/Uv7hmVRi2Zs36ES5NhLV4V78HySiik60/NFjjQVIFxN76FvzX0UzNxhGzWo8hQysnvw/O3tgrZDLohz1ewSk93kdHTWRgEQGzhvWQNCN/1VCksMLyq0lyxJCxDiyz+ODguLKDz4J+zkT3eGrUVQjRBToD0Xy W75gBMBg AW3QTrDAmfaLUD/1SaZ5oxCiSqZwGtg+t5zKuNmHnB6ChXVfJmAEbmuLjeJF8zOQBPrY42mG7376iLoeBBEynfIEJlOQt9HZ++43bNQGWxiMiLVFh9WorKMO4eF1Y9lz1OFAOnkwD9vBCWtZsEfjAXc9n6a2wmdBKsFBnmrfZAyEs4IGPTQNAaQTgqzvUppIl2ISQ683nYt746C+BSMURoO49XGuDcBQi86dOZgiZa1p60YupZxJzQmO36BzJ/l3rMYU2PgDKQlXj4LZAeOKcjow24vNevONxwQftDKWCcSYmsc9sYkryrJVN1byhdlWgMIPHnJ0ZFcBR5lnQrAQvz6+WUoY2oWJpQBUoXqFDg1op/gSYtHPfsojS647/niwHGUci 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, 27 Jun 2025 12:54:05 +0900 Byungchul Park wrote: > 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. Object set. Not objective. > > 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. Ugh, you keep explaining the mechanics to me. Our goal here is not just to move fields around and make it still compile :/ Let me ask you this way: you said "netmem_desc" will be allocated thru slab "shortly". How will calling the equivalent of page_address() on netmem_desc work at that stage? Feel free to refer me to the existing docs if its covered..