On Mon, Feb 12, 2024 at 01:43:56PM -0800, Reinette Chatre wrote: > Hi Tony, > > On 2/12/2024 11:57 AM, Luck, Tony wrote: > >>> To be honest, I like this series more than the previous series. I always > >>> thought RDT_RESOURCE_L3_MON should have been a separate resource by itself. > >> > >> Would you prefer that your "Reviewed-by" tag be removed from the > >> previous series? > > > > I'm thinking that I could continue splitting things and break "struct rdt_resource" into > > separate "ctrl" and "mon" structures. Then we'd have a clean split from top to bottom. > > It is not obvious what you mean with "continue splitting things". Are you > speaking about "continue splitting from v14" or "continue splitting from v15-RFC"? I'm speaking of some future potential changes. Not proposing to do this now. > I think that any solution needs to consider what makes sense for resctrl > as a whole instead of how to support SNC with smallest patch possible. I am officially abandoning my v15-RFC patches. I wasn't clear enough in my e-mail earlier today. https://lore.kernel.org/all/SJ1PR11MB608378D1304224D9E8A9016FFC482@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/ > > There should not be any changes that makes resctrl harder to understand > and maintain, as exemplified by confusion introduced by a simple thing as > resource name choice [1]. > > > > > Doing that would get rid of the rdt_resources_all[] array. Replacing with individual > > rdt_hw_ctrl_resource and rdt_hw_mon_resource declarations for each feature. > > > > Features found on a system would be added to a list of ctrl or list of mon resources. > > Could you please elaborate what is architecturally wrong with v14 and how this > new proposal addresses that? There is nothing architecturally wrong with v14. I thought it was more complex than it needed to be. You have convinced me that my v15-RFC series, while simpler, is not a reasonable path for long-term resctrl maintainability. > > Reinette > > [1] https://lore.kernel.org/lkml/ZcZyqs5hnQqZ5ZV0@agluck-desk3/ -Tony
