Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37;
Message-ID: <5215fe1e-52e1-4ca4-8bd2-a42152f3e0e3@intel.com>
Date:   Tue, 12 Dec 2023 13:42:51 -0800
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v6 1/3] x86/resctrl: Add mount option "mba_MBps_event"
Content-Language: en-US
To:     Tony Luck <tony.luck@intel.com>
CC:     Peter Newman <peternewman@google.com>,
        Fenghua Yu <fenghua.yu@intel.com>,
        Jonathan Corbet <corbet@lwn.net>,
        Shuah Khan <skhan@linuxfoundation.org>, <x86@kernel.org>,
        Shaopeng Tan <tan.shaopeng@fujitsu.com>,
        James Morse <james.morse@arm.com>,
        Jamie Iles <quic_jiles@quicinc.com>,
        Babu Moger <babu.moger@amd.com>,
        Randy Dunlap <rdunlap@infradead.org>,
        <linux-kernel@vger.kernel.org>, <linux-doc@vger.kernel.org>,
        <patches@lists.linux.dev>
References: <20231201214737.104444-1-tony.luck@intel.com>
 <20231207195613.153980-1-tony.luck@intel.com>
 <20231207195613.153980-2-tony.luck@intel.com>
 <CALPaoCji1yzfkA=tms3LhYMvRB+wSJQM3qzPKrHNEa7a+KduTA@mail.gmail.com>
 <ZXORTTIUKWXOsd9p@agluck-desk3>
 <CALPaoCj_OvMzD8W9+jEORewwDquM6F-sOW32Ngcy+Gm6A1+OcQ@mail.gmail.com>
 <2377bfb8-00bc-4863-8d70-425cb70c9c0b@intel.com>
 <ZXi8Rj3znA6lmjE9@agluck-desk3>
