public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Daniel Tsai <danielsftsai@google.com>
Cc: "Jingoo Han" <jingoohan1@gmail.com>,
	"Manivannan Sadhasivam" <manivannan.sadhasivam@linaro.org>,
	"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Rob Herring" <robh@kernel.org>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] PCI: dwc: Separate MSI out to different controller
Date: Wed, 15 Jan 2025 15:23:39 -0600	[thread overview]
Message-ID: <20250115212339.GA553488@bhelgaas> (raw)
In-Reply-To: <20250115083215.2781310-1-danielsftsai@google.com>

On Wed, Jan 15, 2025 at 08:32:15AM +0000, Daniel Tsai wrote:
> From: Tsai Sung-Fu <danielsftsai@google.com>
> 
> Setup the struct irq_affinity at EP side, and passing that as 1 of the
> function parameter when endpoint calls pci_alloc_irq_vectors_affinity,
> this could help to setup non-default irq_affinity for target irq (end up
> in irq_desc->irq_common_data.affinity), and we can make use of that to
> separate msi vector out to bind to other msi controller.
> 
> In current design, we have 8 msi controllers, and each of them own up to
> 32 msi vectors, layout as below
> 
> msi_controller0 <- msi_vector0 ~ 31
> msi_controller1 <- msi_vector32 ~ 63
> msi_controller2 <- msi_vector64 ~ 95
> .
> .
> .
> msi_controller7 <- msi_vector224 ~ 255
> 
> dw_pcie_irq_domain_alloc is allocating msi vector number in a contiguous
> fashion, that would end up those allocated msi vectors all handled by
> the same msi_controller, which all of them would have irq affinity in
> equal. To separate out to different CPU, we need to distribute msi
> vectors to different msi_controller, which require to allocate the msi
> vector in a stride fashion.
> 
> To do that, the CL make use the cpumask_var_t setup by the endpoint,
> compare against to see if the affinities are the same, if they are,
> bind to msi controller which previously allocated msi vector goes to, if
> they are not, assign to new msi controller.

It's crunch time right now getting ready for the merge window, but
some superficial things you can address when you get more detailed
feedback later:

Add "()" after function names.

s/EP/Endpoint/ at least the first time it's used
s/msi/MSI/ in English text
s/irq/IRQ/
s/the CL make use/use/ ("CL" looks like a Google-ism)

> +	 * All IRQs on a given controller will use the same parent interrupt,
> +	 * and therefore the same CPU affinity. We try to honor any CPU spreading
> +	 * requests by assigning distinct affinity masks to distinct vectors.
> +	 * So instead of always allocating the msi vectors in a contiguous fashion,
> +	 * the algo here honor whoever comes first can bind the msi controller to
> +	 * its irq affinity mask, or compare its cpumask against
> +	 * currently recorded to decide if binding to this msi controller.

Wrap comment to fit in 80 columns like the rest of the file.

s/msi/MSI/
s/irq/IRQ/

> +		 * no msi controller matches, we would error return (no space) and
> +		 * clear those previously allocated bit, because all those msi vectors
> +		 * didn't really successfully allocated, so we shouldn't occupied that
> +		 * position in the bitmap in case other endpoint may still make use of
> +		 * those. An extra step when choosing to not allocate in contiguous
> +		 * fashion.

Similar.

Capitalize beginning of sentence.

Some of these are not quite sentences or have grammatical issues.

Bjorn

  reply	other threads:[~2025-01-15 21:23 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-15  8:32 [PATCH] PCI: dwc: Separate MSI out to different controller Daniel Tsai
2025-01-15 21:23 ` Bjorn Helgaas [this message]
2025-01-27 10:07 ` Manivannan Sadhasivam
2025-02-11  7:16   ` Tsai Sung-Fu
2025-02-11  7:56     ` Manivannan Sadhasivam
2025-02-11  8:22       ` Tsai Sung-Fu
2025-02-11  8:23       ` Tsai Sung-Fu
2025-02-14  7:15         ` Manivannan Sadhasivam
2025-02-14 19:54           ` Brian Norris
2025-02-19 17:51             ` Manivannan Sadhasivam
2025-02-19 18:02               ` Marc Zyngier
2025-02-19 18:09                 ` Manivannan Sadhasivam
2025-03-03  7:08                   ` Tsai Sung-Fu

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=20250115212339.GA553488@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=danielsftsai@google.com \
    --cc=jingoohan1@gmail.com \
    --cc=kw@linux.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=manivannan.sadhasivam@linaro.org \
    --cc=robh@kernel.org \
    /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