Re: Re: [RFC] mpam,x86,fs/resctrl: Generic schema description Proof of Concept

[Shaopeng Tan (Fujitsu)]

Hello Reinette, Ben, Drew,

> On Thu, Jun 04, 2026 at 02:47:39PM -0700, Reinette Chatre wrote:
> > > The ability to change scope is much needed for RISC-V. There are
> > > compromises in my RFC [1] as a result of trying to map everything to
> > > either L2 or L3 scope.
> > > 
> > > I would also like to see a non-cpu cache scope for monitoring too, but
> > > would that be better discussed outside the context of this proof of
> > > concept?
> > 
> > I also think it would be good for it to be clear that monitoring is based on
> > scope, not a resource. With the MB controls supporting different scope I do think
> > that this would be a good next step. A previous musing from me on this topic can
> > be found (at the end of ) https://lore.kernel.org/lkml/fb1e2686-237b-4536-acd6-15159abafcba@xxxxxxxxx/
> > 
> > I have not yet considered how this can be built on top of this PoC though.
> 
> Thanks for explaining. I like how how you show an example of
> mon_data/mon_NODE_00/mbm_total_bytes in that thread. I believe that sort
> of scheme would work well for RISc-V as a bandwidth controller
> implementing the CBQRI spec can be located anywhere within the system.

I have a few questions regarding the scope parameter and the name "mbm_total_bytes".

First, concerning the scope parameter, does the "NODE" specified in "scope" refer to a NUMA node?
If so, wouldn't using "NUMA" directly be more explicit and user-friendly? 
Could you please explain why "NODE" is used instead of "NUMA"?

Second, regarding the naming of "mbm_total_bytes",
the meaning of this name seems to differ from what is typically found under mon_data/mon_L3_<id>/mbm_total_bytes. 
To avoid confusion and better reflect its different nature, 
how about considering an alternative name such as mbm_global_bytes or another more appropriate identifier.

Best regards,
Shaopeng TAN