[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231102172827.GA8677@wunner.de>
Date: Thu, 2 Nov 2023 18:28:27 +0100
From: Lukas Wunner <lukas@...ner.de>
To: Bjorn Helgaas <helgaas@...nel.org>
Cc: Mario Limonciello <mario.limonciello@....com>, bhelgaas@...gle.com,
mika.westerberg@...ux.intel.com, andreas.noever@...il.com,
michael.jamet@...el.com, YehezkelShB@...il.com,
linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-usb@...r.kernel.org, Alexander.Deucher@....com
Subject: Re: [PATCH 2/2] PCI: Ignore PCIe ports used for tunneling in
pcie_bandwidth_available()
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
Powered by blists - more mailing lists