All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: Mario Limonciello <mario.limonciello@amd.com>
Cc: "Karol Herbst" <kherbst@redhat.com>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	"open list:PCI SUBSYSTEM" <linux-pci@vger.kernel.org>,
	"open list:DRM DRIVER FOR NVIDIA GEFORCE/QUADRO GPUS"
	<dri-devel@lists.freedesktop.org>,
	"David Airlie" <airlied@gmail.com>,
	"Marek Behún" <kabel@kernel.org>,
	"open list:RADEON and AMDGPU DRM DRIVERS"
	<amd-gfx@lists.freedesktop.org>,
	"open list:ACPI" <linux-acpi@vger.kernel.org>,
	"Danilo Krummrich" <dakr@redhat.com>,
	"open list:DRM DRIVER FOR NVIDIA GEFORCE/QUADRO GPUS"
	<nouveau@lists.freedesktop.org>,
	"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
	"Manivannan Sadhasivam" <mani@kernel.org>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Xinhui Pan" <Xinhui.Pan@amd.com>,
	"open list" <linux-kernel@vger.kernel.org>,
	"Lukas Wunner" <lukas@wunner.de>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Pali Rohár" <pali@kernel.org>,
	"Christian König" <christian.koenig@amd.com>,
	"Maciej W . Rozycki" <macro@orcam.me.uk>
Subject: Re: [PATCH v3 5/7] PCI: ACPI: Detect PCIe root ports that are used for tunneling
Date: Thu, 16 Nov 2023 11:00:42 +0200	[thread overview]
Message-ID: <20231116090042.GF17433@black.fi.intel.com> (raw)
In-Reply-To: <70b35a0e-5ccd-4e19-a8ac-4cf095007a69@amd.com>

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.

WARNING: multiple messages have this Message-ID (diff)
From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: Mario Limonciello <mario.limonciello@amd.com>
Cc: "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>,
	"Lukas Wunner" <lukas@wunner.de>,
	"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>,
	"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: Re: [PATCH v3 5/7] PCI: ACPI: Detect PCIe root ports that are used for tunneling
Date: Thu, 16 Nov 2023 11:00:42 +0200	[thread overview]
Message-ID: <20231116090042.GF17433@black.fi.intel.com> (raw)
In-Reply-To: <70b35a0e-5ccd-4e19-a8ac-4cf095007a69@amd.com>

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.

WARNING: multiple messages have this Message-ID (diff)
From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: Mario Limonciello <mario.limonciello@amd.com>
Cc: "Rafael J . Wysocki" <rafael@kernel.org>,
	"open list:PCI SUBSYSTEM" <linux-pci@vger.kernel.org>,
	"open list:DRM DRIVER FOR NVIDIA GEFORCE/QUADRO GPUS"
	<dri-devel@lists.freedesktop.org>,
	"Marek Behún" <kabel@kernel.org>,
	"open list:RADEON and AMDGPU DRM DRIVERS"
	<amd-gfx@lists.freedesktop.org>,
	"open list:ACPI" <linux-acpi@vger.kernel.org>,
	"open list:DRM DRIVER FOR NVIDIA GEFORCE/QUADRO GPUS"
	<nouveau@lists.freedesktop.org>,
	"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
	"Manivannan Sadhasivam" <mani@kernel.org>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Xinhui Pan" <Xinhui.Pan@amd.com>,
	"open list" <linux-kernel@vger.kernel.org>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Pali Rohár" <pali@kernel.org>,
	"Christian König" <christian.koenig@amd.com>,
	"Maciej W . Rozycki" <macro@orcam.me.uk>
Subject: Re: [Nouveau] [PATCH v3 5/7] PCI: ACPI: Detect PCIe root ports that are used for tunneling
Date: Thu, 16 Nov 2023 11:00:42 +0200	[thread overview]
Message-ID: <20231116090042.GF17433@black.fi.intel.com> (raw)
In-Reply-To: <70b35a0e-5ccd-4e19-a8ac-4cf095007a69@amd.com>

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.

WARNING: multiple messages have this Message-ID (diff)
From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: Mario Limonciello <mario.limonciello@amd.com>
Cc: "Karol Herbst" <kherbst@redhat.com>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	"open list:PCI SUBSYSTEM" <linux-pci@vger.kernel.org>,
	"open list:DRM DRIVER FOR NVIDIA GEFORCE/QUADRO GPUS"
	<dri-devel@lists.freedesktop.org>,
	"Marek Behún" <kabel@kernel.org>,
	"open list:RADEON and AMDGPU DRM DRIVERS"
	<amd-gfx@lists.freedesktop.org>,
	"open list:ACPI" <linux-acpi@vger.kernel.org>,
	"Danilo Krummrich" <dakr@redhat.com>,
	"open list:DRM DRIVER FOR NVIDIA GEFORCE/QUADRO GPUS"
	<nouveau@lists.freedesktop.org>,
	"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
	"Manivannan Sadhasivam" <mani@kernel.org>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Xinhui Pan" <Xinhui.Pan@amd.com>,
	"open list" <linux-kernel@vger.kernel.org>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Pali Rohár" <pali@kernel.org>,
	"Christian König" <christian.koenig@amd.com>,
	"Maciej W . Rozycki" <macro@orcam.me.uk>
