From: Bjorn Helgaas <helgaas@kernel.org>
To: "Krzysztof Hałasa" <khalasa@piap.pl>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
Arnd Bergmann <arnd@arndb.de>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH REPOST] Extend PCIE_BUS_PEER2PEER to set MRSS=128 to fix CNS3xxx BM DMA.
Date: Wed, 4 May 2016 14:47:11 -0500 [thread overview]
Message-ID: <20160504194711.GB3117@localhost> (raw)
In-Reply-To: <m3y47qdl6g.fsf@t19.piap.pl>
On Wed, May 04, 2016 at 03:09:27PM +0200, Krzysztof Hałasa wrote:
> Bjorn Helgaas <helgaas@kernel.org> writes:
>
> > It looks like 498a92d42596 merely fixed a warning, at the expense of
> > breaking DMA on Cavium. Reverting it would bring the warning back, but
> > that's better than broken DMA.
>
> Perhaps we should change PCIE_BUS_PEER2PEER to also write MRRS anyway.
>
> I realize the CNS3xxx patch is some sort of clever workaround, and that
> PCIE_BUS_PEER2PEER (which normally comes from kernel command line
> parameter "pcie_bus_peer2peer") was not exactly intended for this. But
> if one asks for "peer2peer" (which means limiting transfers to 128
> bytes), how could it all work if the bus mastering read requests are
> not equally limited?
MPS=128 means a function will never generate a TLP exceeding 128
bytes. MRRS=128 means a function will never generate a Read Request
with a size exceeding 128 bytes.
The comment in pcie_write_mrrs() claims:
... the MRRS ... cannot be configured larger than the MPS the
device or the bus can support.
I think this comment is wrong, at least from a hardware point of view.
Setting all devices to MRRS=512 and MPS=128 is a legal configuration
that means functions may receive Read Requests for up to 512 bytes,
and they will have to respond with 4 128-byte TLPs.
The spec (PCIe r3.0, 7.8.4 implementation note) says:
The Max_Read_Request_Size mechanism allows improved control of
bandwidth allocation in systems where quality of service (QoS) is
important for the target applications. For example, an arbitration
scheme based on counting Requests (and not the sizes of those
Requests) provides imprecise bandwidth allocation when some
Requesters use much larger sizes than others. The
Max_Read_Request_Size mechanism can be used to force more uniform
allocation of bandwidth, by restricting the upper size of Read
Requests.
The Linux usage of tying it to MRRS to MPS is part of a plan to use
MRRS to restrict the TLP size in one direction and MPS to restrict TLP
size in the other. See b03e7495a862 ("PCI: Set PCI-E Max Payload Size
on fabric"). But this is not in line with the spec intention, and I'm
not 100% convinced that it works reliably.
So I'm a little wary of tweaking our MPS/MRRS configuration without a
more extensive analysis and (hopefully) some simplification of the
code.
Bjorn
next prev parent reply other threads:[~2016-05-04 19:47 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-21 9:39 [PATCH REPOST] Extend PCIE_BUS_PEER2PEER to set MRSS=128 to fix CNS3xxx BM DMA Krzysztof Halasa
2016-04-21 15:42 ` Bjorn Helgaas
2016-05-02 16:53 ` Bjorn Helgaas
2016-05-04 13:09 ` Krzysztof Hałasa
2016-05-04 19:47 ` Bjorn Helgaas [this message]
2016-05-31 20:12 ` Bjorn Helgaas
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=20160504194711.GB3117@localhost \
--to=helgaas@kernel.org \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=khalasa@piap.pl \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.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;
as well as URLs for NNTP newsgroup(s).