Hi Reinette, On 5/22/25 11:33, Reinette Chatre wrote: > Hi Babu, > > On 5/22/25 8:44 AM, Moger, Babu wrote: >> On 5/21/25 18:03, Reinette Chatre wrote: > > ... > >>> This is why I proposed in [3] that the name of the mode reflects how user can interact >>> with the system. Instead of one "mbm_cntr_assign" mode there can be "mbm_cntr_event_assign" >>> that is used for ABMC and "mbm_cntr_group_assign" that is used for soft-ABMC. The mode should >>> make it clear what the system is capable of wrt counter assignments. >> >> Yes, that makes sense. Perhaps we can also simplify it further: >> >> # cat /sys/fs/resctrl/info/L3_MON/mbm_assign_mode: >> [mbm_cntr_evt_assign] <- for ABMC >> mbm_cntr_grp_assign <- for soft-ABMC > > Looks good to me. Thank you. > >>> Considering this the interface should be clear: >>> num_mbm_cntrs: reflects the number of counters in each domain that can be assigned. In >>> "mbm_cntr_event_assign" this will be the number of counters that can be assigned to >>> each event within a monitoring group, in "mbm_cntr_group_assign" this will be the number >>> of counters that can be assigned to entire monitoring groups impacting all MBM events. >>> >>> mbm_L3_assignments: manages the counter assignment in each group. When user knows the mode >>> is "mbm_cntr_event_assign"/"mbm_cntr_group_assign" then it should be clear to user space how the >>> interface behaves wrt assignment, no surprises of multiple events impacted when >>> assigning/unassigning single event. >>> >>> For soft-ABMC I thus find it most intuitive for num_mbm_cntrs to be the exact number >>> of "active" RMIDs that the system can support *and* changing the name of the modes >>> to help user interpret num_mbm_cntrs. >> >> Sure. The option A: fits well here then. >> >> Option A (counters are RMIDs): >> # cat /sys/fs/resctrl/info/L3_MON/num_mbm_cntrs >> 0=31;1=31 > > Thank you for considering. > > Please add the requirements from this discussion to your running list. Also please keep in mind > how soft-ABMC intends to use the interfaces created by this work so that the documentation that > accompanies the ABMC support in this series leaves enough "wiggle room" for soft-ABMC to be built on top. Sure. Thanks > >>>> [1] https://lore.kernel.org/lkml/CALPaoChSzzU5mzMZsdT6CeyEn0WD1qdT9fKCoNW_ty4tojtrkw@xxxxxxxxxxxxxx/ >>> >>> Reinette >>> >>> [2] https://lore.kernel.org/lkml/b9e48e8f-3035-4a7e-a983-ce829bd9215a@xxxxxxxxx/ >>> [3] https://lore.kernel.org/lkml/b3babdac-da08-4dfd-9544-47db31d574f5@xxxxxxxxx/ >>> >> > > Reinette > -- Thanks Babu Moger