From:   Reinette Chatre <reinette.chatre@intel.com>
In-Reply-To: <ZXi8Rj3znA6lmjE9@agluck-desk3>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MW9TTkE3V1FQK0FweEJ1MDgrOU5qbUYwTmxiTjlTS2oweUc5RGNoQ240TG1L?=
 =?utf-8?B?VTYvNlNkVktNRVBOdG9MSy90eHBFSU8zMzhZajd0MnhrRVBBTmZLSThlNWtL?=
 =?utf-8?B?VWgvMFptTnRXWVRkZHlWVStoSWp2Q05QWGw2OWZWYy9iZXFVOWc3eHpndWdD?=
 =?utf-8?B?ODJHOUpBOEdEclgva242M3ZKSUhXZlRsWHkvdER0Qkh0eWExT2ROQkhac0Jz?=
 =?utf-8?B?SDNMSlE2MEJpd1EydG4wbVRsdVZ1SElpeFpmYVBzdFpkOU1HM1lGeWtnemVx?=
 =?utf-8?B?Z0JrQ1NacXZQVmQ1eVhjc2dQU1Q4VmEySE9DTytZNlhOOGhVL3JQbVNKQ3J4?=
 =?utf-8?B?Y3MxWStFTXBOMVZLYzd5ZjVUZExOTUt5WmdESXZFMElsazRpT1dvNzVHTmtZ?=
 =?utf-8?B?blVmVzF6TEFlWHFJTWxzaHlJV3I4K1NlVGZiY2lhVml6ZThZcjVrRHZhc1Iv?=
 =?utf-8?B?VkhHVVZrZndwaC9zVVE3K3VYVjE1dVFmUzFnZlpYZzh3Y0pVWDJZVWNCZmVv?=
 =?utf-8?B?aG1NUU1IWUg4Z3dDMldQVTJXUWV5QVk3eWxoSTFnL0NCbTJvR0QwQWJ0Vm43?=
 =?utf-8?B?WlFFeTZTNFFIaUxneW04ZFlWUXZJMmdGL0pCRDdYdFY5OXdjRXllRnVWVTdu?=
 =?utf-8?B?OWFTU2g3MklwU3dFU3VPdlcvK1pvZ1kwS0Y1dkYzOTN6by94Qk5GSW45TmI5?=
 =?utf-8?B?R0dtemZtQTJyNDVQMHRFOGNMa3RzUW9qcFlIWWdRbzJBd2VvWGhJTFFIZWlL?=
 =?utf-8?B?VnE3SC8vU09Mck1UUWxVSkRVamdVak5PL3krSldaNDY5SlMvWGZvMkJJcnd4?=
 =?utf-8?B?My9rMW52c3Jub0JWR05VVFlTRko5TjM4cG5paUFCdjVTbUs1TDhBVTBoSVFo?=
 =?utf-8?B?R0FHWFBURmhWaGIzWDR5QytNdmdmMVlYZHA5YmVzVXFvUThTSlUrMGwzR1p5?=
 =?utf-8?B?UFVhVENzQTZoL0hYZklTY29Qb0UrU3hIMFBVZ0tGS2tETEdhcmZoMnJDdmIw?=
 =?utf-8?B?OU1IZkcvNjJXRmFramkxZjNJYjJtZTFyTi9QQVJSZCtwcXNKcGVPT1FUdXBs?=
 =?utf-8?B?NWNndFMxS0NaSGZyNzlkQ3lWUVVQeDYwVWVyVzBYRHpjSmdyb3ZzUHBhelBZ?=
 =?utf-8?B?S3JYRVBHN2VSMHI1ck1oWVpQTGhoakdURHBJc2FGM29mbXFBYXBidlF1SnNW?=
 =?utf-8?B?OFpaSUE2cVByQUJzaE00bXNFdTVmdUlMbUwvNGRCeU5QczJkYXYrZTJ5NEs1?=
 =?utf-8?B?NmRxaWg2Rk9Db0dsUCtYVUZEaTNnSUtFcEVMVE9VN0RrWDk3UGlKTHhYRGNE?=
 =?utf-8?B?cS94VGNlYkw5Zm1ZRGw0dHlLbmtabVJ2cXVkbThiQ2R3OHFYUXhZMGY0d200?=
 =?utf-8?B?ZmYyd1RuV2RQblNJZHF3cjZjVUdSV0M2Q3IwRjJFZnRseDBaQUNPeXprSUtU?=
 =?utf-8?B?OUlXZk9jUGpBc01HY0FJNEZ3RVhCQ3RPd21xaS80ejlpcnpLdUxlTDRVdEhv?=
 =?utf-8?B?YjhnOU8zM3Z0YXpyYTdvTWROSi9nUkFuQUg4TXZ0V1dvaGZCYVpDM2M3UVF4?=
 =?utf-8?B?Q1lDUkVFTVJmUTlsQk4rVkw4RXJ0S2ZMUDliNGY2Q3FQUGZUN2RmTk9XSzhk?=
 =?utf-8?B?Qis4WTV6Ry85RjkrYzl1TWRBQVNKUTk2WWR1VHlwR3ZPUERUbFVIUEFjSHBM?=
 =?utf-8?B?MVErTm1sSWpuWTZHQldHT2R1QlZYS2JDRjdMSVFzbHhlRnpOc0g2VnprQ3RJ?=
 =?utf-8?B?SVh6VFE1dnkweUluVWh6RnFXUm1iYXZuVFFhYzNNTERrL3U2SVRQV2EwSitM?=
 =?utf-8?B?VmlPYTB3UzZiM0d0WTJuMUluVE82RmV5OFloT3BlcmczY3o1UjRDTjV6Y2g2?=
 =?utf-8?B?RnZoRUhoOTN5aFlZY1BKZjdhR0dYWlpkYmFuNmdCZ3NYdDNINkFLN0tWRUtz?=
 =?utf-8?B?OVZOd0lteWVGUEl5Sk80QzdodWNndFlYelFLNDhTbDFsb2FubmVDSVIzbVJp?=
 =?utf-8?B?a0k1L08zVE5wQ1pHMHZSbm8wZTZFamVXSDQvdEIxMkpzU2xQR1BkR1NxR2sw?=
 =?utf-8?B?ZGh4N0lpOTlGK1d4L2orMVRiK2pNMGNkdnI5VzJNQTRBWWE4dmMyS2dlNk5H?=
 =?utf-8?B?ZG5kVVNKdEFoSkcvQlF5Wk1oUGRQaEg0ZVY3cGFndHpaU00wazBRYmROZXpv?=
 =?utf-8?B?R1E9PQ==?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 5485c9c6-4511-423e-ec90-08dbfb5b4c15
X-MS-Exchange-CrossTenant-AuthSource: SJ2PR11MB7573.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Dec 2023 21:42:54.1620
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: hLk4sX0kcERWNTKLGiIiVkG62ZSDFc05XLodS4uvVAd+cX8JWSrnu45BC5QxXJbTjHc02Bt3ajQP4xMxBY5/o18W/PsSV3lF/Bea/apXeVA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR11MB8750
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,
        SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Tue, 12 Dec 2023 13:44:06 -0800 (PST)

Hi Tony,

