linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mario Limonciello <mario.limonciello@amd.com>
To: "Karol Herbst" <kherbst@redhat.com>,
	"Lyude Paul" <lyude@redhat.com>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Christian König" <christian.koenig@amd.com>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Mika Westerberg" <mika.westerberg@linux.intel.com>,
	"Lukas Wunner" <lukas@wunner.de>
Cc: "Danilo Krummrich" <dakr@redhat.com>,
	"David Airlie" <airlied@gmail.com>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Xinhui Pan" <Xinhui.Pan@amd.com>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
	"Pali Rohár" <pali@kernel.org>, "Marek Behún" <kabel@kernel.org>,
	"Maciej W . Rozycki" <macro@orcam.me.uk>,
	"Manivannan Sadhasivam" <mani@kernel.org>,
	"Mario Limonciello" <mario.limonciello@amd.com>,
	"open list:DRM DRIVER FOR NVIDIA GEFORCE/QUADRO GPUS"
	<dri-devel@lists.freedesktop.org>,
	"open list:DRM DRIVER FOR NVIDIA GEFORCE/QUADRO GPUS"
	<nouveau@lists.freedesktop.org>,
	"open list" <linux-kernel@vger.kernel.org>,
	"open list:RADEON and AMDGPU DRM DRIVERS"
	<amd-gfx@lists.freedesktop.org>,
	"open list:PCI SUBSYSTEM" <linux-pci@vger.kernel.org>,
	"open list:ACPI" <linux-acpi@vger.kernel.org>
Subject: [PATCH v3 7/7] PCI: Exclude PCIe ports used for virtual links in pcie_bandwidth_available()
Date: Tue, 14 Nov 2023 14:07:55 -0600	[thread overview]
Message-ID: <20231114200755.14911-8-mario.limonciello@amd.com> (raw)
In-Reply-To: <20231114200755.14911-1-mario.limonciello@amd.com>

The USB4 spec specifies that PCIe ports that are used for tunneling
PCIe traffic over USB4 fabric will be hardcoded to advertise 2.5GT/s and
behave as a PCIe Gen1 device. The actual performance of these ports is
controlled by the fabric implementation.

Callers for pcie_bandwidth_available() will always find the PCIe ports
used for tunneling as a limiting factor potentially leading to incorrect
performance decisions.

To prevent such problems check explicitly for ports that are marked as
virtual links or as thunderbolt controllers and skip them when looking
for bandwidth limitations of the hierarchy. If the only device connected
is a port used for tunneling then report that device.

Callers to pcie_bandwidth_available() could make this change on their
own as well but then they wouldn't be able to detect other potential
speed bottlenecks from the hierarchy without duplicating
pcie_bandwidth_available() logic.

Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2925#note_2145860
Link: https://www.usb.org/document-library/usb4r-specification-v20
      USB4 V2 with Errata and ECN through June 2023
      Section 11.2.1
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
---
v2->v3:
 * Split from previous patch version
 * Look for thunderbolt or virtual link
---
 drivers/pci/pci.c | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 0ff7883cc774..b1fb2258b211 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -6269,11 +6269,20 @@ static u32 pcie_calc_bw_limits(struct pci_dev *dev, u32 bw,
  * limiting_dev, speed, and width pointers are supplied) information about
  * that point.  The bandwidth returned is in Mb/s, i.e., megabits/second of
  * raw bandwidth.
+ *
+ * This excludes the bandwidth calculation that has been returned from a
+ * PCIe device that is used for transmitting tunneled PCIe traffic over a virtual
+ * link part of larger hierarchy. Examples include Thunderbolt3 and USB4 links.
+ * The calculation is excluded because the USB4 specification specifies that the
+ * max speed returned from PCIe configuration registers for the tunneling link is
+ * always PCI 1x 2.5 GT/s.  When only tunneled devices are present, the bandwidth
+ * returned is the bandwidth available from the first tunneled device.
  */
 u32 pcie_bandwidth_available(struct pci_dev *dev, struct pci_dev **limiting_dev,
 			     enum pci_bus_speed *speed,
 			     enum pcie_link_width *width)
 {
+	struct pci_dev *vdev = NULL;
 	u32 bw = 0;
 
 	if (speed)
@@ -6282,10 +6291,20 @@ u32 pcie_bandwidth_available(struct pci_dev *dev, struct pci_dev **limiting_dev,
 		*width = PCIE_LNK_WIDTH_UNKNOWN;
 
 	while (dev) {
+		if (dev->is_virtual_link || dev->is_thunderbolt) {
+			if (!vdev)
+				vdev = dev;
+			goto skip;
+		}
 		bw = pcie_calc_bw_limits(dev, bw, limiting_dev, speed, width);
+skip:
 		dev = pci_upstream_bridge(dev);
 	}
 
+	/* If nothing "faster" found on hierarchy, limit to first virtual link */
+	if (vdev && !bw)
+		bw = pcie_calc_bw_limits(vdev, bw, limiting_dev, speed, width);
+
 	return bw;
 }
 EXPORT_SYMBOL(pcie_bandwidth_available);
-- 
2.34.1


  parent reply	other threads:[~2023-11-14 20:08 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-14 20:07 [PATCH v3 0/7] Improvements to pcie_bandwidth_available() for eGPUs Mario Limonciello
2023-11-14 20:07 ` [PATCH v3 1/7] drm/nouveau: Switch from pci_is_thunderbolt_attached() to dev_is_removable() Mario Limonciello
2023-11-16 12:50   ` Ilpo Järvinen
2023-11-14 20:07 ` [PATCH v3 2/7] drm/radeon: " Mario Limonciello
2023-11-15  9:27   ` Christian König
2023-11-14 20:07 ` [PATCH v3 3/7] PCI: Drop pci_is_thunderbolt_attached() Mario Limonciello
2023-11-16 12:51   ` Ilpo Järvinen
2023-11-14 20:07 ` [PATCH v3 4/7] PCI: pciehp: Move check for is_thunderbolt into a quirk Mario Limonciello
2023-11-16 12:30   ` Ilpo Järvinen
2023-11-14 20:07 ` [PATCH v3 5/7] PCI: ACPI: Detect PCIe root ports that are used for tunneling Mario Limonciello
2023-11-15 10:40   ` Mika Westerberg
2023-11-15 17:08     ` Mario Limonciello
2023-11-16  9:00       ` Mika Westerberg
2023-11-14 20:07 ` [PATCH v3 6/7] PCI: Split up some logic in pcie_bandwidth_available() to separate function Mario Limonciello
2023-11-16 13:02   ` Ilpo Järvinen
2023-11-14 20:07 ` Mario Limonciello [this message]
2023-11-15  3:23   ` [PATCH v3 7/7] PCI: Exclude PCIe ports used for virtual links in pcie_bandwidth_available() Lazar, Lijo
2023-11-15 17:04     ` Mario Limonciello
2023-11-15 21:09       ` Mario Limonciello
2023-11-16  4:33         ` Lazar, Lijo

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=20231114200755.14911-8-mario.limonciello@amd.com \
    --to=mario.limonciello@amd.com \
    --cc=Xinhui.Pan@amd.com \
    --cc=airlied@gmail.com \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=bhelgaas@google.com \
    --cc=christian.koenig@amd.com \
    --cc=dakr@redhat.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=kabel@kernel.org \
    --cc=kherbst@redhat.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=lyude@redhat.com \
    --cc=macro@orcam.me.uk \
    --cc=mani@kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=nouveau@lists.freedesktop.org \
    --cc=pali@kernel.org \
    --cc=rafael@kernel.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).