From: Bjorn Helgaas <helgaas@kernel.org>
To: Sathyanarayanan Kuppuswamy <sathyanarayanan.kuppuswamy@linux.intel.com>
Cc: mmaddireddy@nvidia.com, kthota@nvidia.com,
linux-pci@vger.kernel.org, Vidya Sagar <vidyas@nvidia.com>,
linux-kernel@vger.kernel.org, jonathanh@nvidia.com,
vsethi@nvidia.com, oohall@gmail.com, bhelgaas@google.com,
treding@nvidia.com, linuxppc-dev@lists.ozlabs.org,
sagar.tv@gmail.com
Subject: Re: [PATCH V1] PCI/AER: Configure ECRC only AER is native
Date: Thu, 12 Jan 2023 12:23:48 -0600 [thread overview]
Message-ID: <20230112182348.GA1777363@bhelgaas> (raw)
In-Reply-To: <880c4d3c-86d2-082c-bb58-8212adc67ff3@linux.intel.com>
On Wed, Jan 11, 2023 at 03:27:51PM -0800, Sathyanarayanan Kuppuswamy wrote:
> On 1/11/23 3:10 PM, Bjorn Helgaas wrote:
> > On Wed, Jan 11, 2023 at 01:42:21PM -0800, Sathyanarayanan Kuppuswamy wrote:
> >> On 1/11/23 12:31 PM, Vidya Sagar wrote:
> >>> As the ECRC configuration bits are part of AER registers, configure
> >>> ECRC only if AER is natively owned by the kernel.
> >>
> >> ecrc command line option takes "bios/on/off" as possible options. It
> >> does not clarify whether "on/off" choices can only be used if AER is
> >> owned by OS or it can override the ownership of ECRC configuration
> >> similar to pcie_ports=native option. Maybe that needs to be clarified.
> >
> > Good point, what do you think of an update like this:
> >
> > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> > index 6cfa6e3996cf..f7b40a439194 100644
> > --- a/Documentation/admin-guide/kernel-parameters.txt
> > +++ b/Documentation/admin-guide/kernel-parameters.txt
> > @@ -4296,7 +4296,9 @@
> > specified, e.g., 12@pci:8086:9c22:103c:198f
> > for 4096-byte alignment.
> > ecrc= Enable/disable PCIe ECRC (transaction layer
> > - end-to-end CRC checking).
> > + end-to-end CRC checking). Only effective
> > + if OS has native AER control (either granted by
> > + ACPI _OSC or forced via "pcie_ports=native").
> > bios: Use BIOS/firmware settings. This is the
> > the default.
> > off: Turn ECRC off
>
> Looks fine. But do we even need "bios" option? Since it is the default
> value, I am not sure why we need to list that as an option again. IMO
> this could be removed.
I agree, it seems pointless.
> > I don't know whether the "ecrc=" parameter is really needed. If we
> > were adding it today, I would ask "why not enable ECRC wherever it is
> > supported?" If there are devices where it's broken, we could always
> > add quirks to disable it on a case-by-case basis.
>
> Checking the original patch which added it, it looks like the intention
> is to give option to boost performance over integrity.
>
> commit 43c16408842b0eeb367c23a6fa540ce69f99e347
> Author: Andrew Patterson <andrew.patterson@hp.com>
> Date: Wed Apr 22 16:52:09 2009 -0600
>
> PCI: Add support for turning PCIe ECRC on or off
>
> Adds support for PCI Express transaction layer end-to-end CRC checking
> (ECRC). This patch will enable/disable ECRC checking by setting/clearing
> the ECRC Check Enable and/or ECRC Generation Enable bits for devices that
> support ECRC.
>
> The ECRC setting is controlled by the "pci=ecrc=<policy>" command-line
> option. If this option is not set or is set to 'bios", the enable and
> generation bits are left in whatever state that firmware/BIOS set them to.
> The "off" setting turns them off, and the "on" option turns them on (if the
> device supports it).
>
> Turning ECRC on or off can be a data integrity versus performance
> tradeoff. In theory, turning it on will catch more data errors, turning
> it off means possibly better performance since CRC does not need to be
> calculated by the PCIe hardware and packet sizes are reduced.
Ah, right, and I think I was even part of the conversation when this
was added :)
I'm not sure I would make the same choice today, though. IMHO it's
kind of hard to defend choosing performance over data integrity.
If a platform really wants to sacrifice integrity for performance, it
could retain control of AER, and after Vidya's patch, Linux will leave
the ECRC configuration alone.
Straw-man: If Linux owns AER and ECRC is supported, enable ECRC by
default. Retain "ecrc=off" to turn it off, but drop a note in dmesg
and taint the kernel.
Bjorn
next prev parent reply other threads:[~2023-01-12 18:54 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-11 20:31 [PATCH V1] PCI/AER: Configure ECRC only AER is native Vidya Sagar
2023-01-11 21:42 ` Sathyanarayanan Kuppuswamy
2023-01-11 23:10 ` Bjorn Helgaas
2023-01-11 23:27 ` Sathyanarayanan Kuppuswamy
2023-01-12 3:33 ` Vidya Sagar
2023-01-12 3:48 ` Sathyanarayanan Kuppuswamy
2023-01-12 4:59 ` Vidya Sagar
2023-01-12 5:06 ` Sathyanarayanan Kuppuswamy
2023-01-12 7:12 ` Vidya Sagar
2023-01-12 18:23 ` Bjorn Helgaas [this message]
2023-01-12 7:21 ` [PATCH V2] " Vidya Sagar
2023-01-12 18:25 ` 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=20230112182348.GA1777363@bhelgaas \
--to=helgaas@kernel.org \
--cc=bhelgaas@google.com \
--cc=jonathanh@nvidia.com \
--cc=kthota@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mmaddireddy@nvidia.com \
--cc=oohall@gmail.com \
--cc=sagar.tv@gmail.com \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=treding@nvidia.com \
--cc=vidyas@nvidia.com \
--cc=vsethi@nvidia.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).