From: Bjorn Helgaas <helgaas@kernel.org>
To: Ron Yuan <ron.yuan@memblaze.com>
Cc: Sinan Kaya <okaya@codeaurora.org>,
Bjorn Helgaas <bhelgaas@google.com>,
Bo Chen <bo.chen@memblaze.com>,
William Huang <william.huang@memblaze.com>,
Fengming Wu <fengming.wu@memblaze.com>,
Jason Jiang <jason.jiang@microsemi.com>,
Radjendirane Codandaramane <radjendirane.codanda@microsemi.com>,
Ramyakanth Edupuganti <Ramyakanth.Edupuganti@microsemi.com>,
William Cheng <william.cheng@microsemi.com>,
"Kim Helper (khelper)" <khelper@micron.com>,
Linux PCI <linux-pci@vger.kernel.org>
Subject: Re: One Question About PCIe BUS Config Type with pcie_bus_safe or pcie_bus_perf On NVMe Device
Date: Tue, 23 Jan 2018 11:48:21 -0600 [thread overview]
Message-ID: <20180123174821.GF5317@bhelgaas-glaptop.roam.corp.google.com> (raw)
In-Reply-To: <SHAPR01MB173D186666EBAFEC5367AACFEE30@SHAPR01MB173.CHNPR01.prod.partner.outlook.cn>
On Tue, Jan 23, 2018 at 02:01:27PM +0000, Ron Yuan wrote:
> Just got the log, see attachment. Kernel is under "perf" mode.
> SSD and Ethernet controller are both set to 256B MRRS.
Here's what I see from lspci:
3a:00.0 Root Port to 3b MPS_cap=256 MPS=256 MRRS=128
3b:00.0 NIC Endpoint MPS_cap=512 MPS=256 MRRS=256
3b:00.1 NIC Endpoint MPS_cap=512 MPS=256 MRRS=256
Here, the NICs support up to MPS=512 but the Root Port only supports
MPS=256. We must set MPS=256 for the NICs. Otherwise, the NICs could
do 512-byte DMA writes to system memory, and the Root Port would treat
those TLPs as malformed.
There is no need to limit MRRS because there are no other devices
under this Root Port. We can't tell from lspci what the maximum MRRS
is, but if the NICs support MRRS=4096, we could use that.
ae:00.0 Root Port to af MPS_cap=256 MPS=256 MRRS=128
ae:01.0 Root Port to b0 MPS_cap=256 MPS=256 MRRS=128
af:00.0 SSD Endpoint MPS_cap=256 MPS=256 MRRS=256
b0:00.0 SSD Endpoint MPS_cap=256 MPS=256 MRRS=256
Everything here supports MPS=256, so that's what we should use.
As with the NICs, there's no need to limit MRRS here. We don't know
what MRRS the endpoints support, but PERFORMANCE mode is being
unnecessarily conservative when it limits MRRS to the MPS (256 in this
case).
It's not as simple as just removing the "set MRRS=MPS" part because we
do rely on that in some topologies. There are interesting topologies
where we *don't* need it, like both of the ones above, and we need to
make Linux smart enough to recognize them.
next prev parent reply other threads:[~2018-01-23 17:48 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <SH2PR01MB106A1E21DEB5FE3FFB3D61C83E90@SH2PR01MB106.CHNPR01.prod.partner.outlook.cn>
[not found] ` <ef16a3cc-b641-a30d-644a-7940e340eb3e@codeaurora.org>
[not found] ` <SHAPR01MB173A5EA1677C2138CB528F2FEE90@SHAPR01MB173.CHNPR01.prod.partner.outlook.cn>
[not found] ` <5727b0b1-f0d5-7c78-373e-fc9d1bd662d2@codeaurora.org>
[not found] ` <CABhMZUU0643U-qVc9ymA+1PMZToSLFm2dg8-cu=iQ2LGw2Pi8Q@mail.gmail.com>
[not found] ` <SHAPR01MB173A36104635A8BFF9A83E1FEE80@SHAPR01MB173.CHNPR01.prod.partner.outlook.cn>
2018-01-18 16:24 ` One Question About PCIe BUS Config Type with pcie_bus_safe or pcie_bus_perf On NVMe Device Sinan Kaya
2018-01-19 20:51 ` Bjorn Helgaas
2018-01-20 19:20 ` Sinan Kaya
2018-01-20 19:29 ` Sinan Kaya
2018-01-22 21:36 ` Bjorn Helgaas
2018-01-22 22:04 ` Sinan Kaya
2018-01-22 22:51 ` Bjorn Helgaas
2018-01-22 23:24 ` Sinan Kaya
2018-01-23 0:16 ` Bjorn Helgaas
2018-01-23 2:27 ` Sinan Kaya
2018-01-23 13:25 ` Ron Yuan
2018-01-23 14:01 ` Ron Yuan
2018-01-23 17:48 ` Bjorn Helgaas [this message]
2018-01-23 18:07 ` Bjorn Helgaas
2018-01-23 14:38 ` Bjorn Helgaas
2018-01-23 23:50 ` Radjendirane Codandaramane
2018-01-24 16:29 ` Myron Stowe
2018-01-24 17:59 ` Ron Yuan
2018-01-24 18:01 ` Bjorn Helgaas
2018-01-31 8:40 ` Ron Yuan
2018-02-01 0:01 ` Myron Stowe
2018-02-01 0:13 ` Sinan Kaya
2018-02-01 3:37 ` Bjorn Helgaas
2018-02-01 15:14 ` Sinan Kaya
2018-02-05 1:02 ` Sinan Kaya
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=20180123174821.GF5317@bhelgaas-glaptop.roam.corp.google.com \
--to=helgaas@kernel.org \
--cc=Ramyakanth.Edupuganti@microsemi.com \
--cc=bhelgaas@google.com \
--cc=bo.chen@memblaze.com \
--cc=fengming.wu@memblaze.com \
--cc=jason.jiang@microsemi.com \
--cc=khelper@micron.com \
--cc=linux-pci@vger.kernel.org \
--cc=okaya@codeaurora.org \
--cc=radjendirane.codanda@microsemi.com \
--cc=ron.yuan@memblaze.com \
--cc=william.cheng@microsemi.com \
--cc=william.huang@memblaze.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;
as well as URLs for NNTP newsgroup(s).