From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.11]) (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 39EE33F44D3 for ; Wed, 3 Jun 2026 03:55:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=192.198.163.11 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780458951; cv=fail; b=bNmAmlgjJ3wj4RUy9g4N8Rm08xBhuPV4zUA7xbcs+ABRvz4OdlwjTs8r67r2kNm3zBH3nFsHZ5r8U8Fv4XfJe8Bu8hiY03zykSyU0TGFn4c/3F9ZhgPTI69rWq3q/1K5faDypyiXV4Qn52N9O3gcLJ+yTYDcTPhygNv1369cCr0= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780458951; c=relaxed/simple; bh=pai/wJBwHhWEJsPo47L7BATiZbPRHlwnJviYCDNOsH8=; h=Message-ID:Date:Subject:To:CC:References:From:In-Reply-To: Content-Type:MIME-Version; b=jAJ9S9p3X5NU0iFhFU137h3Macg73SPI+294nvKD9P3xppnmvjMtpeW0NYMFOM6WztWuR8caQysH0fE3h+cOgEwXEeHxSRO284rmn4dR9fu/0mHHlVRnTC9x/0vyiT05NxXV8YV9AsACYRo15OojIH4r4kjZmPOzrCMXEHj9nDc= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=iEzH1rQM; arc=fail smtp.client-ip=192.198.163.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="iEzH1rQM" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1780458948; x=1811994948; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=pai/wJBwHhWEJsPo47L7BATiZbPRHlwnJviYCDNOsH8=; b=iEzH1rQM5wPKNBLr+VwlS15aKmZpi85IjrA+ZhhxZGEWw/1DBxbWTCKp swKK/dwBbrT7+bxS0A1VWMRUMZCx6xtF/18e13zSDrl7KOjWxAQTS8dEi psNf6b21IYoUhpZePABJeaDiq8lj4C2YkL++XaBqgRWhuXYrD/sKdWejH HZUpKlrzX0LDUDTLMRTlU7S7he/4mVUtgGdE5I7/MUSramBtQ+rb2CX/7 ERvdOgNj2N0asrp3CLkQEjyMM9UzRV3ZTms0lSwM/L1XuGRhQ8CP+cSXy CGREKmZnuKgxZwuZXF84P7BH40MHrNQC6eX5v24Kvto/kFDuMWy5ZtSBp w==; X-CSE-ConnectionGUID: e3l2fCeNRv+P9g6Y8bSbfw== X-CSE-MsgGUID: qZyxD88kRs2eKp+uNxoxAg== X-IronPort-AV: E=McAfee;i="6800,10657,11805"; a="91829314" X-IronPort-AV: E=Sophos;i="6.24,184,1774335600"; d="scan'208";a="91829314" Received: from fmviesa005.fm.intel.com ([10.60.135.145]) by fmvoesa105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Jun 2026 20:55:48 -0700 X-CSE-ConnectionGUID: JV77zm2qQXKwBzVmlGzG7Q== X-CSE-MsgGUID: W+dCNJEfSRuT9tqVxk5jhA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.24,184,1774335600"; d="scan'208";a="249176697" Received: from fmsmsx901.amr.corp.intel.com ([10.18.126.90]) by fmviesa005.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Jun 2026 20:55:47 -0700 Received: from FMSMSX902.amr.corp.intel.com (10.18.126.91) by fmsmsx901.amr.corp.intel.com (10.18.126.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.37; Tue, 2 Jun 2026 20:55:47 -0700 Received: from fmsedg903.ED.cps.intel.com (10.1.192.145) by FMSMSX902.amr.corp.intel.com (10.18.126.91) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.37 via Frontend Transport; Tue, 2 Jun 2026 20:55:47 -0700 Received: from MW6PR02CU001.outbound.protection.outlook.com (52.101.48.43) by edgegateway.intel.com (192.55.55.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.37; Tue, 2 Jun 2026 20:55:42 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=nynyIX+VwP1nkPBZ4A9zja3H/kfCr6NoJKbj6lGiM8SKFQseFKKdUytny4JBxUK2nhfdV5qeAvJs+dv9kHqV5Hegx7209dPNqFsvpe8ktRRAvC6vRtqi86Sv9eS70pZUhRCbpL3N7Vt27SyRnfllJfX1xNXIpbjn7kOJ7XHmhf8hbdWi3R6uaKUKTgFKPHlDyHtT/x9kq248bC5Tyt5ApyLW++hNY6bwYJSvsDQEodLHH2uZIE8e8NiT0kP5/COONfGmkz3Zf+U2QTuTCe3bZWPkslVEhwzrdms1jihodbQTH0AIZrv5oGTBEIIEvSnF7Hb6x6LANF5pyW1zFyGtww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=mL6YkF5bM6LO0E/5HxS6836CYvdKxUDmufcsSM3CYmE=; b=GNAuaYceqZ38MPa226jbOKg5dqJNAkHOTkgl6f6OozUep8EgDagSg0YUk9cF7EnQc6uKh4U9MwnnxqmCUnnUlUmPdkKj0olmHKhhiEAjwPl+jCj2clrO9hr9/GuWq2Xg+GVQdg95daNee/3sumjJTxIchqyJ1yl39KfSbXYph4S+evZ/btXRKAHtWEILi+ILOz3IqFskvUx6hLCRks3fnKzuU1Es5D0mhCK87wpc7v9cNYqIa6bPs8IVropjHxFvAv7oUTh2P7f6b+8e48pdZivYyookqRDrLM3aT95u2ju9i4E/EfuoomqMuPbYhCOyy1M1SnBK3LA+pYBLV5+f2g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; Received: from SJ2PR11MB8370.namprd11.prod.outlook.com (2603:10b6:a03:540::20) by IA0PR11MB7933.namprd11.prod.outlook.com (2603:10b6:208:407::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.92.7; Wed, 3 Jun 2026 03:55:34 +0000 Received: from SJ2PR11MB8370.namprd11.prod.outlook.com ([fe80::b6cf:ce77:3cdf:7cc]) by SJ2PR11MB8370.namprd11.prod.outlook.com ([fe80::b6cf:ce77:3cdf:7cc%4]) with mapi id 15.21.0092.006; Wed, 3 Jun 2026 03:55:34 +0000 Message-ID: <6fc01c5a-aeee-41ea-ad02-67747ae80d03@intel.com> Date: Tue, 2 Jun 2026 20:55:32 -0700 User-Agent: Mozilla Thunderbird Subject: Re: [RFC] mpam,x86,fs/resctrl: Generic schema description Proof of Concept To: "Moger, Babu" , Babu Moger , Tony Luck , Ben Horgan , James Morse , Dave Martin , Drew Fustini , Fenghua Yu , Chen Yu CC: Borislav Petkov , Thomas Gleixner , "Dave Hansen" , Peter Newman , "x86@kernel.org" , "linux-kernel@vger.kernel.org" References: <188147f4-db82-4aa6-adb0-d1a26565cfdd@amd.com> <533f6b30-6d6d-4962-a7f5-b7b83d888f6b@intel.com> <81f27656-2c56-4419-95cc-54424592c1e7@amd.com> Content-Language: en-US From: Reinette Chatre In-Reply-To: <81f27656-2c56-4419-95cc-54424592c1e7@amd.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-ClientProxiedBy: MW4PR03CA0342.namprd03.prod.outlook.com (2603:10b6:303:dc::17) To SJ2PR11MB8370.namprd11.prod.outlook.com (2603:10b6:a03:540::20) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ2PR11MB8370:EE_|IA0PR11MB7933:EE_ X-MS-Office365-Filtering-Correlation-Id: d79d7957-15b2-4ddd-0dcf-08dec123f6d0 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|1800799024|7416014|921020|3023799007|18002099003|22082099003|56012099006|11063799006|5023799004|4143699003; X-Microsoft-Antispam-Message-Info: umT9wQS2DtPobeFX896Fqiej5QknFVUUFHQBKGsfsthpEe8k0Gn8i4tmRSEfhA0H0JrP90qAOzo4mgZz4y3AoV9PuAmBslqDE9u5hWMixzpcE9RRLhsjb5FPeHctUsopKLAiwdB3OKTxXrqRpI5foqtcBBXLiyj2wjdN5wvRDKMzWOxWlF8PY9l7pXuPGNI7kS8j1TtbpWTdB/CXxEflKNOv1317uZH8nWl10MQzlBGQqDiz0AcslZ5rVlWOROIAHdbvtbxV2ACModQ3YCR5sWzvTj0vVSJxfiHK9MjWmGURtVQRwltq3Zr7oC+f3kgxV6ZpQdF1LFpzlVS4yoz5w2ZEeQOewU2+OKfh+AmlG+mGx65Gn66j77U4//3eyPzVcNRXlbkiIq6Ua6SJ+e0R36bLlDpwqMNwHtT7FXUhYwYIduZH/bgfGa0OHTC56MRWm/kdBRL3rtPpuRCOAx/+c7CHayQgt7Y6pC0bmLPbccOfV/FDgDqZaJrwUuSefg1/tploMG4ZwITYqGRy5iNAEUIj+8TNwHZs8lIrz1/j40GGGGhCbvLlTdegOjDjEiT+OwjhtFmfn4MvOFDAoVdaA2HvS2V5JW158Sg8DnoQrh5qkfApPpPahklLLoI6dZrzXj65+XlNBqWR4HffrkwOutfq1WhluARgqjnX+DZE0BO9KVP9Uz1WFe3ZriJPNHHo X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SJ2PR11MB8370.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(7416014)(921020)(3023799007)(18002099003)(22082099003)(56012099006)(11063799006)(5023799004)(4143699003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MWZwVUFnQlNXdmlqYURWMU1Jc05TM1dLOTJ5bjFGRGN4S09FeFZpRWVxcFkx?= =?utf-8?B?cXlRTlhRSlRVUllQNENQd2VYQjBPQjhlU1ZSRDJOQmthZ3NBemNGbEUzSnIx?= =?utf-8?B?QzRBY2NRM1gzaGkxaFdRc29NQlg5bHFEZmlRK01hMUxZTzB1dXNVdWxQcjhu?= =?utf-8?B?bk5va1FVNHJabXdrMVhYbkJYL1VMRjdVdHc5UllXYms5SXBsNzBoQ0hORVI5?= =?utf-8?B?UzhHaUYzSFNYSldlVnRaYU9UcEJaM0Z6cFpMRjcxSTZtek1zV0swRUUvMVlM?= =?utf-8?B?S014Q2tUaGpRZDRvbncwQkRhRlBzdHJpblBtbEMvMEFVQjZ4T2J4ZFJnb211?= =?utf-8?B?VTEwOFJTTGJzcmlBek9jay9JZ3ZkTXBmd3lWRTVVdjhGY3BKakFOZnNtQW5C?= =?utf-8?B?Y3FWaHBmMmhvK0h1NkNvU1BzVVZkczlxazVJaHJyem44eE54V0kwbjBrKzNX?= =?utf-8?B?aUxYUlByYVBHTFNQOXBacm5Td0FVNTRYSjVmaExHajZrUUMyWnFnS1kzaGdH?= =?utf-8?B?OTVSRkxWWTF6VVJJeTRha3kyTTdtZFhTWjF3ajFhQ09NeUhRd200TXMyQXVW?= =?utf-8?B?b1NFTktkaVhVMVZaUTBYR0NXUFo1RGgyWElqRElPM3NNVitsVTJnckVTUWhv?= =?utf-8?B?cHJkUG92NEo1WENEOWdVeU1xR0xQZy8vdTFYWTV3ODJ1QnJrTmYrL3R6cXIv?= =?utf-8?B?d2Vpc0VqUkhSQmFqaVJUdWFnYVp4Y0FkNnozWG9YWWJpN0tBeW54ZjNrK2RY?= =?utf-8?B?WE1yNm40S0djMWdkamFaa1ZXOFo2VUk2QmVFSGxkN25ZRFV6WEorL211U3pS?= =?utf-8?B?UVYyeUtwclArK1FSeVNqU2pBY0J3ZzhVQ2gyd3E1MkRjUFlKdXh6UCtwVUZw?= =?utf-8?B?MkJzSmRQb1FoVEFEWldKT3paSEF3RTZuMElpd0xLZWUvWm5LQTRvcEFhZHFJ?= =?utf-8?B?VlBRTDlWclNhUlhWcEt4akhNZ2MrQUlrV09DbE1RZmswNVcxK1BzSytMeE9I?= =?utf-8?B?WkFmWjcyeW15RDFFNUc2Nm9xM05YM3V5Sko4bC9sSXFJcjUvYVNvU2x4L3Jt?= =?utf-8?B?aFZiQjMwK2xIcWlGSDR2Q0lIQlZGa2JCS1BjcGJBdGhVM0xjOG84VWpaeEFw?= =?utf-8?B?amYzM0dkS3lYMVFZbUxTYm10dlJXYnBBZ1luYVRLVkxNZmNqMjdHcVZ6Zmh3?= =?utf-8?B?UjJHT1lKNmVkclRjSlZyM2Uvek5xM25aZkxLOTlWQStxSVBLc0U5SWc5dEFo?= =?utf-8?B?eGZOTmJtdy9OMjhya3EvV01uYkNWY0ZIamMwMmZtdER0WmcrVXdnZWJDSFBC?= =?utf-8?B?SE82WWZsY2ZNVHR2TnJ4UDhXd2FqZmpOS1NsU0pISWpRaVhxQjU4aFAzbGFz?= =?utf-8?B?czRHQkU4aGU4cXJUQlk3a0JOZVNWMUhMV1NjL3Q4Uy92Q0daS1lsUlN1V1V3?= =?utf-8?B?aHRtUnhhSGd5ZDNPVGpJaFhseGtLWDcyQjdJTWlGL2oyd0VmWHhNemtOTlkv?= =?utf-8?B?SjJvTnZsZG5ybGF1bVFwQ3pjSVUvOEJjNVBzYVZHWVJSWkIyOFd0allaampp?= =?utf-8?B?WEcyM0RIakR4d0JWZUNlRlZJbm03N2szZ0wyTVVjeHBuVDhZZkxHWkJZOGdJ?= =?utf-8?B?UHZBTnhldmdtT3lVR2dpN1FiU0JiWjZsWGZQZTRYMnRIMElnTC9oOXdrRXQ5?= =?utf-8?B?dWVlQmJLZHUvZ2RLbEFTa3Y2aHVOSEFKSUFJa3R4MnNUaFkxUXErZy81MDA0?= =?utf-8?B?V3BYeWtzWWRNdENpaFo2VGxrWVU5azB3d2VpbmE0d1JKblFMdThtSldtYnNV?= =?utf-8?B?Yk1yOUNXNU1DWFZlK2JRZDR0aDg5NkVsOUJEM00rVUI5Wk8vNWl1SnViRWdu?= =?utf-8?B?MmU0a2htRWxKVHdNZFMxckowRlEvOWt2eFVFdmtzeWJ1UEVRWnc2bkVGUkp1?= =?utf-8?B?RE9PeWtHcCtscnZ6dzZIdWRld1ZvcDBGcENXcWpLV0c0SjFiZUJva2hjRE9N?= =?utf-8?B?TmUvdHVRY3RZSXpGMFZxcWI5MmZ0L3k5Z3A4dmdLNENsaXIvRlRIUlV3Kytj?= =?utf-8?B?dW1sL3Zmb0d5R01nRUZxYjdEbkNwd3hGTjZSa0dEVnpWOEt5emg2SWNzUjVu?= =?utf-8?B?d3NhWFd5dHpQNFJQNVY0Zmw2dURWaUFreS9QSTlmZktsMTVSZEhWMzZGd2dh?= =?utf-8?B?akRlV3dZRnE4VlNTcVVqV3ZZTGJ4Nng3K1ZxdWJSVVl2ZHNZT0oyUWVEVVhE?= =?utf-8?B?b3BUWFRSZkxXK3B5bXBmU0hYNy9iOHlteUtrYjlNdXFCZTZIVlFuck16SHF6?= =?utf-8?B?c0NHUkg1VURvLytqWWRJYkpxRmFyQXZic1VNNUdDTWpuQ1R2eG1WenhJT1Vz?= =?utf-8?Q?u2PHHGjxRFS8oA5Y=3D?= X-Exchange-RoutingPolicyChecked: DNthh5vx5boi72VMiYxbHEgZDVilVa13H7F3kmUfxOhm1+k7k12jkKuZaj2SLJNY5veQq4+r2H8sFxidLnV7efFl1UpBOzLbxnUJpBgIwKNzY5USPsBIni81ks75NoRZ+hIjLo4DBTLuRHghg90DZ4A8EK96rC4U6NXZY/I3SOSzVZyD3L7V2iIPrf7KjIiC/JVCluMXt2d92JhcgLUW5u+BwSnf9NqUXidL3l09iuaV14ss/tkV6ynOmyJwI0cqO8M3fFA4uj2SLq/oY6aRb00uDs05ClcPzsCYX8jsz8YrVFQpTaIccAyNNw5Vq+uKB53+Fgje9HJoHMnky3gVDg== X-MS-Exchange-CrossTenant-Network-Message-Id: d79d7957-15b2-4ddd-0dcf-08dec123f6d0 X-MS-Exchange-CrossTenant-AuthSource: SJ2PR11MB8370.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jun 2026 03:55:34.3946 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: D9I15nQ9MkonZbdgYEt8xSgPuKa4CRyKmhmdQSsN2AhaA2x6cQGO346tx+/IcoMlOTUDi4UOS8HDVp+Ap+caJF+WhYvEMVn1O9Vd5WgK4jc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR11MB7933 X-OriginatorOrg: intel.com Hi Babu, On 6/2/26 6:14 PM, Moger, Babu wrote: > Hi Reinette, > > On 6/2/2026 5:56 PM, Reinette Chatre wrote: >> Hi Babu, >> >> On 6/2/26 1:23 PM, Babu Moger wrote: >>> Hi Reinette, >>> >>> For some reason, I couldn’t find your patch on lore.kernel.org: >>> https://lore.kernel.org/lkml/?q=Reinette+Chatre >> >> How about: >> https://lore.kernel.org/lkml/aab804b9-e8b5-40ad-a85b-af7033391243@intel.com/ > > Yes. It works. But, I used to find patches using the names. It did not work this time. Interesting. When I run your lore query the first email from this thread is among the results. > >> >>> >>> I eventually located it here: >>> https://sashiko.dev/#/message/aab804b9-e8b5-40ad-a85b-af7033391243%40intel.com >>> >>> Thanks for sharing the patches. I’m still reviewing them. >>> >>> I was able to build and boot the kernel and can see the MIN and MAX controls. After moving your test code to __rdt_get_mem_config_amd(). >> >> Thank you very much for trying it out. >> >>> On 5/29/26 13:06, Reinette Chatre wrote: >> >> ... >> >>>> Primary resctrl fs data structure changes >>>> ========================================= >>>> >>>> Introduces a control represented by struct resctrl_ctrl that looks as below. To make >>>> the changes easier to follow I kept some of the original names to help communicate >>>> where familiar data structures land. >>>> >>>> What to notice about a control is that it has some common properties required >>>> from all controls (scope, type, etc.) and then depending on the type of control >>>> (RESCTRL_CTRL_BITMAP or RESCTRL_CTRL_SCALAR) there are type specific properties. >>>> >>>> /** >>>>    * struct resctrl_ctrl - A resource control >>>>    * @entry:    List entry of rdt_resource::controls >>>>    * @scope:    Scope of the resource that this control allocates >>>>    * @domains:    RCU list of all control domains >>>>    * @type:    The control type that determines the properties of the control, >>>>    *        format string for displaying control values to user space, and >>>>    *        parser of control values provided by user space. >>>>    * @name:    Name of the control. Appended to final resource name >>>>    *        (rdt_resource_final::name) to create final schema entry. >>>>    *        Specifically, "rdt_resource_final::name"_"resctrl_ctrl::name". >>>>    *        For example, with resource name "MB" and control name "MAX" the >>>>    *        schema entry will be "MB_MAX". >>>>    * @cache:    Cache allocation control properties. >>>>    * @membw:    Bandwidth control properties. >>>>    */ >>>> struct resctrl_ctrl { >>>>      struct list_head    entry; >>>>      enum resctrl_scope    scope; >>>>      struct list_head    domains; >>>>      enum resctrl_ctrl_type    type; >>>>      enum resctrl_ctrl_name    name; >>>>      union { >>>>          struct resctrl_cache    cache; >>>>          struct resctrl_membw    membw; >>>>      }; >>>> }; >>>> >>>> Two members summarize how this new structure fits into the rest of resctrl: >>>> a) resctrl_ctrl::entry >>>>      Since a resource can support multiple controls there is a new list >>>>      in struct rdt_resource named "controls" that contains the list of all >>>>      controls supported by the resource. >>>> b) resctrl_ctrl::domains >>>>      Instead of the list of control domains belonging to a resource they >>>>      now belong to the control self. By doing so resctrl can support resource >>>>      controls at different scope for the same resource. This is intended to >>>>      support some upcoming MPAM and RISC-V usages. >>>>      >>> >>> I like the idea of supporting multiple controls for each resource. >>> >>> With these patches, now we have one list containing all the controls. >>> >>> However, in case of RDT_RESOURCE_L3, we have two lists "mon_domains" and "controls". mon_domains list deals with monitoring and control deals with control parts(multiple). >>> >>> Have you thought about making the list("control") generic so that the control can be monitoring also. It will just one list containing multiple controls or monitor. >> >> The control list adds an additional layer of abstraction just for control management, >> independent from monitoring. The mon_domains list is unchanged while each control now >> has its own ctrl_domains list. >> >> Here is an attempt to visualize how a resource with two monitoring domains, and two controls, >> each with two control domains end up being managed: >> >> +-------------------------+ >> | struct rdt_resource     | >> +-------------------------+ >> | ...                     | >> | controls (list_head)    |---------+ >> | mon_domains (list_head) |---+     | >> | ...                     |   |     | >> +-------------------------+   |     | >>                                |     | >>    +---------------------------+     | >>    |                                 | >>    v                                 v >> +-----------------------------+   +-------------------------+ >> | struct rdt_l3_mon_domain #1 |   | struct resctrl_ctrl #A  | >> +-----------------------------+   +-------------------------+ >> | rdt_domain_hdr              |-+ | entry (list_head)       |       +----------------------------+ >> | ...                         | | | domains (list_head)     |------>| struct rdt_ctrl_domain #A1 | >> +-----------------------------+ | | ...                     |       +----------------------------+ >>                                  | +-------------------------+       | rdt_domain_hdr             |---+ >>    +-----------------------------+   |                               | ...                        |   | >>    | (next)                          | (next)                        +----------------------------+   | >>    v                                 v                                                                | >> +-----------------------------+   +-------------------------+       +----------------------------+<--+ >> | struct rdt_l3_mon_domain #2 |   | struct resctrl_ctrl #B  |       | struct rdt_ctrl_domain #A2 | >> +-----------------------------+   +-------------------------+       +----------------------------+ >> | rdt_domain_hdr              |   | entry (list_head)       |       | rdt_domain_hdr             | >> | ...                         |   | domains (list_head)     |----n  | ...                        | >> +-----------------------------+   | ...                     |    |  +----------------------------+ >>                                    +-------------------------+    | >>                                                                   | >>                                      +----------------------------+ >>                                      | >>                                      v >>                                    +----------------------------+ >>                                    | struct rdt_ctrl_domain #B1 | >>                                    +----------------------------+ >>                                    | rdt_domain_hdr             |---+ >>                                    | ...                        |   | >>                                    +----------------------------+   | >>                                                                     | >>                                    +----------------------------+<--+ >>                                    | struct rdt_ctrl_domain #B2 | >>                                    +----------------------------+ >>                                    | rdt_domain_hdr             | >>                                    | ...                        | >>                                    +----------------------------+ >> >> resctrl used to manage single domains that are capable of both monitoring and control >> but this was split to support scenario where monitoring and control of a resource are >> done at different scope. See >> cd84f72b6a5c ("x86/resctrl: Prepare for different scope for control/monitor operations") >> >> This feature further expands the difference between monitoring and control since now there >> can be multiple instances of a control domain (one per control) associated with a resource >> while monitoring still just supports one monitoring domain per resource. >> >> I thus cannot see how this can be accomplished with a single list. Could you sketch out >> what you have in mind? >> > > Thanks for the sketch. It makes it much more clear. > > mon_domains directly maintains a list of monitoring domains, whereas controls maintains a list of control objects, each of which owns its own domain list. > > I was thinking, one possibility would be to make mon_domains follow a structure similar to controls, allowing both to be represented through a common top-level list. > > However, the resulting abstraction may become fairly large and complex, with limited overlap between the monitoring and control data structures. > I am trying to envision this but it sounds to be as though each control has its own monitoring which is not clear to me. resctrl ultimately needs to support hardware features. Could you please share more about the hardware feature(s) this design intends to support? Reinette