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 D82D3C3DA4A for ; Thu, 1 Aug 2024 13:01:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6D3896B00D1; Thu, 1 Aug 2024 09:01:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 65E436B00D3; Thu, 1 Aug 2024 09:01:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4FC836B00D4; Thu, 1 Aug 2024 09:01:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 2FD266B00D1 for ; Thu, 1 Aug 2024 09:01:31 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id D0116120D8F for ; Thu, 1 Aug 2024 13:01:30 +0000 (UTC) X-FDA: 82403687940.07.284A62E Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by imf14.hostedemail.com (Postfix) with ESMTP id 25079100034 for ; Thu, 1 Aug 2024 13:01:25 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf14.hostedemail.com: domain of linyunsheng@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=linyunsheng@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722517223; 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=Fno7jynlRhR0MntB4PTcUruVkbDLRUwqhL/TfFy6/AQ=; b=xnS+cbD8R9v4GAAFe4FVVQWgJPtJgYHlQ0jMCE8r7vp2t6AMYA9Imi+65/isH439JD17qN KAGffr3Uyi4Euvonhw//7E5n1B5FTdiseUX7qSqYJ4kZQv9MJJodys914+zWbPLBtruFBK 0FlKu1Y5MKqrurpBO9j5KaJqCJc/lwE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722517223; a=rsa-sha256; cv=none; b=ITjQks/lR5e9nptQxyYe8bjB0tAZNB5o/oODyDuGlr7tswDeKZx8IyP2gQgk3l0RSLHrL4 XFvYg3rkcocAok482cuoKJmXMY1JziME8MapP37oMey/4Br30cwUEKgukriAclw8yqVNC0 u1+gqa8AbAkNWuCswCXfOR7Yi5IbZcE= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf14.hostedemail.com: domain of linyunsheng@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=linyunsheng@huawei.com Received: from mail.maildlp.com (unknown [172.19.163.174]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4WZTc54FXfzxW3F; Thu, 1 Aug 2024 21:01:09 +0800 (CST) Received: from dggpemf200006.china.huawei.com (unknown [7.185.36.61]) by mail.maildlp.com (Postfix) with ESMTPS id 996A7140109; Thu, 1 Aug 2024 21:01:22 +0800 (CST) Received: from [10.67.120.129] (10.67.120.129) by dggpemf200006.china.huawei.com (7.185.36.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Thu, 1 Aug 2024 21:01:22 +0800 Message-ID: <22fda86c-d688-42e7-99e8-e2f8fcf1a5ba@huawei.com> Date: Thu, 1 Aug 2024 21:01:21 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net-next v12 04/14] mm: page_frag: add '_va' suffix to page_frag API To: Alexander Duyck CC: , , , , , Subbaraya Sundeep , Jeroen de Borst , Praveen Kaligineedi , Shailend Chand , Eric Dumazet , Tony Nguyen , Przemek Kitszel , Sunil Goutham , Geetha sowjanya , hariprasad , Felix Fietkau , Sean Wang , Mark Lee , Lorenzo Bianconi , Matthias Brugger , AngeloGioacchino Del Regno , Keith Busch , Jens Axboe , Christoph Hellwig , Sagi Grimberg , Chaitanya Kulkarni , "Michael S. Tsirkin" , Jason Wang , =?UTF-8?Q?Eugenio_P=C3=A9rez?= , Andrew Morton , Alexei Starovoitov , Daniel Borkmann , Jesper Dangaard Brouer , John Fastabend , Andrii Nakryiko , Martin KaFai Lau , Eduard Zingerman , Song Liu , Yonghong Song , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , David Howells , Marc Dionne , Chuck Lever , Jeff Layton , Neil Brown , Olga Kornievskaia , Dai Ngo , Tom Talpey , Trond Myklebust , Anna Schumaker , , , , , , , , , , References: <20240731124505.2903877-1-linyunsheng@huawei.com> <20240731124505.2903877-5-linyunsheng@huawei.com> Content-Language: en-US From: Yunsheng Lin In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.120.129] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To dggpemf200006.china.huawei.com (7.185.36.61) X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 25079100034 X-Stat-Signature: mz5dh65k81xhdei1qhyfa1bn7oo6ebnd X-Rspam-User: X-HE-Tag: 1722517285-783651 X-HE-Meta: U2FsdGVkX18/GmTOJSWRlGNli+Gp2ERbjTT5we+ZwVzqcr/HRn6P6kXeVU9ILasyes5ORSddrbzFKtYeKH8ofMhEvF+75PbGL6rSfVU0eoZEGZWqQy/JKtx6P9oad7edx28xj5c9w2I1Pf7fyFJXjaYzLgC90Llw/kSsfeQFk1J/K6qk8ddeotNTjinvAbbw8x1jUCL1x8jcWyv8LgZB8UlWtpg4uAt5OhhsajWGt93D23zH7+BvwA2FPQEydpzHtmpCsBXHrD6pCvnbAawjl+UpqdF9QY+1T09jq1LUEanMpGOBnAQS5Uiljtc+R22LKvvr8nexSRb9/Qbd2Qy2TvegKv4Q68r+qDYGrCXT/PPiXMB92NxxhKna/92z2PqoeQq/8uoaV5zumGbgcu2qXZAWtqhpMf871MULuQMtJ0tw8JaP1BaiYoQ3Hn4qO6rmNO06MbG06EKt85cxuox4CB1fJbSH4BoPwy0x9gZQiP6P/78h+LUu4zmcqJw5eP/0utyG1hm7pBVsmoHeiokt6B/a3g3KBKTQ/agQU6e8etzW4sDDtO1TDZTgEsb7vEXPBUt/51Us3drHwYTZdvw+a3JioOgQOY8Qc5ZxLMJiYQ6AZcfJV+DqFhdmgvK517Uc0pZ839HD83rTgHvfQ1N/vaf+hTZ57yZXOilvW6vF88WfzjJQTLYmQ9q405CMFc7CKToD7FeAQTTLFJRxgiwCNeDvfZMU5qadi3dzGzkYucLho4vY9IEDsyHxQxAjDHi77Il7shvAm/f24VbqHarPuK/UfAcks4sjS5HcEOFVAYjuwtJXovyUa8oeh9aXSw6FFv4Dc6Ax81AWcWespVA8XBDaUkRquzB3QHugNH6zB0kPdX+pyfP7wuSVjX0j6iZCisC4eR5f6J4wGAAL3mVm7d+qWfVUyhhBZn9VedEvgT3Hi3Smoj/iyxgslS0h3Yil1UmnB+C6JGy32CoW0RA 8Y5bZ6z0 T0GKIBngtU4LG2Evt5mvBw6bNxnQoCemCSmIDPiUdTN/77PxqQaORW4dQdHWU25+0QG6O+bbTHNk3htSQia9uQhoCHaiULLjxpLHt5gj9ViceVVZ/LCc2w6Sn5+6c4c40OW70nfQwXvp+K6POffPRGNmV2A9ut1oduDHndW+Dsgqw5SLgTHMtNOlhXiNDTrjC/L2eqjsiP4pXaICgDzcybXlH/xdt8oT4Z75l4ZNDLmkVYmMpkwh5gav5zvpyrkEvbjuU0P2Mn1+vwNK5cFuLxunRr+fthqWPQ5cnFAWOIw69MptgkX2juQG/vCm5pMgKoJZJhwslX0eRZcUIgFLbJYWXnjbgjo842xtU92gL0bJZrIpfwMzwqzlmP9/Y2cAa52LeiONjh4cFgEB2/v6ZDh3NwiP/T+OPiI4T1Iw84bN47QJaxX1D0LAM9MPwq/ne6/oqi8G32bUBukmSDBsabYuwqDhX24iU/07T 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 2024/8/1 2:13, Alexander Duyck wrote: > On Wed, Jul 31, 2024 at 5:50 AM Yunsheng Lin wrote: >> >> Currently the page_frag API is returning 'virtual address' >> or 'va' when allocing and expecting 'virtual address' or >> 'va' as input when freeing. >> >> As we are about to support new use cases that the caller >> need to deal with 'struct page' or need to deal with both >> 'va' and 'struct page'. In order to differentiate the API >> handling between 'va' and 'struct page', add '_va' suffix >> to the corresponding API mirroring the page_pool_alloc_va() >> API of the page_pool. So that callers expecting to deal with >> va, page or both va and page may call page_frag_alloc_va*, >> page_frag_alloc_pg*, or page_frag_alloc* API accordingly. >> >> CC: Alexander Duyck >> Signed-off-by: Yunsheng Lin >> Reviewed-by: Subbaraya Sundeep > > I am naking this patch. It is a pointless rename that is just going to > obfuscate the git history for these callers. I responded to your above similar comment in v2, and then responded more detailedly in v11, both got not direct responding, it would be good to have more concrete feedback here instead of abstract argument. https://lore.kernel.org/all/74e7259a-c462-e3c1-73ac-8e3f49fb80b8@huawei.com/ https://lore.kernel.org/all/11187fe4-9419-4341-97b5-6dad7583b5b6@huawei.com/ > > As I believe I said before I would prefer to see this work more like > the handling of __get_free_pages and __free_pages in terms of the use I am not even sure why are you bringing up __get_free_pages() and __free_pages() here, as the declaration of them is something like below: unsigned long __get_free_pages(gfp_t gfp_mask, unsigned int order); void __free_pages(struct page *page, unsigned int order); And I add another related one for completeness here: extern void free_pages(unsigned long addr, unsigned int order); I am failing to see there is any pattern or rule for the above API naming. If there is some pattern for the above existing APIs, please describe them in detail so that we have common understanding. After the renaming, the declaration for both new and old APIs is below, please be more specific about what exactly is the confusion about them, what is the better naming for the below APIs in your mind: struct page *page_frag_alloc_pg(struct page_frag_cache *nc, unsigned int *offset, unsigned int fragsz, gfp_t gfp); void *page_frag_alloc_va(struct page_frag_cache *nc, unsigned int fragsz, gfp_t gfp_mask); struct page *page_frag_alloc(struct page_frag_cache *nc, unsigned int *offset, unsigned int fragsz, void **va, gfp_t gfp); > of pages versus pointers and/or longs. Pushing this API aside because > you want to reuse the name for something different isn't a valid > reason to rename an existing API and will just lead to confusion. Before this patchset, all the page_frag API renamed with a '_va' suffix in this patch are dealing with virtual address, it would be better to be more specific about what exactly is the confusion here by adding a explicit 'va' suffix for them in this patch? I would argue that the renaming may avoid some confusion about whether page_frag_alloc() returning a 'struct page' or returning a virtual address instead of leading to confusion. Anyway, naming is always hard, any better naming is welcome. But don't deny any existing API renaming when we have not really started doing detailed comparison between different API naming options yet.