From: Lukas Wunner <lukas@wunner.de>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Mario Limonciello <mario.limonciello@amd.com>,
bhelgaas@google.com, mika.westerberg@linux.intel.com,
andreas.noever@gmail.com, michael.jamet@intel.com,
YehezkelShB@gmail.com, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
Alexander.Deucher@amd.com
Subject: Re: [PATCH 2/2] PCI: Ignore PCIe ports used for tunneling in pcie_bandwidth_available()
Date: Thu, 2 Nov 2023 18:28:27 +0100 [thread overview]
Message-ID: <20231102172827.GA8677@wunner.de> (raw)
In-Reply-To: <20231102154748.GA122230@bhelgaas>
On Thu, Nov 02, 2023 at 10:47:48AM -0500, Bjorn Helgaas wrote:
> On Wed, Nov 01, 2023 at 08:14:31PM -0500, Mario Limonciello wrote:
> > On 11/1/2023 17:52, Bjorn Helgaas wrote:
> > > Is the implication that a tunneling port can *never* be a speed
> > > bottleneck? That seems to be how this patch would work in practice.
> >
> > I think that's a stretch we should avoid concluding.
>
> I'm just reading the description and the patch, which seem to say that
> pcie_bandwidth_available() will never report a tunneling port as the
> limiting port.
If the Thunderbolt host controller is a discrete chip attached with PCIe,
the bandwidth is capped by its Switch Upstream Port.
E.g. the "Light Ridge" Thunderbolt 1 controller's Switch Upstream Port
supports 5 GT/s at x4 width.
In contemporary systems, the Thunderbolt controller is often part of the
CPU SoC, so attached Thunderbolt devices appear below a Root Port.
In that case, there's no such limitation.
Additionally the bandwidth is limited by the Thunderbolt generation:
Thunderbolt 1 had two bidirectional 10 GBit/s channels,
Thunderbolt 2 has 20 GBit/s total, Thunderbolt 3 & 4 has 40 GBit/s total:
https://en.wikipedia.org/wiki/Thunderbolt_(interface)
Hence assuming "unlimited" capacity for Thunderbolt wouldn't be accurate.
Thanks,
Lukas
prev parent reply other threads:[~2023-11-02 17:28 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-31 13:34 [PATCH 1/2] PCI: Move the `PCI_CLASS_SERIAL_USB_USB4` definition to common header Mario Limonciello
2023-10-31 13:34 ` [PATCH 2/2] PCI: Ignore PCIe ports used for tunneling in pcie_bandwidth_available() Mario Limonciello
2023-10-31 23:02 ` kernel test robot
2023-11-01 22:52 ` Bjorn Helgaas
2023-11-02 1:14 ` Mario Limonciello
2023-11-02 10:31 ` Mika Westerberg
2023-11-02 12:07 ` Bjorn Helgaas
2023-11-02 12:17 ` Mika Westerberg
2023-11-02 15:21 ` Lukas Wunner
2023-11-02 15:26 ` Mario Limonciello
2023-11-02 15:33 ` Lukas Wunner
2023-11-02 16:22 ` Mario Limonciello
2023-11-03 5:48 ` Mika Westerberg
2023-11-02 15:47 ` Bjorn Helgaas
2023-11-02 17:28 ` Lukas Wunner [this message]
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=20231102172827.GA8677@wunner.de \
--to=lukas@wunner.de \
--cc=Alexander.Deucher@amd.com \
--cc=YehezkelShB@gmail.com \
--cc=andreas.noever@gmail.com \
--cc=bhelgaas@google.com \
--cc=helgaas@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mario.limonciello@amd.com \
--cc=michael.jamet@intel.com \
--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 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.