Hi Babu,
On 12/20/24 9:33 AM, Moger, Babu wrote:
> On 12/19/2024 4:33 PM, Reinette Chatre wrote:
>> On 12/12/24 12:15 PM, Babu Moger wrote:
>>> In mbm_assign_mode, the MBM counters are assigned/unassigned to an RMID,
>>> event pair in a resctrl group and monitor the bandwidth as long as it is
>>> assigned. Counters are assigned/unassigned at domain level and needs to
>>> be tracked at domain level.
>>>
>>> Add the mbm_assign_cntr_cfg data structure to struct rdt_ctrl_domain to
>>
>> "mbm_assign_cntr_cfg" -> "mbm_cntr_cfg"
>
> Sure.
>
>>
>>> manage and track MBM counter assignments at the domain level.
>>
>> This can really use some more information about this data structure. I think
>> it will be helpful to provide more information about how the data structure
>> looks ... for example, that it is an array indexed by counter ID where the
>> assignment details of each counter is stored. I also think it will be helpful
>> to describe how interactions with this data structure works, that a NULL
>> rdtgrp means that the counter is free and that it is not possible to find
>> a counter from a resource group and arrays need to be searched instead and doing
>> so is ok for $REASON (when considering the number of RMID and domain combinations
>> possible on AMD). A lot is left for the reader to figure out.
>
> How about this?
>
>
> In mbm_assign_mode, the MBM counters are assigned/unassigned to an RMID,
> event pair in a resctrl group and monitor the bandwidth as long as it is
> assigned. Counters are assigned/unassigned at domain level and needs to
> be tracked at domain level.
>
> Add the mbm_cntr_cfg data structure to struct rdt_ctrl_domain to
> manage and track MBM counter assignments at the domain level.
>
> Each domain will contain num_mbm_cntrs entries, indexed by cntr_id. During initialization, all entries will be set to zero. When a counter is allocated, its corresponding entry will be populated with the assigned struct rdtgroup and enum resctrl_event_id. When the counter is released, its entry will be reset to zero.
It will be better if you take a step back and create a coherent changelog
instead of appending independent text snippets. What you present has the
same mistake as before (mbm_assign_mode vs mbm_cntr_assign mode) and does
not address all the points raised.
Consider something like below (please check, improve, and complete):
In mbm_cntr_assign mode hardware counters are assigned/unassigned
to an MBM event of a monitor group. Hardware counters are
assigned/unassigned at monitoring domain level.
Manage a monitoring domain's hardware counters using a per monitoring
domain array of struct mbm_cntr_cfg that is indexed by the hardware
counter ID. A hardware counter's configuration contains the MBM event
ID and points to the monitoring group that it is assigned to, with a
NULL pointer meaning that the hardware counter is available for assignment.
There is no direct way to determine which hardware counters are assigned
to a particular monitoring group. Check every entry of every hardware
counter configuration array in every monitoring domain to query which
MBM events of a monitoring group is tracked by hardware. Such queries
are acceptable because <insert reason here>.
Please work on creating good changelogs. The requirements should be clear to you.
Reinette
