Received-SPF: pass (google.com: domain of linux-kernel+bounces-174751-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Message-ID: <0d94849c-828c-4f10-a6f8-e26cc4554909@intel.com>
Date: Thu, 9 May 2024 11:07:12 -0700
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH v3 00/17] x86/resctrl : Support AMD Assignable
 Bandwidth Monitoring Counters (ABMC)
To: <babu.moger@amd.com>, <corbet@lwn.net>, <fenghua.yu@intel.com>,
	<tglx@linutronix.de>, <mingo@redhat.com>, <bp@alien8.de>,
	<dave.hansen@linux.intel.com>
CC: <x86@kernel.org>, <hpa@zytor.com>, <paulmck@kernel.org>,
	<rdunlap@infradead.org>, <tj@kernel.org>, <peterz@infradead.org>,
	<yanjiewtw@gmail.com>, <kim.phillips@amd.com>, <lukas.bulwahn@gmail.com>,
	<seanjc@google.com>, <jmattson@google.com>, <leitao@debian.org>,
	<jpoimboe@kernel.org>, <rick.p.edgecombe@intel.com>,
	<kirill.shutemov@linux.intel.com>, <jithu.joseph@intel.com>,
	<kai.huang@intel.com>, <kan.liang@linux.intel.com>,
	<daniel.sneddon@linux.intel.com>, <pbonzini@redhat.com>,
	<sandipan.das@amd.com>, <ilpo.jarvinen@linux.intel.com>,
	<peternewman@google.com>, <maciej.wieczor-retman@intel.com>,
	<linux-doc@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<eranian@google.com>, <james.morse@arm.com>
References: <cover.1711674410.git.babu.moger@amd.com>
 <48b595cc-5ffe-4507-bffd-335a60fdaab9@intel.com>
 <2016b830-64c7-43bd-8116-bdfd239221e3@amd.com>
 <ea75801f-e56a-486d-85a4-85c57bce0c81@intel.com>
 <7e92200e-d68c-4dc4-85c3-7192a23f8cbc@amd.com>
 <b8a87fb1-838f-4337-8940-8eb1c5328a2b@intel.com>
 <379ba0ed-5c67-4fb8-9738-952289d2f699@amd.com>
