Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1754077AbcJKRIj (ORCPT <rfc822;w@1wt.eu>);
        Tue, 11 Oct 2016 13:08:39 -0400
Received: from mail-it0-f45.google.com ([209.85.214.45]:38159 "EHLO
        mail-it0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752183AbcJKRIh (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 11 Oct 2016 13:08:37 -0400
MIME-Version: 1.0
In-Reply-To: <20161010171902.GA30774@intel.com>
References: <1475894763-64683-1-git-send-email-fenghua.yu@intel.com>
 <1475894763-64683-6-git-send-email-fenghua.yu@intel.com> <CACbG30_cKCS7Tz2GSosybPycEgGP444U8ebU8_A_AVr84JDs7g@mail.gmail.com>
 <20161008203306.GA7672@linux.intel.com> <20161010171902.GA30774@intel.com>
From: Nilay Vaish <nilayvaish@gmail.com>
Date: Tue, 11 Oct 2016 12:07:33 -0500
Message-ID: <CACbG30-oAftpUZ0K0VdtN-HacWiQfD8ZXU5EvY_NYB4Vsr0gUQ@mail.gmail.com>
Subject: Re: [PATCH v3 05/18] Documentation, x86: Documentation for Intel
 resource allocation user interface
To: "Luck, Tony" <tony.luck@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        "H. Peter Anvin" <h.peter.anvin@intel.com>,
        Ingo Molnar <mingo@elte.hu>, Peter Zijlstra <peterz@infradead.org>,
        Stephane Eranian <eranian@google.com>, Borislav Petkov <bp@suse.de>,
        Dave Hansen <dave.hansen@intel.com>, Shaohua Li <shli@fb.com>,
        David Carrillo-Cisneros <davidcc@google.com>,
        Ravi V Shankar <ravi.v.shankar@intel.com>,
        Sai Prakhya <sai.praneeth.prakhya@intel.com>,
        Vikas Shivappa <vikas.shivappa@linux.intel.com>,
        linux-kernel <linux-kernel@vger.kernel.org>, x86 <x86@kernel.org>
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 2569
Lines: 67

On 10 October 2016 at 12:19, Luck, Tony <tony.luck@intel.com> wrote:
> On Sat, Oct 08, 2016 at 01:33:06PM -0700, Fenghua Yu wrote:
>> On Sat, Oct 08, 2016 at 12:12:07PM -0500, Nilay Vaish wrote:
>> > On 7 October 2016 at 21:45, Fenghua Yu <fenghua.yu@intel.com> wrote:
>> > > From: Fenghua Yu <fenghua.yu@intel.com>
>> > >
>> > > +L3 details (code and data prioritization disabled)
>> > > +--------------------------------------------------
>> > > +With CDP disabled the L3 schemata format is:
>> > > +
>> > > +       L3:<cache_id0>=<cbm>;<cache_id1>=<cbm>;...
>> > > +
>> > > +L3 details (CDP enabled via mount option to resctrl)
>> > > +----------------------------------------------------
>> > > +When CDP is enabled, you need to specify separate cache bit masks for
>> > > +code and data access. The generic format is:
>> > > +
>> > > +       L3:<cache_id0>=<d_cbm>,<i_cbm>;<cache_id1>=<d_cbm>,<i_cbm>;...
>> >
>> > Can we drop L3 here and instead say:
>> > L<level>:<cache_id0>=<d_cbm>,<i_cbm>;<cache_id1>=<d_cbm>,<i_cbm>;...
>> >
>> > and similarly for without CDP as well.
>>
>> L3 and L2 are similar but different. L2 doesn't have CDP feature. It would
>> be better to talk them separately here.
>>
>
> Perhaps we should document the general form, and then show examples
> for L3 (and later L2 and other resources as they are added). Note
> in particular that other resources are not cache-like ... so the
> pattern you see between L3 and L2 is short lived. Future resources
> that can be controlled are not caches.
>
> General form of a resource line is:
>
> {resource type}:[{resource instanceM}={resource value};]*N
>
> where "M" iterates over all online instances of this resource,
> and "N" is the total number. [and the ";" is a separator, not a terminator,
> but I'm not sure how to write that].
>
> For the "L3" resource there are two formats for the value.
> With CDP enabled:
>         {d-cache bit mask},{i-cache bit mask}
> with CDP disabled:
>         {cache bit mask}


I am in favour of documenting the general form, but Fenghua and you
can take a call on this.

>
> "L2" resource doesn't support CDP, so the only format is {cache bit mask}
>
>
> The next resource coming will have values that are simple ranges {0 .. max}
>

Regarding addition of more resources, I was wondering if one common
definition of struct rdt_resource to be used for each resource the way
to take.  As you point out, L2 caches will not support CDP, but cdp
would be part of the variable describing L2 cache.  Should we have
separate structs for each resource?

--
Nilay