On 12/12/2023 12:02 PM, Tony Luck wrote:
> On Tue, Dec 12, 2023 at 09:54:38AM -0800, Reinette Chatre wrote:
>>
>> On 12/8/2023 2:09 PM, Peter Newman wrote:
>>> On Fri, Dec 8, 2023 at 1:57 PM Tony Luck <tony.luck@intel.com> wrote:
>>>>
>>>> On Fri, Dec 08, 2023 at 10:17:08AM -0800, Peter Newman wrote:
>>>>> Hi Tony,
>>>>>
>>>>> On Thu, Dec 7, 2023 at 11:56 AM Tony Luck <tony.luck@intel.com> wrote:
>>>>>> @@ -2715,7 +2723,25 @@ static int rdt_parse_param(struct fs_context *fc, struct fs_parameter *param)
>>>>>>         case Opt_mba_mbps:
>>>>>>                 if (!supports_mba_mbps())
>>>>>>                         return -EINVAL;
>>>>>> -               ctx->enable_mba_mbps = true;
>>>>>> +               if (is_mbm_local_enabled())
>>>>>> +                       ctx->enable_mba_mbps_local = true;
>>>>>> +               else
>>>>>> +                       return -EINVAL;
>>>>>> +               return 0;
>>>>>> +       case Opt_mba_mbps_event:
>>>>>> +               if (!supports_mba_mbps())
>>>>>> +                       return -EINVAL;
>>>>>> +               if (!strcmp("mbm_local_bytes", param->string)) {
>>>>>> +                       if (!is_mbm_local_enabled())
>>>>>> +                               return -EINVAL;
>>>>>> +                       ctx->enable_mba_mbps_local = true;
>>>>>> +               } else if (!strcmp("mbm_total_bytes", param->string)) {
>>>>>> +                       if (!is_mbm_total_enabled())
>>>>>> +                               return -EINVAL;
>>>>>> +                       ctx->enable_mba_mbps_total = true;
>>>>>> +               } else {
>>>>>> +                       return -EINVAL;
>>>>>
>>>>> It looks like if I pass
>>>>> "mba_MBps_event=mbm_total_bytes,mba_MBps_event=mbm_local_bytes" I can
>>>>> set both flags true.
>>>>
>>>> That's going to be confusing. I'll add code to stop the user from
>>>> passing both options.
>>>
>>> Also kind of confusing, after reading the second patch, I realized
>>> "mba_MBps_event=mbm_total_bytes,mba_MBps" also results in both being
>>> set. If you're able to fail the mount operation if both flags somehow
>>> get set, that would address this one too.
>>
>> Are two separate flags required? All existing options within struct rdt_fs_context
>> are of type bool but that does not imply that it is the required type for
>> all. 
> 
> Reinette,
> 
> Maybe a flag and a value?  The structure becomes:
> 
> struct rdt_fs_context {
> 	struct kernfs_fs_context	kfc;
> 	bool				enable_cdpl2;
> 	bool				enable_cdpl3;
> 	bool				enable_mba_mbps;
> 	enum resctrl_event_id		mba_mbps_event;
> 	bool				enable_debug;
> };

A flag and value would work. This brings the implementation close
to the resource properties. Something that is confusing to me with
this change is the inconsistent naming:

struct rdt_fs_context:
	bool			enable_mba_mbps
	enum resctrl event_id	mba_mbps_event

struct resctrl_membw:
	bool			mba_sc
	enum resctrl_event_id	mba_mbps_event


The intention with the above naming is not obvious to me. How are
these intended to be viewed?

One option could be to view these as separately representing user
space (struct rdt_fs_context) and kernel space (struct resctrl_membw).
If this is the case then the following naming may be more intuitive:

struct rdt_fs_context:
	bool			enable_mba_mbps
	enum resctrl event_id	mba_mbps_event

struct resctrl_membw:
	bool			mba_sc
	enum resctrl_event_id	mba_sc_event


> 
> Mount option parsing (including blocking user from setting the options
> multiple times):
> 
> 	case Opt_mba_mbps:
> 		if (!supports_mba_mbps() || ctx->enable_mba_mbps)
> 			return -EINVAL;

I am not familiar with the API but it seems that invalfc() is available
to communicate a more useful message to user space than the default one
shown in changelog of patch #2.

> 		if (is_mbm_local_enabled())
> 			ctx->mba_mbps_event = QOS_L3_MBM_LOCAL_EVENT_ID;
> 		else if (is_mbm_total_enabled())
> 			ctx->mba_mbps_event = QOS_L3_MBM_TOTAL_EVENT_ID;
> 		else
> 			return -EINVAL;
> 		ctx->enable_mba_mbps = true;
> 		return 0;
> 	case Opt_mba_mbps_event:
> 		if (!supports_mba_mbps() || ctx->enable_mba_mbps)
> 			return -EINVAL;
> 		if (!strcmp("mbm_local_bytes", param->string))
> 			ctx->mba_mbps_event = QOS_L3_MBM_LOCAL_EVENT_ID;
> 		else if (!strcmp("mbm_total_bytes", param->string))
> 			ctx->mba_mbps_event = QOS_L3_MBM_TOTAL_EVENT_ID;
> 		else
> 			return -EINVAL;
> 		ctx->enable_mba_mbps = true;
> 		return 0;
> 
> 
> and use of the options to enable the feature:
> 
> 	if (ctx->enable_mba_mbps) {
> 		r->membw.mba_mbps_event = ctx->mba_mbps_event;
> 		ret = set_mba_sc(true);
> 		if (ret)
> 			goto out_cdpl3;
> 	}

Since 0 will not be used for an unset/invalid value I expect mba_mbps_event
will not (cannot) be cleared by rdt_disable_ctx(). If this is the case I think
future changes can be supported by expanding the kerneldoc of struct resctrl_membw
to document that "@mba_mbps_event (or @mba_sc_event?) is invalid if @mba_sc
is false".

Reinette