Received: by 2002:a05:7412:b995:b0:f9:9502:5bb8 with SMTP id it21csp8124513rdb; Thu, 4 Jan 2024 21:55:27 -0800 (PST) X-Google-Smtp-Source: AGHT+IHQFBh2E6Nh/JbOr8mHR0tV0H13o4vywoCLw8BHFUQZWTfpuXtp4M+MF6Le/pjcL93aiEZd X-Received: by 2002:a50:c252:0:b0:557:13ad:bc8f with SMTP id t18-20020a50c252000000b0055713adbc8fmr514444edf.28.1704434127819; Thu, 04 Jan 2024 21:55:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704434127; cv=none; d=google.com; s=arc-20160816; b=ayut5LHTIK2z35VbUbsOkzNaSMFMff+XF/M/DIm0vXoClVx8aZmpeZygcaStwtMtsr ZPLrQskOkR+MAdbeLSoysqFWjjBH1YCvs2DeDgjxseAirpJUPjRxy8gGTtzVO/JrOG/I wTLYLeT/Eihjj0Rq+Eagk8GzuCdfoJABJ8s6p0Cv/0aBYt7EexNMUmeCLhlgVrcfUHpx nutkSwKrAwFFHHtcV2O/MAziawVtPgI2Uufmjf7CYc3TogFbfdfnAm6r12GDudOuwgnR qz/73p4WBAIh1BGwQr4MSZyWvvUA6oNMx+y7TW54TTFzkw+VXcNRqKKfsZFSb1C0paMY A1dg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id; bh=tuAKWD5PjWzhH/PKhNncIlJ7IiGuwYR+ty/5lMlqtWE=; fh=CXpVxMpAnJU6p5AYWsRVHITtvnKSWWFoAaOTM9AmpTY=; b=IdXrwhypNYTT1VKlq81L3FzAEVrFyx8j+7X5PDGT8ifA8Ng+7pw+ra8QamfQVjsY/7 4JfsUv8TcGoBm+NPZvG+ycAmNug3N96K/85bazJHgRzr/sSsPgcI/QiCxi4dAZomyyrF gDT1llw/b8cayDM2K+PGQyGHVOBXPAum5ak0sMD+6GrwS9+R/Faq4OAFFoaLIXBizm05 AWljrBZgLjfyb7BmFN86EGNh8J05adF+Hov6fQXSAqVG/3NApGf9BFr82T9RAyJGdVXP WUfS4S7V3fIcyvGyetwAFx7Erb+Ke/q4hVwPqcwxRY68C25lumKPWGUg1qTPlFk6yM+W B8WQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-17489-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-17489-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=hisilicon.com Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id w14-20020a50d78e000000b005537e61bd6dsi356402edi.406.2024.01.04.21.55.27 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Jan 2024 21:55:27 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-17489-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-17489-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-17489-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=hisilicon.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 91DE11F2331F for ; Fri, 5 Jan 2024 05:55:27 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 658085691; Fri, 5 Jan 2024 05:55:19 +0000 (UTC) X-Original-To: linux-kernel@vger.kernel.org Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A56E9610E; Fri, 5 Jan 2024 05:55:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=hisilicon.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=hisilicon.com Received: from mail.maildlp.com (unknown [172.19.163.252]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4T5t2L57llz1Q6vN; Fri, 5 Jan 2024 13:54:34 +0800 (CST) Received: from kwepemi500006.china.huawei.com (unknown [7.221.188.68]) by mail.maildlp.com (Postfix) with ESMTPS id 3FE8218006F; Fri, 5 Jan 2024 13:55:12 +0800 (CST) Received: from [10.67.120.168] (10.67.120.168) by kwepemi500006.china.huawei.com (7.221.188.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Fri, 5 Jan 2024 13:55:11 +0800 Message-ID: <3d4cdc2e-0053-f486-7323-72127027886f@hisilicon.com> Date: Fri, 5 Jan 2024 13:55:11 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.1.0 Subject: Re: [PATCH for-next 4/6] RDMA/hns: Support flexible pagesize Content-Language: en-US To: Jason Gunthorpe CC: Leon Romanovsky , , , References: <20231225075330.4116470-1-huangjunxian6@hisilicon.com> <20231225075330.4116470-5-huangjunxian6@hisilicon.com> <20231226085202.GA13350@unreal> <20240104202902.GD50608@ziepe.ca> From: Junxian Huang In-Reply-To: <20240104202902.GD50608@ziepe.ca> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To kwepemi500006.china.huawei.com (7.221.188.68) On 2024/1/5 4:29, Jason Gunthorpe wrote: > On Tue, Dec 26, 2023 at 05:16:33PM +0800, Junxian Huang wrote: >> >> >> On 2023/12/26 16:52, Leon Romanovsky wrote: >>> On Mon, Dec 25, 2023 at 03:53:28PM +0800, Junxian Huang wrote: >>>> From: Chengchang Tang >>>> >>>> In the current implementation, a fixed page size is used to >>>> configure the PBL, which is not flexible enough and is not >>>> conducive to the performance of the HW. >>>> >>>> Signed-off-by: Chengchang Tang >>>> Signed-off-by: Junxian Huang >>>> --- >>>> drivers/infiniband/hw/hns/hns_roce_alloc.c | 6 - >>>> drivers/infiniband/hw/hns/hns_roce_device.h | 9 ++ >>>> drivers/infiniband/hw/hns/hns_roce_mr.c | 168 +++++++++++++++----- >>>> 3 files changed, 139 insertions(+), 44 deletions(-) >>> >>> I'm wonder if the ib_umem_find_best_pgsz() API should be used instead. >>> What is missing there? >>> >>> Thanks >> >> Actually this API is used for umem. >> For kmem, we add hns_roce_find_buf_best_pgsz() to do a similar job. > > But why do you need to do something like this for kmem? It looked to > me like kmem knows its allocation size when it was allocated, how come > you need to iterate over all of it again? > > Jason > kmem was split into multiple small pages for allocation to prevent allocation failure due to memory fragmentation. And now we add this function to confirm whether these small pages have contiguous address. If so, they can be combined into one huge page for use, which is more likely when iommu/smmu is enabled. Junxian