Re: [PATCH v9 0/9] arm_mpam: Introduce Narrow-PARTID feature

[Shaopeng Tan (Fujitsu)]

Hello Jinjie, ZengHeng,


> >
> > I would like to confirm the following points.
> >
> >  - Is the number of reqPARTIDs per intPARTID dependent on the total number of intPARTIDs and reqPARTIDs?
> 
> Hi Shaopeng,
> 
> You are right,
> 
> reqPARTID % mpam_num_closid(the total number of intPARTIDs) -> intPARTID
> 
> so reqPARTIDs per intPARTID = Total number of reqPARTIDs / Total number
> of intPARTIDs
> 
> >  - Given that requirements for the number of control and monitoring groups vary by user,
> >    would dynamic configuration of the mapping ratio between intPARTID and reqPARTID be a more suitable approach?
> 
> No, in v8 James has suggested "static first" and avoid exposing user ABI
> in multiple places below:
> 
> "I think we should leave anything dynamic here for the further future,
>  lets get static partitioning working first"
> 
> "I'd prefer we get the static grouping working first, before we work out
> what needs changing in resctrl to do it dynamically"
> 
> "I'd like to avoid exposing user ABI to control this until we get it
> working, then we can talk about whether to try making the grouping
> dynamically managed by resctrl."
> 
> Link:
> https://lore.kernel.org/all/2944b506-a462-42f8-95cf-404241fb27f0@xxxxxxx/
> Link:
> https://lore.kernel.org/all/ec8bc617-9e74-4749-ab33-39d1079415cc@xxxxxxx/
> 
> 
> >  - Regarding the mapping logic, some reqPARTIDs may remain unused. Is this the expected behavior?
> 
> As mentioned above, we are implementing the static solution first, so it
> is expected behavior that some of the reqpartids are not used.
> 
> >  - Considering that Arm has previously implemented this,
> >    are there any gaps between their implementation and Huawei’s requirements?
> >    https://lore.kernel.org/linux-arm-kernel/20241212154000.330467-1-Dave.Martin@xxxxxxx/
> 
> I haven't looked at the ARM implementation yet (I'll refer to it later),
> but currently the code is being gradually aligned with the maintainer's
> review comments.


My understanding is that if hardware supports PARTID Narrowing, 
the feature is automatically enabled in the current driver implementation. 
This implies that users cannot disable it even if they wish to do so.
Could you please confirm if my understanding is correct?

If so, I believe we need a mechanism to explicitly enable or disable this feature. In Dave Martin's proposal, 
a partid_per_closid switch was introduced, where partid_per_closid = 1 effectively disables the feature, 
while setting it to `N` allows for customization to meet individual user requirements.

It would be ideal if we could configure the partid_per_closid value during the MPAM driver load time, 
avoiding the need for dynamic changes while the driver is in use. What are your thoughts on this approach?

Additionally, could you please let me know which branch this patch series is based on?


Best regards,
Shaopeng TAN