Content-Language: en-US
From: Reinette Chatre <reinette.chatre@intel.com>
In-Reply-To: <379ba0ed-5c67-4fb8-9738-952289d2f699@amd.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bFF0ME5oaWhQMjl1azFlelkyWXRYRm55NVpEVk4xcGgvRC9DMWdBQTRNYVdG?=
 =?utf-8?B?MG56UGtCY3habFZKZzAzZzRJNjlhb0Y5OFZ5V3J0eTFoS2FhWGxUbVkvYnlT?=
 =?utf-8?B?RU1vL2VNV3dsT1NKMnlvcS9oUDlyQU0xVkxYd1ovNHVjSnk0SGEzUVFQNUFB?=
 =?utf-8?B?MjFCRmFaOElzOVFGby8yVjEvZXNUcGNlOEtjVkE4UG9RVVJUbXhwZnprRGZr?=
 =?utf-8?B?SFdXZE1rb1AxanNPaDArZFVJWHNaSGoyZHVGY3VmV3ZjMWJ0bzN0S3NVYXc3?=
 =?utf-8?B?enkvNnlQdFhXTVV3dUlMa0RuV3l6bmVFR1RoUWh1ZGc2S1JhYmdLdWFVdGsv?=
 =?utf-8?B?WDZWRUZYM2xYSHJTMk5ydEhuditCTFZqUkN5MytySmVUSnRvMU9vbzQwdDR4?=
 =?utf-8?B?SXlmNGRhUjBxMzNQRFExanYxRG5ud2Ira1JLN084Q0FCdGNJWnd2VmwrVlJo?=
 =?utf-8?B?dUdrNjNnaTMva1N6bXhramtyR0pXakZ3M1ppYVM0aHhkR2ozV3NrZVF5YXlL?=
 =?utf-8?B?V3NkdUNIUmQ4UkxVdnFFMlBXaHlDcVd1OFk5NWFaZWVHbHA1Sm9IcVhYQkZs?=
 =?utf-8?B?cDdWb25wZEZoU0pHeE5HWk9SR0pLRGQ5SHJOV2hRVWVDQXpwYVUrNjNqREgr?=
 =?utf-8?B?RjUxNXJDbnhRTURjR2ZYS3lzcGZHUlJjUXNhbVNiQVEwUXo2blVKWnZlandI?=
 =?utf-8?B?Ykh2TzdWMGdpZDZBMXI4V1RGUVZ3QU1qaVJJT0FadW9YMDJoalNFRnQ1TWMz?=
 =?utf-8?B?eU84emhMRUVsQmdHTkJZMUpGOU1xazgyVE5zc2ZaNytUTU0zQjk0ZEpYajdM?=
 =?utf-8?B?bm5vdk9vOHBJcUZMMENndFhxVXlnbG0yMnE5ek5WeDZNL2R0U2puV0M5QVdU?=
 =?utf-8?B?S1dLaXlqUlhsTjl0WWNLM0NMOHREWDdSMVh6Wk5GWDdkTjVtV3E2M0JFZG5l?=
 =?utf-8?B?VEgwbWp3dllxY0hEdFZ3cStBd1dBRGR4U0VGeWd1bXppL0N3L0pSdVMrQnlC?=
 =?utf-8?B?L2ZvdGJ5dzZzbkpKUERZU25uSEEwbmRRVzF4SVpVQWxrY3I5VzZSK1pFOWdD?=
 =?utf-8?B?VXpmMW5rUkR0OCtPbVpLQXp5NWxKZVh1TkNXVWZocTAvRytiYVBrbVJNVDls?=
 =?utf-8?B?ZFNNcGZhQnZYQzNoMUF2RWtiUFgvOWFtb3NBZm5OdXVwaUF1VUlRc3lKRUll?=
 =?utf-8?B?Q1U5b0t5eTgyYlpwU2U1b05tdnhsay9EYmJjSnU3NFhYMmJQb3d0VlppWlU4?=
 =?utf-8?B?NE9lM2xjQmsyc3hZK2JvV0licmpvaDYvM3M0bnlXVVdNVzB1eE9LVGR3c1VV?=
 =?utf-8?B?Y0JGeGVmd1RPVE15NS8wYjA4SzRVTFRzL1N3S2Nla3RCYlRWdmtRR3VxbUVh?=
 =?utf-8?B?N3grSVkwdTRpQnV5MVIrWGFyd2RMTXhMcUEwMHRlSjF5bTgxQjU5Y1dITE80?=
 =?utf-8?B?aHV5ampyWFJNQmFVcUlHdkdEYzZORTl5YmtLUFVSanRKVHE5OFJ0akpid3hP?=
 =?utf-8?B?L0txd3orNEtFN2dUdFBSL3hOdGZVblpLYWlUUUxiNWswQzFzd0RNSFc2ZkRJ?=
 =?utf-8?B?TWg0Vkt1WVJYM0VUUGZJcHJheVg5NGpOVXA2blcxc0crVkVJQzhkbFlJV0s0?=
 =?utf-8?B?eGVkRXVTU25JbmFnR1kwYXlGVVJKbXE1ZUU5aHhzY1JudWg5dWpKZkp3RFVN?=
 =?utf-8?B?cHBsUnNMTVhUUGUwV3Q0N21MWnp6U091UVd3Y3ZWZ0d1K3N5MFI3OVZ1VFZ3?=
 =?utf-8?B?SW1ZRFo4UnpnUE9mQlozZ2ZYdU00Y3VRWTNTa0NMUTlTZ1BSYWhpcEpaSjlO?=
 =?utf-8?B?SVVHRS8zYXNpQ1lxMUZkVkl2SFdMbUlBZmEvcDdsbldDOU50SFRGejZySW4y?=
 =?utf-8?B?U3FzQ3dPQ3p6Q1RaNDZFQVhjdVVoZkdNS01UaFBYdXZlQXVVOE5xMFdKdHV0?=
 =?utf-8?B?S25DV3F0VStSMWdFZVRuWC8vbmY5RStFNk4wQ3lMcWNmYSt6SytEdENWK2dY?=
 =?utf-8?B?ZzlIR1puR2dMaENaQVBYb3J4YWZ6R004OGRUWHBSdHRhOUd1ZTBVKzcvK21Q?=
 =?utf-8?B?ZUtsK0NLVy9tZHFxUWxvL3ZWeTlqSVU4ZnFvQW9EQ3lUV3dLZEdnY3NxVlhY?=
 =?utf-8?B?aEVsLzdhcURFQmd2Y2xlUXkxWVdQZlkwNFM3SFRkYkNvbEVRMHY3VlU0QzJP?=
 =?utf-8?B?WUE9PQ==?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 132fed4d-95b3-47b3-6c13-08dc7052dc23
