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 A115AC83F10 for ; Sat, 12 Jul 2025 12:04:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F29B96B00C2; Sat, 12 Jul 2025 08:04:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id ED9996B00C4; Sat, 12 Jul 2025 08:04:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DA1876B00C6; Sat, 12 Jul 2025 08:04:24 -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 C41B26B00C2 for ; Sat, 12 Jul 2025 08:04:24 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 326E712AC04 for ; Sat, 12 Jul 2025 12:04:24 +0000 (UTC) X-FDA: 83655480048.27.0403AA7 Received: from mail-ej1-f47.google.com (mail-ej1-f47.google.com [209.85.218.47]) by imf30.hostedemail.com (Postfix) with ESMTP id 2C4BE80006 for ; Sat, 12 Jul 2025 12:04:21 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=h23w1ZUu; spf=pass (imf30.hostedemail.com: domain of asml.silence@gmail.com designates 209.85.218.47 as permitted sender) smtp.mailfrom=asml.silence@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752321862; a=rsa-sha256; cv=none; b=Xbak+Vyxur6ajG1nDdb8N79zgHxrhddzQmsxk+/Juu0EdV0Oa4Sw8cLw54nxI5ZkMadEeo Zj2YUSWBV/8pH/awLnKz2vJZTZRSvGjmftiM5G7X44Z73lCNe56zgVHJiMBgPbGpl5daRN IRWBW/1sgpvzjcvuDSKXtLYs1RfElyU= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=h23w1ZUu; spf=pass (imf30.hostedemail.com: domain of asml.silence@gmail.com designates 209.85.218.47 as permitted sender) smtp.mailfrom=asml.silence@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752321862; 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=wVU84Q4TTNFb/InD+14kTpRtPOAaj4ENC3rSLs7cunU=; b=M8qArVjqCA9LdsQ1FHB2//pbBU0kgi6qu9KWYzhiTIZkTf9aKc+I2BFStJBZbG8aK2mhNA JNGhC3Un5luvs1pFDS9OTfBqiH9y8k8XdUGTG7arrfnxAjzwTmU4nqNWv+flpajxUXuU+4 6PN35w04uqbODu4XC8qzTESfFMxZNtE= Received: by mail-ej1-f47.google.com with SMTP id a640c23a62f3a-ae0d758c3a2so459201366b.2 for ; Sat, 12 Jul 2025 05:04:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1752321861; x=1752926661; darn=kvack.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=wVU84Q4TTNFb/InD+14kTpRtPOAaj4ENC3rSLs7cunU=; b=h23w1ZUuaEB9H0FaKDZPNNbv+b1FFSIwkG+51ERvPTUVv2oUI3b18amKSj0AaB2n7o UofV4KgM1kMTScoDMaNykpFCuvDe/9fnA+lyAPuJNEwwt+ZkONOgoJbvAJb2A6jQkKO7 st7yH8T0eduNb3wBR/M2dAewDIuXg1wp2Z7NIVGnqx3NSq8btwl0rlqB1aOmNadZlShS 2uvJMZpSWeYB1KHmAQ2tT9um3d+Nyiq2RuqTsWxsfCv2QhozwlEw9DMwOwEdH6grKr6t EoqopE84KYxoE0NNIFdtmx8sCom9Hx/LrXKnURZtOge8SBbVT6S2YPeJroC/fLLshAeV CiHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752321861; x=1752926661; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=wVU84Q4TTNFb/InD+14kTpRtPOAaj4ENC3rSLs7cunU=; b=CjtopWveA7RAEVLn1rMBJWDLmoNuV0g7oeGAqyj8RS4bBSnwQkPbzKjHF8q3SPShMl 47nHPdINPbo6xTo3wi3OM9qwP5q3A9TspM4L0cUV08lKnawct36SFsbmo64clile89er eiHa8VW+q2GXiYGiL1EKutahGWOoVZYOtsiU/oCelqaUkbq0MRU7YvMZaNsTYVN1P+b8 mGRGwmSDFRk8Hxu/0DcCfboBkTNnJT8FZXMyjGQNujtBfUvlAC+lzqaaVmrw7loHsBmM n+jYzKr+gLtsGn89rC0/RUzR9DvLpySCnmXS0sEXhlIoo2de3GxecPnS0ivbK6Y6gRVx dIAw== X-Forwarded-Encrypted: i=1; AJvYcCXSRcjDnlK860zSbkAQw5pNNqq01sU6DmeUBPWEzp/8fpyPELgxR0Jx7vG6bdmrl48jpM6SjVjQkg==@kvack.org X-Gm-Message-State: AOJu0YzPppQhUT4KAOmg/7S2JbbbCZiPdFCQq0NRVu1Po3eoeTpv7WMG Vp8dRaK+ZPo7CAX9bm3EtG/yA+jALgSdCkbovHITYu0ABrcuehNXAnX+ X-Gm-Gg: ASbGncudPORhbx7JsxF5XVU/2rTWgXUfs01pbCtk2IaUe3iv4Jx4zqKUNbczX07iEK5 OKNOu0EZsF6MwqV3IDHIfUgLB6dSa9zF6RL4i8cChmtb3GS91IjtKfUBGk6fZaa5DzsnkITW4xM QTj+ICxTptebgfjS16QLcjsB7xWPCMemd1Tqf+rw8EA2M97+FSmdQ0kH2UB8XFxXwbMNjWjk6Ks /JdGuTFvPpb6vzNAkAqXxKa7pogGgVoeVvCmY+FX5/zNVRXFhJYOcecq/y4z61OFNHrRj7OIqDK sEapfsWqmOEmeEE7pTveOmCSwWqdZzZAV46NBkgx+a4ge/Sm+gRq4UWUERW9XdwJjSYfzbu0tCz 1qcFxHKo1kmGyTGlPPbIgQChVlyRq9S1H01c= X-Google-Smtp-Source: AGHT+IGauQ39Mrtto9zdM0mTTamBDa/G8C/Yqj+C34TLbwDZJlxQ7GX6Kbqv9W/BPm289yBVCi/oZg== X-Received: by 2002:a17:906:9fcc:b0:ae2:a7aa:7efe with SMTP id a640c23a62f3a-ae7013408f4mr555974466b.58.1752321860234; Sat, 12 Jul 2025 05:04:20 -0700 (PDT) Received: from ?IPV6:2620:10d:c096:325::1ac? ([2620:10d:c092:600::1:b2ad]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ae6e7f292d2sm475605566b.72.2025.07.12.05.04.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 12 Jul 2025 05:04:19 -0700 (PDT) Message-ID: Date: Sat, 12 Jul 2025 13:05:37 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net-next v9 2/8] netmem: introduce utility APIs to use struct netmem_desc To: Mina Almasry , Byungchul Park Cc: 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, 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 References: <20250710082807.27402-1-byungchul@sk.com> <20250710082807.27402-3-byungchul@sk.com> Content-Language: en-US From: Pavel Begunkov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 2C4BE80006 X-Stat-Signature: xa9pfyaudxwo14ydhrqy6u8epucmko4e X-HE-Tag: 1752321861-468492 X-HE-Meta: U2FsdGVkX19jpdfkdH73xhI5Nydm3agRsCCX1CClyockKl6tv9WaaLNI2gcULGW2JB/q9DfwnrFBZcwoihcb95n3hZAHBwdGLRR3d0vDLh1AcfnsAYBX/OerDozsBnB/eUg3j7m311gxcOhHYGc/HbLYXsDEuP/0WQT8vO/Nfor/KefT+/uryAp5Vn5klz6fEaoaBqBOVF4mFbqR4Q2SeKazjLgI7qrYf0ry6hUM9NeX0ngHWQUQqEboOGKbnH/wr7jatcUbJNDOsSI3SW/rfBU3//kXAcyRpTLA277LA3/ha/wkfZaTdMjBdtBhyqYYpRaHESlSo+oM2pBNv84cSBg01oXD23b+j3pby9n2EWabo7bRQLCR1mUXlPEMNVycQpuWPn6qLos7O4vC8lT0KRFJw7joApd9pq8Vntsimh99NGhFCVYidlL30ZJfW2hV5y9E4vjOzymaKk5MD3lWfNDGTG2Ete1ScoZzGaf1xnCiftNt7AWsJ+/P4xF16dSM1GjnIpCZIC5dU2ISBg1j+4xPTyHLwf2r3qI+XvzUGEkDgzCGbYuVH6xO7HMEVBFYePB2RsNxDVB8nF/6SK7E3mkZ3XJG8XwB5OIttD7XdOAr4p0enOn59sh0dTUWTv7WjU5I2EsuFNEs0Z1tr6wISkSdiMOrTIACp9x2Xt3fOXEQ2qWAETxLTVCSlSx9qscGJA8IRvip9xwycxzYmrUP3JaW4DJ+pzg8B/du1PkyYz1IW4Z8GWuweIJ090xB1mKUNrTYNZhQ0amYgtWmlI6qtpLoc0Zm/isFW01Cq37BvFhHNcK+yEmlBNVfbiRRTFu7FpgpTy1hJRkt8gnBkseClyRLLdgab40DIsP50kO79bvoGSd2jyqnb1xTg4v6eCglwiNqhIyUF8G4QaTUjlm3WvfB+Kc2YUo14pIFa8m5+w2O/0OSVN08hy2m4lrfUnxjyv/9cEpf6p3CbsGOmFN 0xxZazZg WJkWRlP7hB1bWNG58+Ow/GvhoTQJVQZvhsTFd5gG0KXBAuBaFYfAQh7MDnJoiXSjRCclsaFGGO+mxVjEFHhIzOppDa+/gmbj7z6cY/9h8jnaFSNspJnaysjOIdrec0Vdiy1E6CSv8e0DDfuLdK6PQaeSdQ6N6yXZdSlwyIQ9r2rT99HO9ctvnq67WHuw7lSmyuMhBpEw0BeDPZ8yToz+ekFyJIc487NO9NFInrAspo8ZRVkPseznM7/SMQbW3GxpyrdxDJh6Yp0Ud14sJF0aUbD0Qr3pnq8hO2TS590bzymHxgCSNk8k8d/njeFPL670e3jvFDrDmcZnc2S7yrB3uFpZweNj230T/6+0m4ekaSS0IddLq2i8Taf59CX9GrDtk+s3GiBaF7Gf9np0OgZunld4xaPzAyR9Audgmhc5YSnns5W9VYT9FIbZyrEXG2ye4i6cMR3YKY+n5pLyKkV8lFMyw1GWXo3u9b8YtBpcpww5kjbE2n4ttfIJwwBFziuThIUGOGJoQlphdDoHa9KpaSkxMj6WI/OT1NlmkfLHLsRkC4Y+TPjfcEtli1qolPtfb5XLR8xDzr9zZ+tVotwbM0FmgnXtTi69WixZhqdqRyKTlu7jo0U/AGa0V1F2/Pja4NrfucEe815BEsRILhnQgaFrc5i8ayeY+dS1v/euqfh0E0AcRViuGqzumgowjVkpqhVEf2JkLm62N+yroktZmSvOUFgJbtmklszHy 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 7/10/25 19:11, Mina Almasry wrote: > On Thu, Jul 10, 2025 at 1:28 AM Byungchul Park wrote: >> >> To eliminate the use of the page pool fields in struct page, the page >> pool code should use netmem descriptor and APIs instead. >> >> However, some code e.g. __netmem_to_page() is still used to access the >> page pool fields e.g. ->pp via struct page, which should be changed so >> as to access them via netmem descriptor, struct netmem_desc instead, >> since the fields no longer will be available in struct page. >> >> Introduce utility APIs to make them easy to use struct netmem_desc as >> descriptor. The APIs are: >> >> 1. __netmem_to_nmdesc(), to convert netmem_ref to struct netmem_desc, >> but unsafely without checking if it's net_iov or system memory. >> >> 2. netmem_to_nmdesc(), to convert netmem_ref to struct netmem_desc, >> safely with checking if it's net_iov or system memory. >> >> 3. nmdesc_to_page(), to convert struct netmem_desc to struct page, >> assuming struct netmem_desc overlays on struct page. >> >> 4. page_to_nmdesc(), to convert struct page to struct netmem_desc, >> assuming struct netmem_desc overlays on struct page, allowing only >> head page to be converted. >> >> 5. nmdesc_adress(), to get its virtual address corresponding to the >> struct netmem_desc. >> >> Signed-off-by: Byungchul Park >> --- >> include/net/netmem.h | 41 +++++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 41 insertions(+) >> >> diff --git a/include/net/netmem.h b/include/net/netmem.h >> index 535cf17b9134..ad9444be229a 100644 >> --- a/include/net/netmem.h >> +++ b/include/net/netmem.h >> @@ -198,6 +198,32 @@ static inline struct page *netmem_to_page(netmem_ref netmem) >> return __netmem_to_page(netmem); >> } >> >> +/** >> + * __netmem_to_nmdesc - unsafely get pointer to the &netmem_desc backing >> + * @netmem >> + * @netmem: netmem reference to convert >> + * >> + * Unsafe version of netmem_to_nmdesc(). When @netmem is always backed >> + * by system memory, performs faster and generates smaller object code >> + * (no check for the LSB, no WARN). When @netmem points to IOV, provokes >> + * undefined behaviour. >> + * >> + * Return: pointer to the &netmem_desc (garbage if @netmem is not backed >> + * by system memory). >> + */ >> +static inline struct netmem_desc *__netmem_to_nmdesc(netmem_ref netmem) >> +{ >> + return (__force struct netmem_desc *)netmem; >> +} >> + > > Does a netmem_desc represent the pp fields shared between struct page > and struct net_iov, or does netmem_desc represent paged kernel memory? > If the former, I don't think we need a safe and unsafe version of this > helper, since netmem_ref always has netmem_desc fields underneath. If > the latter, then this helper should not exist at all. We should not > allow casting netmem_ref to a netmem_desc without first checking if > it's a net_iov. +1, and... > > To be honest the cover letter should come up with a detailed > explanation of (a) what are the current types (b) what are the new > types (c) what are the relationships between the types, so these > questions stop coming up. > >> +static inline struct netmem_desc *netmem_to_nmdesc(netmem_ref netmem) >> +{ >> + if (WARN_ON_ONCE(netmem_is_net_iov(netmem))) >> + return NULL; ... specifically this function should work with net_iov. -- Pavel Begunkov