Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp667894pxf; Thu, 8 Apr 2021 10:23:07 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwySi2cHWVDSGTtJOOoU0rMLTMWWJnu7D5zA/FTMfwi0/ybHqCnEz8N3vyVQPZzsSLuLb79 X-Received: by 2002:a17:902:ec88:b029:e9:589a:c64c with SMTP id x8-20020a170902ec88b02900e9589ac64cmr9075672plg.78.1617902587728; Thu, 08 Apr 2021 10:23:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617902587; cv=none; d=google.com; s=arc-20160816; b=esixS6Ox0OXZaFkZuoMVZUwTmRgtKWwYRpHhoJgxgJJek6LKTSH+EGd1FvMzlIrosv dcgs0zlfyvx1nDmPXCtHM5KeAjgYhbl8XKNwNkT5kg2ALf5S4LqFDTzItulf6jD3ONal UnDPPNyj3C8iloFGQ5eNkNlkmG9ILkYz9mVvchEOxGY3bAHf7GCFXBQ696V+n1HcAm/+ 5oHuM/WfrgcBmNjRf9ZmE8fAOtbWJPflFy4udZGVNy6ssCefLpKUSG060dgyj+5kFrGO xGcHTIm9Cgl5y0NsHXINvyr73XqufZGxSrW0/yUmoCD7yJLrmZqBqPIaBaCU6bZH2BoA 6QHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=wt24Z5u86JFmMxMYXkjhfDlEPDTCmtjuUzj+DEjD3To=; b=g79g8mnvba3hA308ncbpv8VdHN42aa/Tvj9HQ52KT2TeGt06f2xICvrfFuqhiOQYwt 7NeV4bG3CtiWSHGqufU8kg2d0FB6B8jMOTgo+2TiUpHopKOVeROHeKpadaPE34zrZBt/ NY4jDLw3uocEFtAnwyZEycgWb7pwyrLQrXs25aEMvVo6iS9y4tWv1jGG1oB4yIbXym1X shxHB/QZDMHfIk/Qf3JX8ACF/LjjlDdbwqUUXK3xQESSC4K5sWT0/RzmPfEm7o7NUdyi aZmcfOfONFxDqpGb2JV0FbTOCWQM60k/9SjIDKk1GyarM7z8AzHm1afEj6NWUH+Birft 1LmQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m3si3774147pfh.297.2021.04.08.10.22.54; Thu, 08 Apr 2021 10:23:07 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232694AbhDHRVG (ORCPT + 99 others); Thu, 8 Apr 2021 13:21:06 -0400 Received: from foss.arm.com ([217.140.110.172]:55416 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231716AbhDHRVA (ORCPT ); Thu, 8 Apr 2021 13:21:00 -0400 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 6B0A7106F; Thu, 8 Apr 2021 10:20:48 -0700 (PDT) Received: from [192.168.0.14] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 129FF3F792; Thu, 8 Apr 2021 10:20:45 -0700 (PDT) Subject: Re: [PATCH v2 02/24] x86/resctrl: Split struct rdt_domain To: Reinette Chatre , x86@kernel.org, linux-kernel@vger.kernel.org Cc: Fenghua Yu , Thomas Gleixner , Ingo Molnar , Borislav Petkov , H Peter Anvin , Babu Moger , shameerali.kolothum.thodi@huawei.com, Jamie Iles , D Scott Phillips OS References: <20210312175849.8327-1-james.morse@arm.com> <20210312175849.8327-3-james.morse@arm.com> <9cb3f9c9-8295-6e40-9f98-1944b9b3c59b@intel.com> From: James Morse Message-ID: Date: Thu, 8 Apr 2021 18:20:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <9cb3f9c9-8295-6e40-9f98-1944b9b3c59b@intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Reinette, On 31/03/2021 22:36, Reinette Chatre wrote: > On 3/12/2021 9:58 AM, James Morse wrote: >> resctrl is the defacto Linux ABI for SoC resource partitioning features. >> To support it on another architecture, it needs to be abstracted from >> the features provided by Intel RDT and AMD PQoS, and moved to /fs/. >> >> Split struct rdt_domain up too. Move everything that that is particular > > s/that that/that/ > >> to resctrl into a new header file. resctrl code paths touching a 'hw' >> struct indicates where an abstraction is needed. > > Similar to previous patch it would help to explain how this split was chosen. For example, > why are the CPUs to which a resource is associated not considered a hardware property? Similarly, because the meaning of those CPUs doesn't differ or change between architectures. I've expanded the middle paragraph in the commit message to explain why the arch specific things are arch specific: | Continue by splitting struct rdt_domain, into an architecture private | 'hw' struct, which contains the common resctrl structure that would be | used by any architecture. | | The hardware values in ctrl_val and mbps_val need to be accessed via | helpers to allow another architecture to convert these into a different | format if necessary. | | After this split, filesystem code code paths touching a 'hw' struct | indicates where an abstraction is needed. and similarly changed the kernel doc comment. Let me know if you prefer some other struct name. Thanks, James