From: Dave Jiang <dave.jiang@intel.com>
To: Alison Schofield <alison.schofield@intel.com>
Cc: Davidlohr Bueso <dave@stgolabs.net>,
Jonathan Cameron <jonathan.cameron@huawei.com>,
Vishal Verma <vishal.l.verma@intel.com>,
Ira Weiny <ira.weiny@intel.com>,
Dan Williams <dan.j.williams@intel.com>,
linux-cxl@vger.kernel.org
Subject: Re: [PATCH] cxl/region: Allow 6 & 12 way regions on 3-way HB interleaves
Date: Tue, 25 Feb 2025 08:41:54 -0700 [thread overview]
Message-ID: <648bd488-a93f-4e6a-93cc-cc1841bebfc0@intel.com> (raw)
In-Reply-To: <Z70qiCzzusQ6XXhd@aschofie-mobl2.lan>
On 2/24/25 7:27 PM, Alison Schofield wrote:
> On Mon, Feb 24, 2025 at 05:41:20PM -0700, Dave Jiang wrote:
>>
>>
>> On 2/24/25 4:58 PM, alison.schofield@intel.com wrote:
>>> From: Alison Schofield <alison.schofield@intel.com>
>>>
>>> The CXL driver requires the granularity of a region and it's root
>>
>> s/it's/its/
>
> got it
>
>>
>>> decoder to be the same. This is particularly restrictive for 3-way
>>> host bridge interleaves where the only spec defined interleave
>>> configurations for creating 6-way and 12-way regions on a 3-way HB
>> configuration?
>>> interleave require mixed granularities.
>> requries?
>
> considering that
>
>>
>>>
>>> CXL 3.1 Specification 9.13.1.1:
>>
>> May as well go to 3.2
>>
>
> got it
>
>
>>> Legal Interleaving Configurations: 12-way, 6-way, and 3-way
>>>
>>> Adding support for these new interleaves touches these areas:
>>>
>>> 1) User created regions employing "cxl create-region" fail when the
>>> ndctl tool gets a mixed granularity request. That is addressed in
>> s/ndctl/CXL CLI/
>>
>
> got it
>
>
>>> a patch to the ndctl tool.
>>>
>
> snip
>
>>>
>>> +static bool interleave_granularity_allow(struct cxl_decoder *cxld, u16 ig)
>>> +{
>>> + /*
>>> + * When the host-bridge is interleaved, disallow region granularity
>>> + * != root granularity with the exception of 3-way HB interleaves.
>>> + * Allow the CXL Spec defined 3-way HB interleaves that can only be
>>> + * configured when host-bridge interleave is greater that the
>>> + * region interleave. (CXL 3.1 Specification 9.13.1.1)
>> spec 3.2
>>
>>> + * Allow 2+2+2 interleave where HB gran is 2 * region granularity
>>> + * 4+4+4 interleave where HB gran is 4 * region granularity
>>> + *
>>> + * Regions with a granularity greater than the root interleave result
>>> + * in invalid DPA translations (invalid to support).
>>> + */
>>> + if (cxld->interleave_ways > 1 && ig != cxld->interleave_granularity) {
>>> + if (cxld->interleave_ways != 3)
>>> + return false;
>>> +
>>> + if (cxld->interleave_granularity % (2 * ig) &&
>>> + cxld->interleave_granularity % (4 * ig))
>>> + return false;
>>
>> Can you please explain how the math works here? I'm not understanding the code here vs the comments above.
>
> I'm guessing you are talking about the last chunk only. We get there
> after discovering a 3-way HB interleave. (HB interleave and root decoder
> interleave are the same thing.) Once we know it's a 3-way, there are
> only 2 possible values and those are defined in the spec as:
> 2+2+2 interleave where HB gran is 2 * region granularity
> 4+4+4 interleave where HB gran is 4 * region granularity
>
> And now that I've gotten to this part of the explanation I think
> the code is allowing multiples of 2*ig and 4*ig, when it should
> be a stricter check for exactly 2*ig or 4*ig.
>
> updating that to:
> if (cxld->interleave_granularity != 2 * ig &&
> cxld->interleave_granularity != 4 * ig)
> return false;
>
Ok the new code make sense to me now. :)
> Thanks for that Dave!
>>
>> DJ
>>
>
> snip
next prev parent reply other threads:[~2025-02-25 15:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-24 23:58 [PATCH] cxl/region: Allow 6 & 12 way regions on 3-way HB interleaves alison.schofield
2025-02-25 0:41 ` Dave Jiang
2025-02-25 2:27 ` Alison Schofield
2025-02-25 15:41 ` Dave Jiang [this message]
2025-02-25 5:02 ` kernel test robot
2025-02-26 7:12 ` Li Ming
2025-03-06 22:15 ` Alison Schofield
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=648bd488-a93f-4e6a-93cc-cc1841bebfc0@intel.com \
--to=dave.jiang@intel.com \
--cc=alison.schofield@intel.com \
--cc=dan.j.williams@intel.com \
--cc=dave@stgolabs.net \
--cc=ira.weiny@intel.com \
--cc=jonathan.cameron@huawei.com \
--cc=linux-cxl@vger.kernel.org \
--cc=vishal.l.verma@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox