Received-SPF: pass (google.com: domain of linux-kernel+bounces-174933-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Message-ID: <f445e7f0-0d70-4f4a-8262-eaf3eb09478f@amd.com>
Date: Thu, 9 May 2024 15:34:59 -0500
User-Agent: Mozilla Thunderbird
Reply-To: babu.moger@amd.com
Subject: Re: [RFC PATCH v3 00/17] x86/resctrl : Support AMD Assignable
 Bandwidth Monitoring Counters (ABMC)
To: Reinette Chatre <reinette.chatre@intel.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>
 <0d94849c-828c-4f10-a6f8-e26cc4554909@intel.com>
Content-Language: en-US
From: "Moger, Babu" <babu.moger@amd.com>
In-Reply-To: <0d94849c-828c-4f10-a6f8-e26cc4554909@intel.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?enM3cnAvb2hvTmo3cURMbW0yRTRySGl2MlBRdUloVWhybHVVZGJIeVU0b05n?=
 =?utf-8?B?aXg5R0RuS0N2T3hkSUFIZ25YQ1NiOG14a0RJdlV0cFNZYzJpUGpRMkZXMTND?=
 =?utf-8?B?VTFPVDVkTjc3bk4yN0lQRFhxUFRaTjh3RmJsNThHTG9DNW13aUozbHA5dnIy?=
 =?utf-8?B?cW9lL0hDQlFtdGNWL3NYcDdld2Fvdkk3enBoS1VaV0VRRGRUcTVHU2IrbXQ1?=
 =?utf-8?B?OWhZNzBWNTZrSHRQbDMyQWZFZHMxc3FPRzA1S3hOcDhGbk1LMmNZQ0NhRU8y?=
 =?utf-8?B?cHlKWStMZ1krV2N1VjF4cmpGN2J1d1ZHQ3RsVHIvZXBZNmN3azltRnBZNU1R?=
 =?utf-8?B?YWJSeEE3eWd6WHV0TE9mMHhTa2dPTUVaUmk2Mm0rTHRldU82MVZyNC9WbmRD?=
 =?utf-8?B?RFk2cXVpU1dmcWI1dzZsMWwrMlVuMVVUM2RadUZSYisxOU4rT2hEU2l6RjFo?=
 =?utf-8?B?NFJEVkJUUXhkTXFsZkpKUWxnUXdzVEtmSDZKVDBYVjJIdVRzVjFWWUxvQXBX?=
 =?utf-8?B?SkNrVHd6cFRCQ1pERTgxMzJaT1lNUmtBOVlzZFAxWUoxMjNod1FnMFBYWkJz?=
 =?utf-8?B?SGpHdldRY05iMjlyT2NVTkY5UE54bDNqR0ZqVk1zYm5ka29YaHVVd2VJSi9N?=
 =?utf-8?B?K3l2YUppekRTV0JKNnlaVS9RTmJCTjBCanE4YTdvMFFFSnhhYjJsWUFLWTkx?=
 =?utf-8?B?OWhDRkFtclpJVm5lY3JjMnllUXVRQ1d5amdkcVFISW9zZDN2ZEtzNDZnMFNL?=
 =?utf-8?B?elNZTlJWSXJYSXBDYUkxTkV3M3JTaXJqVmYyckpqN25oZVJBcU9GWVF5cjl5?=
 =?utf-8?B?WnJWVXZtalRvKzQ2Y3d2NWVoV1NBenJpU1hyUzNqcHNOei8zbmhrWnJPUE1q?=
 =?utf-8?B?ak9DOXFGVTNveXVWc3daa3ZCRUhTL2l4S0toZEFmOHd1TzZPMGZOYUgzZ2NH?=
 =?utf-8?B?YzIzdG1PRG1leUg2NzZ0T3lEbGpONE54eTA4NloyRXhlZEJrbHNNWDBtUzJU?=
 =?utf-8?B?enhVMmg5aVUweGxsQkxOaFRIclhsNFIreHhUeDRSOHBwQytPVGs0ZEpvMHVS?=
 =?utf-8?B?cHR1T2ZjY09Nam9GaXdFZkFHRnhXSENnOTRJTVRFY2ZrR3p0N096RlBxWWZy?=
 =?utf-8?B?Umc3UW1rQ1dQSG1RekV6ZVpCR1ZFMXJ2UTJMOVNKMXJkUGpsT09BaGNnOVN3?=
 =?utf-8?B?ZmNXRm9YcWREMS82blhNUW1JQnBFWFc5am11QkkwYXB1czNCM2R3ZGVaL1E2?=
 =?utf-8?B?UWFodmN1c29VT2tDLzJUTU44cFZxL3JRa01mZ3dlV1phSk9lVDF3S3RyeVhl?=
 =?utf-8?B?aExXL3l1VjVBcXhwYnNqNmlWQjFQcDhUYVhnbnJ2NXA5MEJDandUY0JBWjE3?=
 =?utf-8?B?VnVhbVB3MzB2VURxL0REbVMwV2N3dXFjdlhudEFVVzlxdFRzWUVQRklqcjJi?=
 =?utf-8?B?TmloaXJmbGdheU1NYy9UWjEyeHUxUk1JeUZ1T3E0RWdvd3dIWnduSENzZTdK?=
 =?utf-8?B?S3lnKzNRVGdIRFhTdjJHaDdHLzNqVUN6dEhGOWdhVmR6UWpFWWExTmlaTndy?=
 =?utf-8?B?NW1aS1N0RHREMUo0TFArK1h2RjZFU2RGTVR5OFp3ZGJ5OGJaRkdHdnA3QXRt?=
 =?utf-8?B?RURzTDB4K2k5dW5lblFSdFZuOG1KZTlIZXNleTFHZHhpZDczeVJWNmRDaEtV?=
 =?utf-8?B?bmhnaTY2NVJrUlMvK00wdnR3U292WENyRElGcVZaelZCdk9CQ3FmOUdCRXp1?=
 =?utf-8?B?TDJ1a0RGdHhvSVFwVkNSazh3NXJwVFhGWkNKc01mYVVxaHFFSDdtOEw2eVpm?=
 =?utf-8?B?OVJ5OHhxb2RiSEZZVGF5c1Q0ZmY3a0xRVzZLWUVUNzRPcmRVR2dPSTh5TE91?=
 =?utf-8?B?QTJFZmN5THFtUWkzQ1N0anZlZ0dlbk1tUkNaWjQ1ZXV3eDE0MUx3T0FjbkdT?=
 =?utf-8?B?ZWY5YmFpajVaSjZsRHluWVdYRkxqTDd3bm9OMnRENjlDMzdqZzNCcDZZS1hI?=
 =?utf-8?B?N2tjbXA4cTh4Q0lRUW5qdCtLVmRTRDQ4eVVFWkhMTjV6Q09VKzAyYWxtQUtT?=
 =?utf-8?B?Tis1bDJuTGhwVzgxdEx0VndWalJpeVl3WUd4ZTlhU3Vjb3JHRUtJTk5qTVlu?=
 =?utf-8?Q?jrzs=3D?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7d604890-e734-4e2c-6487-08dc7067816b
X-MS-Exchange-CrossTenant-AuthSource: MW3PR12MB4553.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 May 2024 20:35:03.6639
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: ypwHSp9dTWTbZVBi8u8QlX2VxnOsKhEiWyzxMZfLDXBxqgvEOfCloXVdrbj8fQvU
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR12MB7823

Hi Reinette,

On 5/9/24 13:07, Reinette Chatre wrote:
> 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.

Yes. Sure.
> 
>> 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.

Documentation will refer the events as enabled or disabled instead of
assigned or unassigned.

For example:
Event flags can be one of the following:

        t  MBM total event is enabled
        l  MBM local event is enabled
        tl MBM total and local events are enabled
        _  None of the MBM events are enabled

It is fine.

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

-- 
Thanks
Babu Moger