[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231116090042.GF17433@black.fi.intel.com>
Date: Thu, 16 Nov 2023 11:00:42 +0200
From: Mika Westerberg <mika.westerberg@...ux.intel.com>
To: Mario Limonciello <mario.limonciello@....com>
Cc: Karol Herbst <kherbst@...hat.com>, Lyude Paul <lyude@...hat.com>,
Alex Deucher <alexander.deucher@....com>,
Christian König <christian.koenig@....com>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Lukas Wunner <lukas@...ner.de>,
Danilo Krummrich <dakr@...hat.com>,
David Airlie <airlied@...il.com>,
Daniel Vetter <daniel@...ll.ch>,
Xinhui Pan <Xinhui.Pan@....com>,
"Rafael J . Wysocki" <rafael@...nel.org>,
Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
Pali Rohár <pali@...nel.org>,
Marek Behún <kabel@...nel.org>,
"Maciej W . Rozycki" <macro@...am.me.uk>,
Manivannan Sadhasivam <mani@...nel.org>,
"open list:DRM DRIVER FOR NVIDIA GEFORCE/QUADRO GPUS"
<dri-devel@...ts.freedesktop.org>,
"open list:DRM DRIVER FOR NVIDIA GEFORCE/QUADRO GPUS"
<nouveau@...ts.freedesktop.org>,
open list <linux-kernel@...r.kernel.org>,
"open list:RADEON and AMDGPU DRM DRIVERS"
<amd-gfx@...ts.freedesktop.org>,
"open list:PCI SUBSYSTEM" <linux-pci@...r.kernel.org>,
"open list:ACPI" <linux-acpi@...r.kernel.org>
Subject: Re: [PATCH v3 5/7] PCI: ACPI: Detect PCIe root ports that are used
for tunneling
Hi Mario,
On Wed, Nov 15, 2023 at 11:08:43AM -0600, Mario Limonciello wrote:
> On 11/15/2023 04:40, Mika Westerberg wrote:
> > Hi Mario,
> >
> > On Tue, Nov 14, 2023 at 02:07:53PM -0600, Mario Limonciello wrote:
> > > USB4 routers support a feature called "PCIe tunneling". This
> > > allows PCIe traffic to be transmitted over USB4 fabric.
> > >
> > > PCIe root ports that are used in this fashion can be discovered
> > > by device specific data that specifies the USB4 router they are
> > > connected to. For the PCI core, the specific connection information
> > > doesn't matter, but it's interesting to know that this root port is
> > > used for tunneling traffic. This will allow other decisions to be
> > > made based upon it.
> > >
> > > Detect the `usb4-host-interface` _DSD and if it's found save it
> > > into a new `is_virtual_link` bit in `struct pci_device`.
> >
> > While this is fine for the "first" tunneled link, this does not take
> > into account possible other "virtual" links that lead to the endpoint in
> > question. Typically for eGPU it only makes sense to plug it directly to
> > the host but say there is a USB4 hub (with PCIe tunneling capabilities)
> > in the middle. Now the link from the hub to the eGPU that is also
> > "virtual" is not marked as such and the bandwidth calculations may not
> > get what is expected.
>
> Right; you mentioned the DVSEC available for hubs in this case. As I don't
> have one of these to validate it works properly I was thinking that should
> be a follow up.
>
> If you think it should be part of the same series I'll add it, but I'd ask
> if you can please check I did it right on one that reports the DVSEC?
I don't think it should be part of this series. I just checked and DVSEC
is only required for hosts so kind of hardware equivalent for the _DSD
property you are using here. For hubs there is no such luxury
unfortunately.
I think I do have hardware here with the DVSEC in place so if you
decide to add it, I should be able to try it.
Powered by blists - more mailing lists