From: Bjorn Helgaas <helgaas@kernel.org>
To: Keith Busch <kbusch@kernel.org>
Cc: Alex G <mr.nuke.me@gmail.com>, Lukas Wunner <lukas@wunner.de>,
Alex Williamson <alex.williamson@redhat.com>,
Austin Bolen <austin_bolen@dell.com>,
Alexandru Gagniuc <alex_gagniuc@dellteam.com>,
Keith Busch <keith.busch@intel.com>,
Shyam Iyer <Shyam_Iyer@dell.com>, Sinan Kaya <okaya@kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Revert "PCI/LINK: Report degraded links via link bandwidth notification"
Date: Tue, 30 Apr 2019 21:12:49 -0500 [thread overview]
Message-ID: <20190501021249.GD145057@google.com> (raw)
In-Reply-To: <20190430181813.GC25654@localhost.localdomain>
On Tue, Apr 30, 2019 at 12:18:13PM -0600, Keith Busch wrote:
> On Tue, Apr 30, 2019 at 12:05:09PM -0600, Keith Busch wrote:
> > On Tue, Apr 30, 2019 at 11:11:51AM -0500, Bjorn Helgaas wrote:
> > > > I'm not convinced a revert is the best call.
> > >
> > > I have very limited options at this stage of the release, but I'd be
> > > glad to hear suggestions. My concern is that if we release v5.1
> > > as-is, we'll spend a lot of energy on those false positives.
> >
> > May be too late now if the revert is queued up, but I think this feature
> > should have been a default 'false' Kconfig bool rather than always on.
Since this feature currently just adds a message in dmesg, which we
don't really consider a stable API, I think a Kconfig switch is a
reasonable option.
If you send me a signed-off-by for the following patch, I can apply it:
commit 302b77157e66
Author: Keith Busch <kbusch@kernel.org>
Date: Tue Apr 30 12:18:13 2019 -0600
PCI/LINK: Add Kconfig option (default off)
e8303bb7a75c ("PCI/LINK: Report degraded links via link bandwidth
notification") added dmesg logging whenever a link changes speed or width
to a state that is considered degraded. Unfortunately, it cannot
differentiate signal integrity-related link changes from those
intentionally initiated by an endpoint driver, including drivers that may
live in userspace or VMs when making use of vfio-pci. Some GPU drivers
actively manage the link state to save power, which generates a stream of
messages like this:
vfio-pci 0000:07:00.0: 32.000 Gb/s available PCIe bandwidth, limited by 2.5 GT/s x16 link at 0000:00:02.0 (capable of 64.000 Gb/s with 5 GT/s x16 link)
Since we can't distinguish the intentional changes from the signal
integrity issues, leave the reporting turned off by default. Add a Kconfig
option to turn it on if desired.
Fixes: e8303bb7a75c ("PCI/LINK: Report degraded links via link bandwidth
notification")
diff --git a/drivers/pci/pcie/Kconfig b/drivers/pci/pcie/Kconfig
index 5cbdbca904ac..4a094f0d2856 100644
--- a/drivers/pci/pcie/Kconfig
+++ b/drivers/pci/pcie/Kconfig
@@ -142,3 +142,12 @@ config PCIE_PTM
This is only useful if you have devices that support PTM, but it
is safe to enable even if you don't.
+
+config PCIE_BW
+ bool "PCI Express Bandwidth Change Notification"
+ default n
+ depends on PCIEPORTBUS
+ help
+ This enables PCI Express Bandwidth Change Notification. If
+ you know link width or rate changes occur only to correct
+ unreliable links, you may answer Y.
diff --git a/drivers/pci/pcie/Makefile b/drivers/pci/pcie/Makefile
index f1d7bc1e5efa..d356a5bdb158 100644
--- a/drivers/pci/pcie/Makefile
+++ b/drivers/pci/pcie/Makefile
@@ -3,7 +3,6 @@
# Makefile for PCI Express features and port driver
pcieportdrv-y := portdrv_core.o portdrv_pci.o err.o
-pcieportdrv-y += bw_notification.o
obj-$(CONFIG_PCIEPORTBUS) += pcieportdrv.o
@@ -13,3 +12,4 @@ obj-$(CONFIG_PCIEAER_INJECT) += aer_inject.o
obj-$(CONFIG_PCIE_PME) += pme.o
obj-$(CONFIG_PCIE_DPC) += dpc.o
obj-$(CONFIG_PCIE_PTM) += ptm.o
+obj-$(CONFIG_PCIE_BW) := bw_notification.o
next prev parent reply other threads:[~2019-05-01 2:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-29 18:56 [PATCH] Revert "PCI/LINK: Report degraded links via link bandwidth Bjorn Helgaas
2019-04-29 18:56 ` [PATCH] Revert "PCI/LINK: Report degraded links via link bandwidth notification" Bjorn Helgaas
2019-04-29 19:21 ` Alex Williamson
2019-04-30 1:07 ` Alex G
2019-04-30 16:11 ` Bjorn Helgaas
2019-04-30 18:05 ` Keith Busch
2019-04-30 18:18 ` Keith Busch
2019-05-01 2:12 ` Bjorn Helgaas [this message]
2019-05-01 13:16 ` Keith Busch
2019-04-30 23:09 ` Lukas Wunner
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=20190501021249.GD145057@google.com \
--to=helgaas@kernel.org \
--cc=Shyam_Iyer@dell.com \
--cc=alex.williamson@redhat.com \
--cc=alex_gagniuc@dellteam.com \
--cc=austin_bolen@dell.com \
--cc=kbusch@kernel.org \
--cc=keith.busch@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=mr.nuke.me@gmail.com \
--cc=okaya@kernel.org \
--cc=torvalds@linux-foundation.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 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.