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

[Jinjie Ruan <ruanjinjie@huawei.com>]

在 2026/10/23 10:53, 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@arm.com/
>> Link:
>> https://lore.kernel.org/all/ec8bc617-9e74-4749-ab33-39d1079415cc@arm.com/
>>
>>
>>>  - 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@arm.com/
>>
>> 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. 

Hi Shaopeng,

Yes, You’ve got it right

> This implies that users cannot disable it even if they wish to do so.

Right.

> 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?

I agree with the idea of having a switch at initialization time.

But I think it can be added later as an additional feature, and it
doesn’t conflict with the current implementation.

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

I rebased on v7.3-rc6.

This series is also available at:

	https://github.com/ruanjinjie-eng/linux/tree/narrow_partid_v10

> 
> 
> Best regards,
> Shaopeng TAN

-- 
Best regards,
Jinjie