Linux CXL
 help / color / mirror / Atom feed
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


  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