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 BCCF5C5AE59 for ; Wed, 28 May 2025 08:15:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 439AD6B0093; Wed, 28 May 2025 04:15:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 411036B0095; Wed, 28 May 2025 04:15:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 327086B0096; Wed, 28 May 2025 04:15:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 1B1DB6B0093 for ; Wed, 28 May 2025 04:15:51 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 2622380635 for ; Wed, 28 May 2025 08:15:50 +0000 (UTC) X-FDA: 83491608060.22.46FE963 Received: from invmail4.hynix.com (exvmail4.hynix.com [166.125.252.92]) by imf24.hostedemail.com (Postfix) with ESMTP id DD322180003 for ; Wed, 28 May 2025 08:15:47 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf24.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=1748420148; 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=LiiDxiM70KaRTfHQbQqfvatP9jje+QW0SEmzymqpidg=; b=pY8EGFqFBX/gpKZk3S7RpJfjIu0DBFSczZAMp2dYSV8UP/LFt0gbGULIuXdH18r/rsNhVQ F/uSxwS6oJTMqaO9XgbWS6+rjZvKRiD36x3/PK+DJcbXA++awOwOHuWLzSq1NFKXzoIo3o N9gN2wq1o8wvLopti9hQIePap97WpUg= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf24.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=1748420148; a=rsa-sha256; cv=none; b=U7C6KJffCwR2/ic7Nh7/XfeD0tGP9o//k41SHP0i4eKU+xT47VHvfzsK/ZLiGPtmA1kHOT SM3PCVgsJA6C5hOJXnnEtODg3gaNkMjmjHeUJo1IIGMiPYbTTfbLAliqiE2J94XjNB0AFY i8wcIlvVuTc8mAjE8IwBYgPUuy7GNtA= X-AuditID: a67dfc5b-681ff7000002311f-4c-6836c63082fb Date: Wed, 28 May 2025 17:15:39 +0900 From: Byungchul Park To: Toke =?iso-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: Mina Almasry , willy@infradead.org, 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, davem@davemloft.net, john.fastabend@gmail.com, andrew+netdev@lunn.ch, asml.silence@gmail.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 12/18] page_pool: use netmem APIs to access page->pp_magic in page_pool_page_is_pp() Message-ID: <20250528081539.GB28116@system.software.com> References: <20250523032609.16334-1-byungchul@sk.com> <20250523032609.16334-13-byungchul@sk.com> <20250526022307.GA27145@system.software.com> <20250526023624.GB27145@system.software.com> <87o6vfahoh.fsf@toke.dk> <20250526094305.GA29080@system.software.com> <87ldqjae92.fsf@toke.dk> <20250528051452.GB59539@system.software.com> <87sekpmbmg.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87sekpmbmg.fsf@toke.dk> User-Agent: Mutt/1.9.4 (2018-02-28) X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRzGe3fenR2Xg+PSelXSWmUkpBYVfylSP0hvH4KoICihhju0lU7Z 1FSozKRoNQuNqDljFqUuZbFMV6nlJS8UKJa2zJxpWkFZXpmXLk6J/Pbw+z88z/PhzzHyInEA p9GmCDqtMkHBSrH0u3fRxoimbeqI8w0KMNvKWLjvTofiPocYzNZKBONT7yUw1tjMwp2iSQbM bTkYJmzTDAw29UvAdW8IQ/WFKgb6r7SwYMyZYSDbUSKC9spcMVybvstAVVafBF4/MbPQW/ZH DEP1RgytplIMrtxoaLIsh8mX3xA02qpEMHm5kIX8DgsLAzkuBB0N/RgKzuYisNU6xTDjNrPR q2lF6TsRfWz6IKEWeyp9WBJKDc4OhtqtF1lqH82T0J6uapa23JjB9LFjTESN54ZZOjLYjemP 2k6W2io6MX1laZTQMXvQXv6QdIdKSNCkCbrwnUel6ilnjzj5fUh6Rek4k4UGVhqQF0f4LaSv 9CYyIG5el4yc9GDMryPG4l8ij2b59cTpnGI8Fl8+hrx0HzMgKcfwY2JiHTUyHs8y/ji53P2Z 9WgZD6TuTZXEY5LzlQzJv/EVLxx8SOvNT/OamQudvdUxH8rwgaT4N7eAg8m5RwXz2GtuQ9uP DA/249eQ55XNIk8k4R0ccT/Lxgvz/UldiRNfRT6mRQ2mRQ2m/w2mRQ0WhK1IrtGmJSo1CVvC 1BlaTXpYfFKiHc09zr1Ts4cdaLR9fz3iOaTwltEHW9VysTJNn5FYjwjHKHxl2VHb1HKZSpmR KeiSjuhSEwR9PQrksGKFbPPkSZWcP6ZMEU4IQrKg+3cVcV4BWUiGbq8M/hj7wvb2tP+wpqam +Lq50NVVO3CwfHvcEiEmM/JXX+edwQjNl0B9yMNgHBYVP+TKIpegu/fKrqU7NrSU0/3b97x6 1nzGFZMTGKkNUu3DbYNbVS2dQVGrgj9/SNlt9ePPP/3pjos40zgdMB2bGbt2ycSB8F3Dhryg a3bbWgXWq5WbQhmdXvkXND3YEjQDAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTcRjG+5/bjqvVcVkdtKhOZCSkBhlvWmqf+hMV0oeEQnLlwS2nxaam QWUqaMNpZoTNFSuvM2Fl5maYmC4vmRlbxlLTsOwiUXnFWxdnRH57eJ4fP94PL0vKM2lvVpWQ KGoSFGqBkVLSQyEZ2wJbdioDnT9WgNFSxcDdqRQof2ejwVhZi2B8ulcCY/ZWBopvT5Jg7Mqk YMIyQ8JQy6AEBso+UlCfZSVhMK+NAX3mLAnptgoCmm+20/CyNpeGazOlJFjT3knA+cjIQH/V bxo+NukpaDeYKRjIDYcW02qY7PiKwG6xEjCZc5OBAoeJgfeZAwgczYMUFF3KRWBpcNEwO2Vk wgVcY35D4DrDWwk2VSfhBxV+WOdykLi68jKDq0evSnDf63oGtxXOUrjONkZgfcY3Bo8M9VD4 e0M3g4s//yCwpaabws9NdkmE51Hp7hhRrUoWNQGh0VLltKuPPtPrm1JjHifT0Pt1OsSyPLeD rxg5q0MeLMVt5vXlPwl3ZrgtvMs1TboRL24v3zEVq0NSluTGaL5yVE+6mZXcKT6n5xPjzjIO +CevrBI3JOdqSb6g8Av1d/Dk2298WMjkvHTulmNBSnI+fPkv9m+9ns94WLRQe8zf0PU91V2v 4jbxjbWtxBW03LBIZFgkMvwXGRaJTIiqRF6qhOR4hUod5K+NU6YmqFL8T56Or0bzv1F2fi7f hsad+5oQxyJhmQzfC1LKaUWyNjW+CfEsKXjJ0sN2KuWyGEXqOVFz+rgmSS1qm5APSwlrZPsj xWg5F6tIFONE8Yyo+bcSrId3GmLOBVv4D/ZuX+HA2pJvF9bpnhZdu1GycTidSiwYOWJ2bkhe n5gSnHGnM9vWmWVPUp8QYlcfK+xPi7N4DU+ZYettZ1ZkXViHrzX3S1ThzJ6LSxz3x69nNx7O Whs8E7A3Kjr2UESIXqoS7EsPDpfOvSBsfXmyidDH4r38Qfxsl0wvUFqlYrsfqdEq/gAGYQaT FwMAAA== X-CFilter-Loop: Reflected X-Rspamd-Queue-Id: DD322180003 X-Stat-Signature: wfrbi7qgj4qhgdiz3xt9yr3ppfy4b5iu X-Rspam-User: X-Rspamd-Server: rspam07 X-HE-Tag: 1748420147-108427 X-HE-Meta: U2FsdGVkX1+60haiVHuyQq/aCdhE89CS49d5fJzdgvWTfMrXCIxR83dC3czOT33nWfL/ZyN/ccwle7Jr/rO1pE7oJEAXDWAqxrK5qMZb9Cfqk2G5w0dbu0LpCKwLUOx4/JC/Dc9XlbaS5w9D02nVVyjPf+077/FUSpNSifVK3FOgmRt0eSHRDn7Yfi3OUXnx4EPnZKViCj2w4n+CSObi0D+yefM4JZw8lap9lHHII8CPpZNZDWQRl8315PJEnTEoxXB7DW6pmwMMW9wLh0yfX8ME2TY1qAQKIZ6qImuVHaUdAct8Eynhd56l/rxuRKDasujb1KTQvNlfPW5Jo3X0xX6oUB4vgOY1W6NRHW/u4l+UmheMyJBSVP6Jld4eC269SOfWZm8VoplEVKSoCvP/6eBpXduVUdgJNAhtpzKNnVONYHV9N+IsdKxa4LSFGLWXLwqtSTYOsn+U56axnq56LYIUje3lB0u1tChSwMjHMYgQ/JJnDcU0EgPmvjBucvCBi0HoXIL7uSwwGgJV/aluMUqH85pLnnm3f00z3iCOxMb6/5QHSlD18d33SRMc22Zt6tC5MIO5RwSYMNRzAnLW77Lihwo1AY46Gl6kpqP06xuhWvurNtWxbdfsLbZU+TXMa8N9GqD0kw5k4cDjH6K8qpYdpKiDcKOvHkImkW/9Thnia2E3F8g4frF4HezzwLErFHMwr7O2XD+cRhbGJKz8RfbfRJahmzlkY7YuEvhHDOzd0/gyF2tRaVVtJOOvC+zP/EATvS2TXBfZ41oBT8srVD+RPkRXl+fRJ7IpHDdo+OLJnPuqofil6TGbqCEVtUkhs/4qBsBgX4ykBTs4xG5Bi5pQIlvlSey3fat4wtIHAuhkxadk7fQ+gygaXaMmGcB08r1ELNE44HActxZxu1dPRdUTdEGeRxAgrauf07KVug7cTis3KxUMd+07/GnNAAxni2VSyiu4fy/fcPRliIi yfchk5Ch kDMaCExTCswp3yXGS6e/pJV5WuES0ReGjrzrORSKU9zUqfaL0FkJSHpqkjqjdCWrHV9SYBSaRt1Fo4/EeK02n1MyD3Gj5eV70O7mq7PF8EihhvL+AkohKd5Z7CUd7hubB1i8bCWlzJc2VjTX87orH65/LbJt+3SluPlj5pDl+bGQzaGm1fW3uGfoPjw== 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 Wed, May 28, 2025 at 09:35:03AM +0200, Toke Høiland-Jørgensen wrote: > Byungchul Park writes: > > > On Mon, May 26, 2025 at 11:54:33AM +0200, Toke Høiland-Jørgensen wrote: > >> Byungchul Park writes: > >> > >> > On Mon, May 26, 2025 at 10:40:30AM +0200, Toke Høiland-Jørgensen wrote: > >> >> Byungchul Park writes: > >> >> > >> >> > On Mon, May 26, 2025 at 11:23:07AM +0900, Byungchul Park wrote: > >> >> >> On Fri, May 23, 2025 at 10:21:17AM -0700, Mina Almasry wrote: > >> >> >> > On Thu, May 22, 2025 at 8:26 PM Byungchul Park wrote: > >> >> >> > > > >> >> >> > > To simplify struct page, the effort to seperate its own descriptor from > >> >> >> > > struct page is required and the work for page pool is on going. > >> >> >> > > > >> >> >> > > To achieve that, all the code should avoid accessing page pool members > >> >> >> > > of struct page directly, but use safe APIs for the purpose. > >> >> >> > > > >> >> >> > > Use netmem_is_pp() instead of directly accessing page->pp_magic in > >> >> >> > > page_pool_page_is_pp(). > >> >> >> > > > >> >> >> > > Signed-off-by: Byungchul Park > >> >> >> > > --- > >> >> >> > > include/linux/mm.h | 5 +---- > >> >> >> > > net/core/page_pool.c | 5 +++++ > >> >> >> > > 2 files changed, 6 insertions(+), 4 deletions(-) > >> >> >> > > > >> >> >> > > diff --git a/include/linux/mm.h b/include/linux/mm.h > >> >> >> > > index 8dc012e84033..3f7c80fb73ce 100644 > >> >> >> > > --- a/include/linux/mm.h > >> >> >> > > +++ b/include/linux/mm.h > >> >> >> > > @@ -4312,10 +4312,7 @@ int arch_lock_shadow_stack_status(struct task_struct *t, unsigned long status); > >> >> >> > > #define PP_MAGIC_MASK ~(PP_DMA_INDEX_MASK | 0x3UL) > >> >> >> > > > >> >> >> > > #ifdef CONFIG_PAGE_POOL > >> >> >> > > -static inline bool page_pool_page_is_pp(struct page *page) > >> >> >> > > -{ > >> >> >> > > - return (page->pp_magic & PP_MAGIC_MASK) == PP_SIGNATURE; > >> >> >> > > -} > >> >> >> > > >> >> >> > I vote for keeping this function as-is (do not convert it to netmem), > >> >> >> > and instead modify it to access page->netmem_desc->pp_magic. > >> >> >> > >> >> >> Once the page pool fields are removed from struct page, struct page will > >> >> >> have neither struct netmem_desc nor the fields.. > >> >> >> > >> >> >> So it's unevitable to cast it to netmem_desc in order to refer to > >> >> >> pp_magic. Again, pp_magic is no longer associated to struct page. > >> >> > > >> >> > Options that come across my mind are: > >> >> > > >> >> > 1. use lru field of struct page instead, with appropriate comment but > >> >> > looks so ugly. > >> >> > 2. instead of a full word for the magic, use a bit of flags or use > >> >> > the private field for that purpose. > >> >> > 3. do not check magic number for page pool. > >> >> > 4. more? > >> >> > >> >> I'm not sure I understand Mina's concern about CPU cycles from casting. > >> >> The casting is a compile-time thing, which shouldn't affect run-time > >> > > >> > I didn't mention it but yes. > >> > > >> >> performance as long as the check is kept as an inline function. So it's > >> >> "just" a matter of exposing struct netmem_desc to mm.h so it can use it > >> > > >> > Then.. we should expose net_iov as well, but I'm afraid it looks weird. > >> > Do you think it's okay? > >> > >> Well, it'll be ugly, I grant you that :) > >> > >> Hmm, so another idea could be to add the pp_magic field to the inner > >> union that the lru field is in, and keep the page_pool_page_is_pp() > >> as-is. Then add an assert for offsetof(struct page, pp_magic) == > >> offsetof(netmem_desc, pp_magic) on the netmem side, which can be removed > >> once the two structs no longer shadow each other? > >> > >> That way you can still get rid of the embedded page_pool struct in > >> struct page, and the pp_magic field will just be a transition thing > >> until things are completely separated... > > > > Or what about to do that as mm folks did in page_is_pfmemalloc()? > > > > static inline bool page_pool_page_is_pp(struct page *page) > > { > > /* > > * XXX: The space of page->lru.next is used as pp_magic in > > * struct netmem_desc overlaying on struct page temporarily. > > * This API will be unneeded shortly. Let's use the ugly but > > * temporal way to access pp_magic until struct netmem_desc has > > * its own instance. > > */ > > return (((unsigned long)page->lru.next) & PP_MAGIC_MASK) == PP_SIGNATURE; > > } > > Sure, that can work as a temporary solution (maybe with a static assert > somewhere that pp_magic and lru have the same offsetof())? Sure. I will do that as I posted in the cover letter: https://lore.kernel.org/all/20250528022911.73453-1-byungchul@sk.com/ Byungchul > > -Toke