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 E1A06C71136 for ; Wed, 18 Jun 2025 00:08:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 018756B0088; Tue, 17 Jun 2025 20:08:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EE3886B0089; Tue, 17 Jun 2025 20:08:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DAB4E6B008A; Tue, 17 Jun 2025 20:08:51 -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 C78546B0088 for ; Tue, 17 Jun 2025 20:08:51 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 2F83680DB0 for ; Wed, 18 Jun 2025 00:08:51 +0000 (UTC) X-FDA: 83566585662.11.DF9088E Received: from invmail4.hynix.com (exvmail4.skhynix.com [166.125.252.92]) by imf11.hostedemail.com (Postfix) with ESMTP id 7E03B40002 for ; Wed, 18 Jun 2025 00:08:48 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=none; spf=pass (imf11.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=1750205329; a=rsa-sha256; cv=none; b=rk8fWxCqVzvyxNdjiI5+Dk+1SgMOIYYJPVIAAc1BjD6kWeXoTlEKjAxQ92M7ir0m+3hKt5 YX2CAE6NL3KbsthrwqZvvKorjdrGpl0+LSoaMaW9GAl6OzKGyxRbdmVsbaE/lKMASMlI26 iCRv/VfFDWmtz0Wowj2oRS0Nh8nKpBU= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=none; spf=pass (imf11.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=1750205329; 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=RJzh4d8V24mgOHq0c8AjZ2tvMQAir36Nwd2EzjlHTUc=; b=7IV7Bn4CVFs5Q5XhiT1SmSDEM4SXdiNPF4kM+yVVE0507Hagg0qDj2J778Rq/h3kdNhPQ6 pvMbVW2pOsH+12xEJggcdNeteluMSKmp8/igyKSkdEs9hfPsnIzcUdVWjhTGLHLC2wYHr+ wUPwkqiAW08dBYvX/oD5zy61Hh0J31M= X-AuditID: a67dfc5b-681ff7000002311f-28-6852038d4a0f Date: Wed, 18 Jun 2025 09:08:40 +0900 From: Byungchul Park To: David Hildenbrand Cc: Harry Yoo , Mina Almasry , willy@infradead.org, Jakub Kicinski , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, kernel_team@skhynix.com, ilias.apalodimas@linaro.org, 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, 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: netmem series needs some love and Acks from MM folks Message-ID: <20250618000840.GA23579@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> <129fe808-4285-48fe-95b6-00ea19bd87af@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <129fe808-4285-48fe-95b6-00ea19bd87af@redhat.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTYRTHe3af3V2Hg+tKeyp6cRVGkJpInKhEo5dLpVRCRAU18tZWvuSm poJktQxFp6WYzrelNV8yV6t0ikjaKktBWyirrImlZWSS1tCUalMkv/04/z/ndz4chpJWCJcy yug4XhUtj5TRYiwecS/foKUOKvy1dgqKjbU03JlIhMp+sxCKa+oR/Jx8J4Jxy3MaKm46nI0u DYZfxt8UDD4bEIHdMISh+WoDBQPZ7TRkaaYouGSuEkB3vVYIeb9vU9CQ2i+C103FNHyo/SuE obYsDC901Rjs2mB4pvcCR8c3BBZjgwAcmSU05Fr1NHzU2BFYnwxgKLqoRWBssQlhaqKYDvbm Hla/EXCNuvciTm+K5x5UrecybFaKM9Wk05xp7LqI6+ttprn2ginMNZrHBVzW5e8092PwLeZG W3pozviwB3OdeouIGzet2M8eEW+N4COVCbzKL+iEWPEh/5XoXL5PoqVMmop6l2cgN4awgWTE cAPPcf77EqGLMbuWOAxNIhfTrA+x2SYpFy9i1xFT2j0nixmKvUaTnj7LTLCQDSF/7j8VuFjC AsmrmMCukpS9RZGRlwPUbOBBXhR+mrFRzq3TpVbnnHHyMlL5h5kdrySXHxXN1N3YIDL5yDbD nuxq8rj+ucC1k7BmhnyurkWzVy8hrVU2nIM8dPMUunkK3X+Fbp5Cj3ANkiqjE6LkyshAX0VS tDLR92RMlAk5X8eQMn3UjMa6w9sQyyCZu+TengMKqVCeoE6KakOEoWSLJBXtYQqpJEKelMyr Yo6r4iN5dRtaxmDZYkmA43yElD0tj+PP8vw5XjWXChi3palox7EtRdvO+H97M+F/92RtwL5M 49D30pQFuw8ZsjXZLaYQTVfeZu86cdpIWVNs3c6c+/5qk2dHLm2v2dXiVziqQteC3bcHFmA6 WcF6hV0YXHXiq/RpecGV1lOhPpsyHiTtXZP1ZFXncMeXMH34aFd67zCypqZIDufGKrwMQ6FI vE6G1Qr5xvWUSi3/B2gXCps2AwAA X-Brightmail-Tracker: H4sIAAAAAAAAA02SXUhTcRyG+e+cnXM2Wh3X0oNiwawMKctI/EERSkQHL6TyIrSLHHpoy6/a 1LQyNKVQmmWF5Jy1skxN3Fzl1MRiTt0ssmbastRaKRV9LW1MLWtTIu8e3vfluXopTHyaH0gp MrI4ZYYsTUoIcWHc1qINamyvfNMFz3rQ6hsJuO3JhVtvWvmgbWhBMDX9ioRJSy8BNdfcGGj7 i3H4qZ/BYLzHScJY7QQOHWdMGDjPWQlQF89icKq1jgdd1TY+PG0p48OlmZsYmArekDDQriVg tPEPHybMahxsmnocxsqioUfnD+5HnxFY9CYeuM9WE3DRriPgXfEYAnuXE4eqwjIE+k4HH2Y9 WiJayt6tf8lj2zQjJKszZrN36sLYUocdY40NJQRr/HGBZF8PdRCs9fIszra1TvJYddFXgnWN D+Pst85Bgq358J3H6u8O4uxjnYXc7Zco3JbCpSlyOOXG7UlC+WjFM/JwRWiu5aq4AA0FlyIB xdBbmIqRar6PcXoN465tJ31M0KGMwzGN+VhCr2OMpw1eFlIYXU4wg68t88VyOoaZa+7m+VhE A3OpxoP7RmL6BsZ86XNiC4UfY6t8j/sY81p/XbF7c8rLQcytOWohXsUU3auanwvo7cz0Pcc8 r6BDmIctvbzzaKlmkUmzyKT5b9IsMukQ3oAkioycdJkiLTJclSrPy1DkhidnphuR9x21+b/K W9HUwC4zoikkXSIyxO6Ri/myHFVeuhkxFCaViGqscXKxKEWWd4xTZh5QZqdxKjMKonBpgCh2 H5ckpg/KsrhUjjvMKf+1PEoQWIAeDG5WmOMNNsnXvvvdnV9GpR+vuRjp29Kmk1Z3aMzzbk// 6sK6FyvrTE8Cm483d6rid7q2TdsFO/yPnFCPy0MkYflr3VVtxM3I4Ka+eGQ5Gu2azIvyK81y WoZliSXX3eZc229DQnllgiuZLBRGLStuJD7NRKzojzy0v2B4JEAjxVVyWUQYplTJ/gIzik1J GQMAAA== X-CFilter-Loop: Reflected X-Rspam-User: X-Rspamd-Queue-Id: 7E03B40002 X-Rspamd-Server: rspam02 X-Stat-Signature: 694pchxy8j84ywzskbyp1b461w1umtdb X-HE-Tag: 1750205328-675829 X-HE-Meta: U2FsdGVkX1/xmIF70zVMNIKgR5InGQyyICHGSIR30AxrhIlpYeveG3PlWco6jeAcAAEDG3QrzgI91epFGMVisfMJOJbvsgFRBwccf3OdoXo3d1i1bY4lDHNVlmXydpFPdiYlnbow0tlVdGcjhULP5gqy7Q+7+a4DFqfjFcJMenTjagbHuk3mEOshoXpowAHj133hBuHZNVXpzVHkEmS0ZLBDkrVZli5MRjD4oZkcM9YzYPYEMJlE3/X8ia7mGiZzcO0e5NhjOPSF3Blb6afw7wS+kYdhBYQ7+1Zo2t9WSvPWw5uJ9FSO+Mvl/p1TYV051djo5TIPjTKU3VoxdN25cGRb6aY/MnyBG19Il0DrzD80DjQumTjEVcv7nI1/TEV8kWCXDrCmoeLN76kTfXiofpr/zBhmrVmL7RInwyaesQAhxJFGp9i+bBwT1KhZ2vaNL4PYp3H960pPXFwBkUUFREGE4ZhAEtx2oncQP37vVmjGjWjlkhYDjh6potLMHBRzBe1qO893DTwiOz1GhdtiuVDmXm7rRmm36xP4SL1DExNmMiALZm18UKCMWN+zmjJXjza/+jb2yNd++FpzHDm8fAQkEKBfXUKap4BahHF6agJGIST8uYLO6n13PLduv7tn8eYMNazWGia05mXc3CLpib+rcgHBGDq0GfDLf91qX50qotHZoh0hK5wT03xHyU55HohrTa4JoOq98DbSicP4+NLPQKmTOtUvcH9UrpV2VUxAFHgCD1/cXGUOBS7wMMTUDR/C3NZuS6CcGmSgD2gDbJR4pxdRUFfDRU/RU1q3X+7hJ432maQo78cwXYkXthhlPPpottiDEFPmq0Q9TKWbKuOR/IbRbAtYGEhJH2oNXnW86fyktUy9YKG+EpwuB2lIhioaGMwnhRm6T+EUr8pdsqDtI/xcWBmmA6JW/E5GpHMrrrzeyR1xRjAGRogSVvh5w2SB8o6Qa1J+1PMR31M ceuFxwR3 t0arLWXDsbxDZw6dMCS6k9Qk+OUggVJ6+CwHTVA1n40fgkY3zhhFzTBY50XcgRNrpx5M2EcfeHNZbqZGP5PrOMcm7CSDuZ15pKLHlf9ujXZtCPCI= 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, Jun 17, 2025 at 06:09:36PM +0200, David Hildenbrand wrote: > On 17.06.25 04:31, Harry Yoo wrote: > > 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? > > > > Let's try changing the subject to draw some attention from MM people :) > > Hi, it worked! :P > > I hope Willy will find his way to this thread as well. > > > > > > 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. > > > > As someone who worked on the zpdesc series, I think it is pretty much > > in line with the memdesc plans. > > > > I mean, it does differ a bit from the initial idea of generalizing it as > > "bump" allocator, but overall, it's still aligned with the memdesc > > plans, and looks like a starting point, IMHO. > > Just to summarize (not that there is any misunderstanding), the first > step of the memdesc plan is simple: > > 1) have a dedicated data-structure we will allocate alter dynamically. > > 2) Make it overlay "struct page" for now in a way that doesn't break things > > 3) Convert all users of "struct page" to the new data-structure > > Later, the memdesc data-structure will then actually come be allocated > dynamically, so "struct page" content will not apply anymore, and we can > shrink "struct page". > > > What I see in this patch is exactly 1) and 2). > > I am not 100% sure about existing "struct net_iov" and how that > interacts with "struct page" overlay. I suspects it's just a dynamically > allocated structure? > > Because this patch changes the layout of "struct net_iov", which is a > bit confusing at first sight? The changes of the layout was asked by network folks, that was to split the struct net_iov fields to two, netmem_desc and net_iov specific ones. How to organize struct net_iov further is up to the network folks, but I believe the current layout should be the first step. Byungchul > > -- > Cheers, > > David / dhildenb