X-MS-Exchange-CrossTenant-AuthSource: SJ2PR11MB7573.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 May 2024 18:07:16.5052
 (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: n9ghbVgYgYablu6lf9ScBgJyPsRcJAflgrqclMXXJAiYsmM6bcydEnoQJeWl2sDxBT10waZoK3GRkBZbzd1UAp/wSvI9AfqQx8/30ae7eFY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR11MB7575
X-OriginatorOrg: intel.com

Hi Babu,

On 5/8/2024 4:29 PM, Moger, Babu wrote:
> On 5/8/24 15:41, Reinette Chatre wrote:
>> On 5/8/2024 1:07 PM, Moger, Babu wrote:
>>> On 5/7/24 15:26, Reinette Chatre wrote:
>>>> On 5/6/2024 10:18 AM, Moger, Babu wrote:
>>>>> On 5/3/24 18:24, Reinette Chatre wrote:
>>>>>> On 3/28/2024 6:06 PM, Babu Moger wrote:
>>>>>>
>>>>>>> a. Check if ABMC support is available
>>>>>>> 	#mount -t resctrl resctrl /sys/fs/resctrl/
>>>>>>>
>>>>>>> 	#cat /sys/fs/resctrl/info/L3_MON/mbm_assign
>>>>>>> 	[abmc] 
>>>>>>> 	legacy_mbm
>>>>>>>
>>>>>>> 	Linux kernel detected ABMC feature and it is enabled.
>>>>>>
>>>>>> Please note that this adds the "abmc" feature to the resctrl
>>>>>> *filesystem* that supports more architectures than just AMD. Calling the
>>>>>> resctrl filesystem feature "abmc" means that (a) AMD needs to be ok with
>>>>>> other architectures calling their features that are
>>>>>> similar-but-maybe-not-identical-to-AMD-ABMC "abmc", or (b) this needs
>>>>>> a new generic name.
>>>>>
>>>>> It should not a problem if other architecture calling abmc for similar
>>>>> feature. But generic name is always better if there is a suggestion.
>>>>
>>>> "should not a problem" does not instill confidence that AMD is
>>>> actually ok with this.
>>>
>>> The feature "ABMC" has been used in the public document already to refer
>>> this feature.
>>> https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/programmer-references/24594.pdf
>>
>> It is clear to me that Assignable Bandwidth Monitoring Counters (ABMC) is the
>> name of the AMD feature. The question is whether users can use the 
>> same name to interact with "similar but maybe not identical" features from other
>> architectures, which is what this series enables.
>>
>>> If there comes a conflict then we can change it to amd_abmc. Didn't see
>>> any conflict at this pint.
>>
>> How do you envision this? The resctrl filesystem interface is intended to be
>> architecture neutral so it is not obvious to me how "amd_abmc" is expected
>> to look? Why would it be necessary to have different architecture specific names
>> for a similar feature from different architectures that users interact with in
>> the same way? Sounds to me as though this just needs a new non-AMD marketing name. 
> 
> I think I misunderstood it.
> It is not a concern to have a same name("abmc") for similar feature across
> the architectures.

Thank you for confirming. This joins BMEC and SMBA in this regard.

> ABMC is also kind of generic. I am open to other generic suggestions. I
> think we should have "assign" and "monitor" words in them.

One thing we can consider is to move to a simple "enable"/"disable"
interface for events. Users do not really need to know that hardware
needs to "assign a counter" to an event for it to measure. Yes,
user space can infer some of this by the number of events that
can be "enabled" at a time, but the concept of "assign a hardware counter"
is abstract and does not directly map to (as I understand) the soft-RMID
approach for other AMD hardware. Peter reminded us a while back [1] that
"assign" has a variety of meanings, even among AMD, so we should aim to
avoid any confusion. 

Reinette

[1] https://lore.kernel.org/lkml/CALPaoCjg-W3w8OKLHP_g6Evoo03fbgaOQZrGTLX6vdSLp70=SA@mail.gmail.com/