Hi Tony, On 5/5/25 10:01 AM, Luck, Tony wrote: >> The only aspect of "closids" that has been exposed to user space thus far >> is the "num_closids" and in user documentation a CLOSid has been linked to the >> number of control groups. That is the only constraint we need to think about >> here. I have repeatedly asked for IO alloc connection with CLOSIDs to not be exposed >> to user space (yet user documentation and messages to user space keeps doing so >> in this series). Support for IO alloc in this way is unique to AMD. We do not want >> resctrl to be constrained like this if another architecture needs to support >> some form of IO alloc and does so in a different way. > > This isn't unique to AMD. Intel also ties CLOSid to control features associated with > I/O (likewise with RMIDs for monitoring). > > See the Intel RDT architecture specification[1] chapter 4.4: > > " Non-CPU agent RDT uses the RMID and CLOS tags in the same way that they are used for CPU agents." As I understand AMD uses a single specific (the highest CLOSid supported by L3) CLOS that is then reserved for IO allocation. While both Intel and AMD technically "uses CLOSid", it is done differently, no? Specifically, is this documentation introduced in patch #5 accurate for Intel? + The feature routes the I/O traffic via specific CLOSID reserved + for io_alloc feature. By configuring the CBM (Capacity Bit Mask) + for the CLOSID, users can control the L3 portions available for + I/0 traffic. The reserved CLOSID will be excluded for group creation. Reinette
