From: Bjorn Helgaas <helgaas@kernel.org>
To: Sinan Kaya <okaya@codeaurora.org>
Cc: linux-pci@vger.kernel.org
Subject: Re: ECRC and Max Read Request Size
Date: Fri, 6 Nov 2015 11:22:05 -0600 [thread overview]
Message-ID: <20151106172205.GA1002@localhost> (raw)
In-Reply-To: <56310B34.6000102@codeaurora.org>
Hi Sinan,
On Wed, Oct 28, 2015 at 01:51:48PM -0400, Sinan Kaya wrote:
> I'm seeing two problems with the current PCI framework when it comes
> to end-to-end CRC (ECRC) and Max Read Request Size.
>
> The problem with ECRC is that it blindly enables ECRC generation on
> devices without checking if it is supported by the entire bus with
> ECRC=on option.
>
> ECRC check can be enabled on all devices but ECRC generation on the
> root complex and switches needs to be set only if all devices
> support ECRC checking.
>
> I'm thinking of making changes in this area to cover this gap with
> ECRC=safe option.
Sometimes they can't be avoided, but I'm generally not in favor of
adding command line parameters because they require too much of our
users and they introduce code paths that are rarely exercised.
What specific ECRC problem are you seeing? Do you have devices that
don't operate correctly with the current code? Or do you want to add
some new functionality, e.g., to enable ECRC in cases where we don't
enable it today?
> The other problem I'm seeing is about the maximum read request size.
> If I choose the PCI bus performance mode, maximum read request size
> is being limited to the maximum payload size.
>
> I'd like to add a new mode where I can have bigger read request size
> than the maximum payload size.
I've never been thrilled about the way Linux ties MRRS and MPS
together. I don't think the spec envisioned MRRS being used to
control segment size on the link. My impression is that the purpose
of MRRS is to limit the amount of time one device can dominate a link.
I am sympathetic to the idea of having MRRS larger than MPS. The
question is how to accomplish that. I'm not really happy with the
current set of "pcie_bus_tune_*" parameters, so I'd hesitate to add
yet another one. They feel like they're basically workarounds for the
fact that Linux can't optimize MPS directly itself.
Can you give any more specifics of your MRRS/MPS situation? I guess
you hope to improve bandwidth to some device by reducing the number of
read requests? Do you have any quantitative estimate of what you can
gain?
Bjorn
next prev parent reply other threads:[~2015-11-06 17:22 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-28 17:51 ECRC and Max Read Request Size Sinan Kaya
2015-11-06 17:22 ` Bjorn Helgaas [this message]
2015-11-06 17:54 ` Sinan Kaya
2015-11-07 0:11 ` Bjorn Helgaas
2015-11-07 3:39 ` Sinan Kaya
2015-11-09 19:47 ` Bjorn Helgaas
2015-11-10 0:09 ` Sinan Kaya
2015-11-09 19:15 ` Bjorn Helgaas
2015-11-10 0:43 ` Sinan Kaya
2015-11-08 17:20 ` Sinan Kaya
-- strict thread matches above, loose matches on Subject: below --
2015-10-26 18:42 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=20151106172205.GA1002@localhost \
--to=helgaas@kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=okaya@codeaurora.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).