From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) (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 4B8DF200A3 for ; Thu, 19 Dec 2024 13:39:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.188 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734615598; cv=none; b=I9sk469OOferQ0m994VyvPo88Sei/WM5LZuCeVJKGQD4h+8NjgpxL142EYY/E/AYesGI9eHf+v638N9gQV79HskXE2+HVVRkNpe0IBeKwGR1DdtqpKEuC8gksWrIIqUzVAhBN9HHZwTJYT/go5sqQEXrwpZCyxCyQeNJvYtYSpo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734615598; c=relaxed/simple; bh=+UbyuSBmOInwUBKmhO0P6ScYX+7sZpRA39PmXJETdaI=; h=Message-ID:Date:MIME-Version:From:Subject:To:CC:References: In-Reply-To:Content-Type; b=lJzti/UWyMnpJwKvgfqnNT4bgNXzsaeIuITvOjcyEiMnIKrSkvz8VRNu1TEzzF9m4mCcCEAyfZGM++xoeLM7HuhiKorSKdP5vbiSQ0XWWeULQDPQat3Bmf8jFTIHGSZglZ7hPOVIpeh3t4Uyq3cAsSRpONXaBwcIobWTkOfqYSc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; arc=none smtp.client-ip=45.249.212.188 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Received: from mail.maildlp.com (unknown [172.19.163.174]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4YDWml4jnPzFrcl; Thu, 19 Dec 2024 21:36:55 +0800 (CST) Received: from kwepemf100008.china.huawei.com (unknown [7.202.181.222]) by mail.maildlp.com (Postfix) with ESMTPS id 605D314010D; Thu, 19 Dec 2024 21:39:52 +0800 (CST) Received: from [10.174.179.163] (10.174.179.163) by kwepemf100008.china.huawei.com (7.202.181.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Thu, 19 Dec 2024 21:39:51 +0800 Message-ID: <0a84f8ce-80a3-c49a-28a1-0d3c5e8839fa@huawei.com> Date: Thu, 19 Dec 2024 21:39:50 +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.11.0 From: Zeng Heng Subject: Re: [RFC PATCH mpam mpam/snapshot/v6.12-rc1 v3 2/5] arm_mpam: Read monitor value with new closid/rmid pair To: Dave Martin CC: , , , , , "Wangshaobo (bobo)" References: <20241207092136.2488426-1-zengheng4@huawei.com> <20241207092136.2488426-3-zengheng4@huawei.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To kwepemf100008.china.huawei.com (7.202.181.222) On 2024/12/13 0:18, Dave Martin wrote: > Hi, > > On Sat, Dec 07, 2024 at 05:21:33PM +0800, Zeng Heng wrote: >> The MPAM driver statically assigns all reqPARTIDs to respective intPARTIDs. >> For the new rmid allocation strategy, it will check if there is an >> available rmid of any reqPARTID which belongs to the input closid, not just >> the rmids belonging to the closid. >> >> For a mixture of MSCs system, for MSCs that do not support narrow-partid, >> we use the PARTIDs exceeding the number of closids as reqPARTIDs for >> expanding the monitoring groups. >> >> In order to keep the existing resctrl API interface, the rmid contains both >> req_idx and PMG information instead of PMG only under the MPAM driver. The >> req_idx represents the req_idx-th sub-monitoring group under the control >> group. The new rmid would be like: >> >> rmid = (req_idx << shift | pmg). >> >> The mapping relationships between each group's closid/rmid and the >> respective MSCs' intPARTID/reqPARTID/PARTID are illustrated: >> >> n - Indicates the total number of intPARTIDs >> m - Indicates the number of reqPARTIDs per intPARTID >> >> P - Partition group (control group) >> M - Monitoring group >> >> Group closid rmid.req_idx (req)PARTID MSCs with narrow-partid MSCs without narrow-partid >> P1 0 - 0 intPARTID_1 PARTID_1 >> M1_1 0 0 0 ├── reqPARTID_1_1 ├── PARTID_1_1 >> M1_2 0 1 0+n ├── reqPARTID_1_2 ├── PARTID_1_2 >> M1_3 0 2 0+n*2 ├── reqPARTID_1_3 ├── PARTID_1_3 >> ... ├── ... ├── ... >> M1_m 0 (m-1) 0+n*(m-1) └── reqPARTID_1_m └── PARTID_1_m >> >> P2 1 - 1 intPARTID_2 PARTID_2 >> M2_1 1 0 1 ├── reqPARTID_2_1 ├── PARTID_2_1 >> M2_2 1 1 1+n ├── reqPARTID_2_2 ├── PARTID_2_2 >> M2_3 1 2 1+n*2 ├── reqPARTID_2_3 ├── PARTID_2_3 >> ... ├── ... ├── ... >> M2_m 1 (m-1) 1+n*(m-1) └── reqPARTID_2_m └── PARTID_2_m >> >> Pn (n-1) - (n-1) intPARTID_n PARTID_n >> Mn_1 (n-1) 0 (n-1) ├── reqPARTID_n_1 ├── PARTID_n_1 >> Mn_2 (n-1) 1 (n-1)+n ├── reqPARTID_n_2 ├── PARTID_n_2 >> Mn_3 (n-1) 2 (n-1)+n*2 ├── reqPARTID_n_3 ├── PARTID_n_3 >> ... ├── ... ├── ... >> Mn_m (n-1) (m-1) (n-1)+n*(m-1) = n*m-1 └── reqPARTID_n_m └── PARTID_n_m >> >> Based on the example provided, the conversion relationship between >> closid/rmid and (req)PARTID/PMG is: >> >> (req)PARTID = (rmid.req_idx * n) + closid, >> PMG = rmid.pmg. > > It seemed more natural to me for the PARTIDs assigned to a particular > CLOSID to be consecutively numbered (see [1]), though it works either > way. > > Otherwise, the approach makes sense. Yes, I agree with your point and it would be included in the next version soon. Best Regards, Zeng Heng