Subject: Re: [PATCH v3 5/7] PCI: ACPI: Detect PCIe root ports that are used for tunneling
Date: Thu, 16 Nov 2023 11:00:42 +0200	[thread overview]
Message-ID: <20231116090042.GF17433@black.fi.intel.com> (raw)
In-Reply-To: <70b35a0e-5ccd-4e19-a8ac-4cf095007a69@amd.com>

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.

  reply	other threads:[~2023-11-16  9:11 UTC|newest]

Thread overview: 80+ 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 ` Mario Limonciello
2023-11-14 20:07 ` [Nouveau] " Mario Limonciello
2023-11-14 20:07 ` 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-14 20:07   ` Mario Limonciello
2023-11-14 20:07   ` [Nouveau] " Mario Limonciello
2023-11-14 20:07   ` Mario Limonciello
2023-11-16 12:50   ` Ilpo Järvinen
2023-11-16 12:50     ` Ilpo Järvinen
2023-11-16 12:50     ` Ilpo Järvinen
2023-11-16 12:50     ` Ilpo Järvinen
2023-11-14 20:07 ` [PATCH v3 2/7] drm/radeon: " Mario Limonciello
2023-11-14 20:07   ` Mario Limonciello
2023-11-14 20:07   ` [Nouveau] " Mario Limonciello
2023-11-14 20:07   ` Mario Limonciello
2023-11-15  9:27   ` Christian König
2023-11-15  9:27     ` Christian König
2023-11-15  9:27     ` [Nouveau] " Christian König
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-14 20:07   ` Mario Limonciello
2023-11-14 20:07   ` [Nouveau] " Mario Limonciello
2023-11-14 20:07   ` Mario Limonciello
2023-11-16 12:51   ` Ilpo Järvinen
2023-11-16 12:51     ` Ilpo Järvinen
2023-11-16 12:51     ` Ilpo Järvinen
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-14 20:07   ` Mario Limonciello
2023-11-14 20:07   ` [Nouveau] " Mario Limonciello
2023-11-14 20:07   ` Mario Limonciello
2023-11-16 12:30   ` Ilpo Järvinen
2023-11-16 12:30     ` Ilpo Järvinen
2023-11-16 12:30     ` Ilpo Järvinen
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-14 20:07   ` Mario Limonciello
2023-11-14 20:07   ` [Nouveau] " Mario Limonciello
2023-11-14 20:07   ` Mario Limonciello
2023-11-15 10:40   ` Mika Westerberg
2023-11-15 10:40     ` Mika Westerberg
2023-11-15 10:40     ` [Nouveau] " Mika Westerberg
2023-11-15 10:40     ` Mika Westerberg
2023-11-15 17:08     ` Mario Limonciello
2023-11-15 17:08       ` Mario Limonciello
2023-11-15 17:08       ` [Nouveau] " Mario Limonciello
2023-11-15 17:08       ` Mario Limonciello
2023-11-16  9:00       ` Mika Westerberg [this message]
2023-11-16  9:00         ` Mika Westerberg
2023-11-16  9:00         ` [Nouveau] " Mika Westerberg
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-14 20:07   ` Mario Limonciello
2023-11-14 20:07   ` [Nouveau] " Mario Limonciello
2023-11-14 20:07   ` Mario Limonciello
2023-11-16 13:02   ` Ilpo Järvinen
2023-11-16 13:02     ` Ilpo Järvinen
2023-11-16 13:02     ` Ilpo Järvinen
2023-11-16 13:02     ` Ilpo Järvinen
2023-11-14 20:07 ` [PATCH v3 7/7] PCI: Exclude PCIe ports used for virtual links in pcie_bandwidth_available() Mario Limonciello
2023-11-14 20:07   ` Mario Limonciello
2023-11-14 20:07   ` [Nouveau] " Mario Limonciello
2023-11-14 20:07   ` Mario Limonciello
2023-11-15  3:23   ` Lazar, Lijo
2023-11-15  3:23     ` Lazar, Lijo
2023-11-15  3:23     ` Lazar, Lijo
2023-11-15  3:23     ` Lazar, Lijo
2023-11-15 17:04     ` Mario Limonciello
2023-11-15 17:04       ` Mario Limonciello
2023-11-15 17:04       ` [Nouveau] " Mario Limonciello
2023-11-15 17:04       ` Mario Limonciello
2023-11-15 21:09       ` Mario Limonciello
2023-11-15 21:09         ` Mario Limonciello
2023-11-15 21:09         ` [Nouveau] " Mario Limonciello
2023-11-15 21:09         ` Mario Limonciello
2023-11-16  4:33         ` Lazar, Lijo
2023-11-16  4:33           ` Lazar, Lijo
2023-11-16  4:33           ` Lazar, Lijo
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=20231116090042.GF17433@black.fi.intel.com \
    --to=mika.westerberg@linux.intel.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=macro@orcam.me.uk \
    --cc=mani@kernel.org \
    --cc=mario.limonciello@amd.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 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.