From: Mario Limonciello <mario.limonciello@amd.com>
To: Mika Westerberg <mika.westerberg@linux.intel.com>,
Bjorn Helgaas <bhelgaas@google.com>
Cc: "open list:PCI SUBSYSTEM" <linux-pci@vger.kernel.org>,
Alex Deucher <alexander.deucher@amd.com>
Subject: pcie_bandwidth_available and USB4/TBT3
Date: Mon, 30 Oct 2023 11:46:20 -0500 [thread overview]
Message-ID: <7ad4b2ce-4ee4-429d-b5db-3dfc360f4c3e@amd.com> (raw)
Hi,
Recently we’ve been looking at some issues with AMD dGPUs being put into
a TBT3 eGPU enclosure and various issues that come up. Several of them
are root caused to bugs in the amdgpu driver that we’ll fix there.
However one thing stands out is a performance problem where the cards
are artificially limited to a lower speed than necessary.
The amdgpu driver uses pcie_bandwidth_available() to decide what values
to use for the platform speed cap and bandwidth cap.
The value returned for the platform speed cap is always hardcoded to 2.5
GT/s.
This happens because the USB4 spec explicitly states[1]
---
11.2.1 PCIe Physical Layer Logical Sub-block
The Logical sub-block shall update the PCIe configuration registers with
the following
characteristics:
• PCIe Gen 1 protocol behavior.
• Max Link Speed field in the Link Capabilities Register set to 0001b
(data rate of 2.5 GT/s
only).
Note: These settings do not represent actual throughput. Throughput is
implementation specific
and based on the USB4 Fabric performance.
---
So I wanted to ask – is it better to:
1. Catch this case in pcie_bandwidth_available() to skip PCIe root ports
associated with a USB4 controller.
2. Special case the usage of pcie_bandwidth_available() to ignore any
limiting devices when dev_is_removable() for the dGPU.
I'm personally tending to think it's better to fix in
pcie_bandwidth_available() because papering over it in amdgpu means that
the discovering the upper bound isn't possible if you must ignore the
return value for pcie_bandwidth_available().
Thanks,
[1] https://www.usb.org/document-library/usb4r-specification-v20
USB4 V2 with Errata and ECN through June 2023 - CLEAN p710
next reply other threads:[~2023-10-30 16:46 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-30 16:46 Mario Limonciello [this message]
2023-10-31 7:14 ` pcie_bandwidth_available and USB4/TBT3 Mika Westerberg
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=7ad4b2ce-4ee4-429d-b5db-3dfc360f4c3e@amd.com \
--to=mario.limonciello@amd.com \
--cc=alexander.deucher@amd.com \
--cc=bhelgaas@google.com \
--cc=linux-pci@vger.kernel.org \
--cc=mika.westerberg@linux.intel.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