Thread (45 messages) 45 messages, 7 authors, 2014-06-02

[PATCH v1 5/5] pci: keystone: add pcie driver based on designware core driver

From: Jason Gunthorpe <hidden>
Date: 2014-05-20 17:42:42
Also in: linux-pci, lkml

On Tue, May 20, 2014 at 11:22:22AM -0600, Bjorn Helgaas wrote:
On Tue, May 20, 2014 at 11:02 AM, Jason Gunthorpe
[off-list ref] wrote:
quoted
On Fri, May 16, 2014 at 08:29:56PM +0000, Karicheri, Muralidharan wrote:
quoted
But pcie_bus_configure_settings just make sure the mrrs for a device
is not greater than the max payload size.
Not quite, it first scans the network checking the Maximum Payload Size
Supported (MPSS) for each device, and chooses the highest supported by
all as the MPS for all.
The "performance" setting, e.g., "pci=pcie_bus_perf", adds a few
wrinkles by setting MRRS in ways that allow some devices to have
larger MPS than others.  I don't think this is exactly what was
envisioned in the spec, and it is not guaranteed to work if there is
peer-to-peer DMA.  This isn't documented very well; the best I know of
is the changelogs for:

  a1c473aa11e6 pci: Clamp pcie_set_readrq() when using "performance" settings
  b03e7495a862 PCI: Set PCI-E Max Payload Size on fabric
Neat, and does pretty much confirm that setting the host bridge MPSS
properly is necessary to support all drivers, particularly the ones
that call pcie_set_readrq with any old value.

The 'performance' setting is a bit scary, it isn't just peer-to-peer
DMA that would be impacted but also CPU initiated burst writes. Eg
InfiniBand drivers burst a WQE to the NIC via the CPU. The MPS on the
root port bridge is used to segment the write. Probably not a problem
in practice because I think this is rare, and even rarer that a burst
would be > 128 bytes - but as you say, not really what the spec
intended..

Jason
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help