From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 2050C230BD8 for ; Fri, 28 Feb 2025 19:55:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740772530; cv=none; b=lYSZ43Y9aapHL3EEN6FAdVzg4f8F5QHkFXkhLedBG8u7NVaHKuPmWHH1d0EVrxMVETPf8syRZIx8tVOSrgD0juWWkkgi8LqoXMJqUKMt6owTu7W4/nq87ahHJ/LIsEPYuMeHd1gw5G5fCpfTxs2VH9N8woS1B++RqES9h707g24= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740772530; c=relaxed/simple; bh=+tfHQjfpf/kVJGDuX+IhePHsJLEjr3Ddygk5rSJAQU4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=otdMeucm9bryeX9dneKLqmDToab/0fP3R2UsgjZCKR2Aml50QzSmEIZRkncwDcuZGW5d7bCilMV+qFagJTcEMyWGS/FwUPPjyG6oCG2P7pt0hwhHIu6IVvYPWPmj//bQL5pBvmkgVHBcG3IMuuSisd34k8p+QgUeLfVufov2x3g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C0EB41007; Fri, 28 Feb 2025 11:55:43 -0800 (PST) Received: from [10.1.197.49] (eglon.cambridge.arm.com [10.1.197.49]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id DF4DB3F5A1; Fri, 28 Feb 2025 11:55:21 -0800 (PST) Message-ID: <7562c41a-42f1-4d33-a543-d92ead1d72da@arm.com> Date: Fri, 28 Feb 2025 19:55:19 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 36/42] x86/resctrl: Add end-marker to the resctrl_event_id enum To: babu.moger@amd.com, x86@kernel.org, linux-kernel@vger.kernel.org Cc: Reinette Chatre , Thomas Gleixner , Ingo Molnar , Borislav Petkov , H Peter Anvin , shameerali.kolothum.thodi@huawei.com, D Scott Phillips OS , carl@os.amperecomputing.com, lcherian@marvell.com, bobo.shaobowang@huawei.com, tan.shaopeng@fujitsu.com, baolin.wang@linux.alibaba.com, Jamie Iles , Xin Hao , peternewman@google.com, dfustini@baylibre.com, amitsinght@marvell.com, David Hildenbrand , Rex Nie , Dave Martin , Koba Ko , Shanker Donthineni , Shaopeng Tan , Tony Luck References: <20250207181823.6378-1-james.morse@arm.com> <20250207181823.6378-37-james.morse@arm.com> Content-Language: en-GB From: James Morse In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Babu, On 27/02/2025 20:26, Moger, Babu wrote: > On 2/7/25 12:18, James Morse wrote: >> The resctrl_event_id enum gives names to the counter event numbers on x86. >> These are used directly by resctrl. >> >> To allow the MPAM driver to keep an array of these the size of the enum >> needs to be known. >> >> Add a 'num_events' define which can be used to size an array. This isn't >> a member of the enum to avoid updating switch statements that would >> otherwise be missing a case. >> diff --git a/include/linux/resctrl_types.h b/include/linux/resctrl_types.h >> index 51c51a1aabfb..70226f5ab3e3 100644 >> --- a/include/linux/resctrl_types.h >> +++ b/include/linux/resctrl_types.h >> @@ -51,4 +51,6 @@ enum resctrl_event_id { >> QOS_L3_MBM_LOCAL_EVENT_ID = 0x03, >> }; >> >> +#define QOS_NUM_EVENTS (QOS_L3_MBM_LOCAL_EVENT_ID + 1) > Why cant this be part of "enum resctrl_event_id" like we defined > RDT_NUM_RESOURCES? Maybe its a difference that only exists in my head, but the rdt resource array is completely a resctrl concept, the positions in the enum don't mean anything. Not so for for resctrl_event_id - those numbers mean something to the X86 CPUs. Resctrl needs some unique identifier for those, and its simpler just to use these directly. I didn't want to add anything to this enum. If there are mpam specific events, (currently there is only the risk of bandwidth counters on the L2, or scattered at random through the system), I'd prefer to support them via perf and keep them out of here completely. Thanks, James