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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 758C5C531DC for ; Thu, 15 Aug 2024 03:00:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:CC:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=tVGgtAeIU797BlAn1ZjEHpddsnFBZFqZOqJ+L03TlXk=; b=PrpR+pIQ9nr6iHLIc4gKTuuTwz V4B70FaCgegDHHsSVcLrgEQXjmbJLLQKtIT0oGn2qSuvV0xl5kt4KXWIUP/46lz5FtKcpjOIZXRCn WIzkwfZ0+cyqT+cc7tbhpXkCY46olWnNRZcaF74dCirBA2UQMoxkKB64YiIxTGakOeQXMt63+sA5j LCOA0x9XI/Dfl95yaogj8u0g21JT6cGh+o05pXoui2H3FJ7KmooAh/jvBsC2syNOoZUQg2zS3Two0 pe4g3UTcekuGu/eeo7NVp+qOr2AvMcqZSb//RrLxy6SGP5jelsBmTqgN1RHEeXJHeCZYNXApB9drn pLOBDdGw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1seQie-00000008rvr-0ei6; Thu, 15 Aug 2024 03:00:08 +0000 Received: from szxga05-in.huawei.com ([45.249.212.191]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1seQiZ-00000008ruE-0o0c; Thu, 15 Aug 2024 03:00:05 +0000 Received: from mail.maildlp.com (unknown [172.19.163.17]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4WkqXP209yz1HGKB; Thu, 15 Aug 2024 10:56:53 +0800 (CST) Received: from dggpemf200006.china.huawei.com (unknown [7.185.36.61]) by mail.maildlp.com (Postfix) with ESMTPS id 5EBEA1A0188; Thu, 15 Aug 2024 10:59:58 +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, 15 Aug 2024 10:59:57 +0800 Message-ID: <676a2a15-d390-48a7-a8d7-6e491c89e200@huawei.com> Date: Thu, 15 Aug 2024 10:59:57 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net-next v13 04/14] mm: page_frag: add '_va' suffix to page_frag API To: Alexander H Duyck , , , CC: , , Subbaraya Sundeep , Chuck Lever , Sagi Grimberg , 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 , 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 , Jeff Layton , Neil Brown , Olga Kornievskaia , Dai Ngo , Tom Talpey , Trond Myklebust , Anna Schumaker , Shuah Khan , , , , , , , , , , , References: <20240808123714.462740-1-linyunsheng@huawei.com> <20240808123714.462740-5-linyunsheng@huawei.com> Content-Language: en-US From: Yunsheng Lin In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.120.129] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To dggpemf200006.china.huawei.com (7.185.36.61) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240814_200003_694108_9666E13C X-CRM114-Status: GOOD ( 20.06 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org On 2024/8/14 23:49, Alexander H Duyck wrote: > On Thu, 2024-08-08 at 20:37 +0800, 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 >> Acked-by: Chuck Lever >> Acked-by: Sagi Grimberg >> --- >> drivers/net/ethernet/google/gve/gve_rx.c | 4 ++-- >> drivers/net/ethernet/intel/ice/ice_txrx.c | 2 +- >> drivers/net/ethernet/intel/ice/ice_txrx.h | 2 +- >> drivers/net/ethernet/intel/ice/ice_txrx_lib.c | 2 +- >> .../net/ethernet/intel/ixgbevf/ixgbevf_main.c | 4 ++-- >> .../marvell/octeontx2/nic/otx2_common.c | 2 +- >> drivers/net/ethernet/mediatek/mtk_wed_wo.c | 4 ++-- >> drivers/nvme/host/tcp.c | 8 +++---- >> drivers/nvme/target/tcp.c | 22 +++++++++---------- >> drivers/vhost/net.c | 6 ++--- >> include/linux/page_frag_cache.h | 21 +++++++++--------- >> include/linux/skbuff.h | 2 +- >> kernel/bpf/cpumap.c | 2 +- >> mm/page_frag_cache.c | 12 +++++----- >> net/core/skbuff.c | 16 +++++++------- >> net/core/xdp.c | 2 +- >> net/rxrpc/txbuf.c | 15 +++++++------ >> net/sunrpc/svcsock.c | 6 ++--- >> .../selftests/mm/page_frag/page_frag_test.c | 13 ++++++----- >> 19 files changed, 75 insertions(+), 70 deletions(-) >> > > I still say no to this patch. It is an unnecessary name change and adds > no value. If you insist on this patch I will reject the set every time. > > The fact is it is polluting the git history and just makes things > harder to maintain without adding any value as you aren't changing what > the function does and there is no need for this. In addition it just I guess I have to disagree with the above 'no need for this' part for now, as mentioned in [1]: "There are three types of API as proposed in this patchset instead of two types of API: 1. page_frag_alloc_va() returns [va]. 2. page_frag_alloc_pg() returns [page, offset]. 3. page_frag_alloc() returns [va] & [page, offset]. You seemed to miss that we need a third naming for the type 3 API. Do you see type 3 API as a valid API? if yes, what naming are you suggesting for it? if no, why it is not a valid API?" 1. https://lore.kernel.org/all/ca6be29e-ab53-4673-9624-90d41616a154@huawei.com/ > makes it that much harder to backport fixes in the future as people > will have to work around the rename. >