Hi Reinette, On 9/19/24 10:33, Reinette Chatre wrote: > Hi Babu, > > On 9/18/24 11:22 AM, Moger, Babu wrote: >> >> >> On 9/18/24 10:27, Moger, Babu wrote: >>> Hi Reinette, >>> >>> On 9/13/24 15:45, Reinette Chatre wrote: >>>> Hi Babu, >>>> >>>> On 8/16/24 9:16 AM, Babu Moger wrote: >>>>> Detect SDCIAE`(L3 Smart Data Cache Injection Allocation Enforcement) >>>> >>>> (stray ` char) >>> >>> Sure. >>> >>>> >>>>> feature and initialize sdciae_capable. >>>> >>>> (This is a repeat of the discussion we had surrounding the ABMC feature.) >>>> >>>> By adding "sdciae_capable" to struct rdt_resource the "sdciae" feature >>>> becomes a resctrl fs feature. Any other architecture that has a "similar >>>> but perhaps not identical feature to AMD's SDCIAE" will be forced to also >>>> call it "sdciae" ... sdciae seems like a marketing name to me and resctrl >>>> needs something generic that could later be built on (if needed) by other >>>> architectures. >>> >>> How about "cache_inject_capable" ? >>> >>> This seems generic. I will change the description also. >>> >> >> Basically, this feature reserves specific CLOS for SDCI cache. >> >> We can also name "clos_reserve_capable". > > Naming is always complicated. I think we should try to stay away from > "clos" in a generic name since that creates problem when trying to > apply it to Arm and is very specific to how AMD implements this > feature. "cache_inject_capable" does sound much better to me ... > it also looks like this may be more appropriate as a property > of struct resctrl_cache? Coming back to this again, I feel 'cache_inject_capable' is kind of very generic. Cache injection term is used very generically everywhere. Does 'cache_reserve_capable" sound good ? This is inside the resctrl subsystem. We know what it is referring to. -- Thanks Babu Moger
