[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1238788057.19984.126.camel@grinch>
Date: Fri, 03 Apr 2009 19:47:37 +0000
From: Andrew Patterson <andrew.patterson@...com>
To: Andi Kleen <andi@...stfloor.org>
Cc: linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
jbarnes@...tuousgeek.org
Subject: Re: [PATCH] Add support for turning PCIe ECRC on or off
On Fri, 2009-04-03 at 08:54 +0200, Andi Kleen wrote:
> Andrew Patterson <andrew.patterson@...com> writes:
>
> > 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 "pcie_ecrc=" command-line option. If
> > this option is not set or is set to 'default", the enable and generation
> > bits are left in whatever state that firmware/BIOS sets them to. The
> > "off" setting turns them off, and the "on" option turns them on (if the
> > device supports it).
>
> Can you please expand a little bit on your motvation? Why does the kernel
> need to set that over the firmware?
My main motivation is to turn this on for systems that support ECRC but
don't currently have it turned on. I think that turning this on or off
provides a possible tradeoff of increased data integrity over some sort
of performance penalty (hardware no longer has to calculate ECRC data,
and packet length is smaller due to lack of ECRC fields).
> And why does it need to be a boot
> parameter vs some sysfs file?
It could be either. I thought about doing both actually, but decided it
probably wasn't worth it. One possible advantage of doing sysfs is that
you could turn it on or off selectively for each root bridge. The
advantage of doing it at boot is that we could turn it off/on very early
for balky hardware.
>
> -Andi
>
--
Andrew Patterson
Hewlett-Packard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists