Hi Reinette/Tony, On 10/14/24 15:05, wrote: > Hi Tony, > > On 10/14/24 12:51 PM, Luck, Tony wrote: >>>> What advantage does it have over skipping the per-domain list and >>>> just providing a single value for all domains? You clearly expect this >>>> will be a common user request since you implemented the "*" means >>>> apply to all domains. >>>> >>> >>> We started with a global assignment by applying assignment across all the >>> domains initially. >>> >>> But we wanted give a generic approach which allows both the options(domain >>> specific assignment and global assignment with '*"). It is also matches >>> with other managements (RMID/CLOSID management) we are doing in resctrl >>> right now. Also, there is an extra IPI for each domain if user is only >>> interested in on domain. >>> >>> Some of the discussions are here. >>> https://lore.kernel.org/lkml/f7dac996d87b4144e4c786178a7fd3d218eaebe8.1711674410.git.babu.moger@xxxxxxx/#r >> >> My summary of that: >> >> Peter: Complex, don't need per-domain. >> Reinette: Maybe some architecture might want per-domain. > > To be specific ... we already have an architecture that supports per-domain: > AMD's ABMC. When I considered the lifetime of user interfaces (forever?) while knowing > that ABMC does indeed support per-domain counter assignment it seems a good > precaution for the user interface to support that, even if the first > implementation does not. > > There are two parts to this work: (a) the new user interface > and (b) support for ABMC. I believe that the user interface has to be > flexible to support all ABMC features that users may want to take advantage of, > even if the first implementation does not enable those features. In addition, > the user interface should support future usages that we know if, "soft-ABMC" > and MPAM. > > I do not think that we should require all implementations to support everything > made possible by user interface though. As I mentioned in that thread [1] I do > think that the user _interface_ needs to be flexible by supporting domain level > counter assignment, but that it may be possible that the _implementation_ only > supports assignment to '*' domain values. > > I thus do not think we should simplify the syntax of mbm_assign_control, > but I also do not think we should require that all implementations support all that > the syntax makes possible. > >> Since you seem to want to keep the flexibility for a possible future >> where per-domain is needed. The "available_mbm_cntrs" file >> suggested in another thread would need to list available counters >> on each domain to avoid ABI problems should that future arrive. >> >> $ cat num_mbm_counters >> 32 >> >> $ cat available_mbm_cntrs >> 0=12;1=9 > > Good point. Ok. Will add it. Thanks Babu Moger
