From: Bjorn Helgaas <helgaas@kernel.org>
To: Tyler Hicks <code@tyhicks.com>
Cc: Keith Busch <kbusch@kernel.org>,
bhelgaas@google.com, linux-pci@vger.kernel.org,
Zhiqiang Hou <Zhiqiang.Hou@nxp.com>,
Lorenzo Pieralisi <lpieralisi@kernel.org>
Subject: Re: [PATCH] PCI: Align MPS to upstream bridge for SAFE and PERFORMANCE mode
Date: Thu, 3 Nov 2022 17:14:29 -0500 [thread overview]
Message-ID: <20221103221429.GA47218@bhelgaas> (raw)
In-Reply-To: <20221027225149.GA846989@bhelgaas>
On Thu, Oct 27, 2022 at 05:51:49PM -0500, Bjorn Helgaas wrote:
> On Tue, Oct 25, 2022 at 12:07:47AM -0500, Tyler Hicks wrote:
> > On 2022-10-20 15:24:37, Bjorn Helgaas wrote:
> > I've been talking to the firmware folks on why SAFE mode was selected,
> > based on Keith's question from Wednesday. From what I've been told,
> > U-Boot doesn't seed the RP MPS with a value so the kernel sees a value
> > of 128 for p_mps in pci_configure_mps() when using the DEFAULT mode.
> > Apparently UEFI does seed the RP MPS but we don't get that with U-Boot.
> > Therefore, SAFE mode was selected to get an initial, tuned RP MPS value
> > set to 256.
>
> Are there any devices below the RP at the time we set MPS=256?
>
> > > A subsequent hot-add will do nothing in pci_configure_mps(), and
> > > pcie_bus_configure_settings() looks like it would set the RP and EP
> > > MPS to the minimum of the RP and EP MPS_Supported.
> > >
> > > Is that what you see? What would you like to see instead?
> >
> > No, not quite. After hot-add, we see the EP MPS set to 128 with SAFE
> > mode even though the RP MPS is 256.
>
> Can you add the relevant topology here so we can work through the
> concrete details? Is the endpoint hot-added directly below a Root
> Port? Or is there a switch involved? What are the MPS_Supported
> values for all the devices? If there's a switch in the picture, it
> looks like we currently restrict to 128, I think because it's possible
> an endpoint that can only do 128 may be added.
Ping? I'd like to talk about a concrete scenario. It's too hard for
me to imagine all the possible things that could go wrong.
I guess part of what's interesting here is that things work better
when firmware has already configured MPS? It doesn't seem like we
should *depend* on firmware having done that.
Bjorn
next prev parent reply other threads:[~2022-11-03 22:14 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-10 15:01 [PATCH] PCI: Align MPS to upstream bridge for SAFE and PERFORMANCE mode Zhiqiang Hou
2022-07-13 10:21 ` Z.Q. Hou
2022-08-26 15:49 ` Tyler Hicks
2022-09-14 14:41 ` Tyler Hicks
2022-10-13 3:48 ` Tyler Hicks
2022-10-19 18:25 ` Tyler Hicks
2022-10-19 18:30 ` Keith Busch
2022-10-20 20:24 ` Bjorn Helgaas
2022-10-25 5:07 ` Tyler Hicks
2022-10-27 22:51 ` Bjorn Helgaas
2022-11-03 22:14 ` Bjorn Helgaas [this message]
2022-11-09 23:41 ` Tyler Hicks (Microsoft)
2023-01-04 0:14 ` Tyler Hicks
2022-11-13 18:39 ` Z.Q. Hou
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=20221103221429.GA47218@bhelgaas \
--to=helgaas@kernel.org \
--cc=Zhiqiang.Hou@nxp.com \
--cc=bhelgaas@google.com \
--cc=code@tyhicks.com \
--cc=kbusch@kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lpieralisi@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.