All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Krzysztof Hałasa" <khalasa@piap.pl>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: linux-pci@vger.kernel.org, Artem Lapkin <email2tema@gmail.com>,
	Neil Armstrong <narmstrong@baylibre.com>,
	Huacai Chen <chenhuacai@gmail.com>
Subject: Re: ARM Max Read Req Size and PCIE_BUS_PERFORMANCE stories
Date: Wed, 11 Aug 2021 08:33:48 +0200	[thread overview]
Message-ID: <m3r1f08p83.fsf@t19.piap.pl> (raw)
In-Reply-To: <20210810232736.GA2315513@bjorn-Precision-5520> (Bjorn Helgaas's message of "Tue, 10 Aug 2021 18:27:36 -0500")

Hi Bjorn,

Bjorn Helgaas <helgaas@kernel.org> writes:

> Super.  IIUC, i.MX6 is another DWC-based controller, so this looks
> like another case of the issue that afflicts amlogic, keystone,
> loongson (weirdly apparently *not* DWC-based), meson, and probably
> others.
>
> Some previous discussion here:
> https://lore.kernel.org/linux-pci/20210707155418.GA897940@bjorn-Precision-5520/

Ok. So I guess the fix for i.MX6 is a simple PCI fixup, limiting MRRS to
512 (while MPS = 128).

Now the Kconfig states that MRRS=MPS is the "best performance" case. Is
it really true? One could think requesting 512 bytes (memory read)
completed with 4 response packets 128 bytes each could be faster than
4 requests and 4 responses. Various docs suggest that lowering MRRS is
good for "interactivity", but not exactly for throughput.
Should I do some benchmarking?

> This sounds like a defect in the CPU/PCI host adapter.  If the device
> initiates a 4096-byte read and the CPU or whatever can't deal with it,
> the host adapter should break it up into whatever the CPU *can*
> handle.  I don't think this is the device's problem or the device
> driver's problem.

As I see it, this is not a CPU (ARM core, IXI bus etc) problem. This is
DWC PCIe thing, and the cause is apparently the size of its buffers.
That's why the max number of tags (which I assume is a number of
individual read requests) depends on the MRRS size.

The PCIe 3 docs state:
Max_Read_Request_Size – This field sets the maximum Read
Request size for the Function as a Requester. The Function
must not generate Read Requests with a size exceeding the set
value.

Not sure about the "set value", but perhaps a limit (lower than 4096) is
permitted - e.g. for the whole system or bus.

The i.MX6 errata list states:
"ERR003754 PCIe: 9000403702—AHB/AXI Bridge Master responds with UR
status instead of CA status for inbound MRd requesting greater than
CX_REMOTE_RD_REQ_SIZE

Description:
         The AHB/AXI Bridge RAM is sized at configuration time to support inbound read requests with a
         maximum size of CX_REMOTE_RD_REQ_SIZE. When this limit is violated the core responds
         with UR status, when it should respond with CA status."

The above suggests that aborting an oversized read request is ok. It
should be done with a CA (Completer Abort) code rather than UR
(Unsupported Request), but that's just a difference in the error code.

>> 2. should the PCI code limit MRRS to MPS by default?
>> 3. should the PCI code limit MRRS to the maximum safe value (512 on
>>    this CPU)?
>
> How do we learn the maximum safe value?  Is this something a native
> driver could read from PCIE_PL_MRCCR0 (see below)?

It will read "512" by default (unless maybe some boot loader etc.
changed it).
I think, for these particular SoCs, a fixed 512 would do.
But perhaps we could experiment with larger values, which need to be
*written* to this register before use.

I will think about it.
-- 
Krzysztof "Chris" Hałasa

Sieć Badawcza Łukasiewicz
Przemysłowy Instytut Automatyki i Pomiarów PIAP
Al. Jerozolimskie 202, 02-486 Warszawa

      reply	other threads:[~2021-08-11  6:33 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-10 10:40 ARM Max Read Req Size and PCIE_BUS_PERFORMANCE stories Krzysztof Hałasa
2021-08-10 23:27 ` Bjorn Helgaas
2021-08-11  6:33   ` Krzysztof Hałasa [this message]

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=m3r1f08p83.fsf@t19.piap.pl \
    --to=khalasa@piap.pl \
    --cc=chenhuacai@gmail.com \
    --cc=email2tema@gmail.com \
    --cc=helgaas@kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=narmstrong@baylibre.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 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.