From: Logan Gunthorpe <logang@deltatee.com>
To: Leon Romanovsky <leon@kernel.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Len Brown <lenb@kernel.org>,
Saket Dumbre <saket.dumbre@intel.com>,
Bjorn Helgaas <bhelgaas@google.com>
Cc: linux-acpi@vger.kernel.org, acpica-devel@lists.linux.dev,
linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
Lukas Wunner <lukas@wunner.de>,
"Natu, Mahesh" <mahesh.natu@intel.com>
Subject: Re: [PATCH RFC 4/7] PCI/P2PDMA: Prefer providers with better HMAT performance
Date: Thu, 13 Aug 2026 21:50:07 -0600 [thread overview]
Message-ID: <5e7eb09b-a47b-4cb5-8629-0ca5fa39f1f9@deltatee.com> (raw)
In-Reply-To: <20260812-hmat-p2p-v1-4-75ac41380585@nvidia.com>
On 2026-08-12 1:47 p.m., Leon Romanovsky wrote:
> @@ -820,21 +844,29 @@ static unsigned long map_types_idx(struct pci_dev *client)
> * PCI_P2PDMA_MAP_THRU_HOST_BRIDGE. Otherwise, return
> * PCI_P2PDMA_MAP_BUS_ADDR.
> *
> - * Any two devices that have a data path that goes through the host bridge
> - * will consult a whitelist. If the host bridge is in the whitelist, return
> - * PCI_P2PDMA_MAP_THRU_HOST_BRIDGE with the distance set to the number of
> - * ports per above. If the device is not in the whitelist, return
> - * PCI_P2PDMA_MAP_NOT_SUPPORTED.
> + * Any two devices that have a data path through a host bridge require
> + * platform support from the CPU, the host bridge whitelist, or a reachable
> + * ordered HMAT path. Return PCI_P2PDMA_MAP_NOT_SUPPORTED when none of those
> + * sources permits the path.
> */
> VISIBLE_IF_KUNIT enum pci_p2pdma_map_type
> calc_map_type_and_dist(struct pci_dev *provider, struct pci_dev *client,
> int *dist, bool verbose)
> +{
> + return __calc_map_type_and_dist(provider, client, dist, verbose, NULL);
> +}
This patch is a bit hard to follow compared to the earlier ones in this
series.
Why do we need to have a different variant of the function that excludes
coord and is exported only for KUNIT? Why can't we just export the
original function as is instead of creating the double underscore
variant? Personally, I've been trying to avoid creating double
underscore functions and naming functions more appropriately. But this
one seems weird to me.
Seems like some of these details would be better split into another
patch justifying them as this change seems more like prep changes for
the KUNIT work that follows instead of what the patch is meant to do:
enabling the HMAT stuff.
> @@ -941,12 +976,22 @@ calc_map_type_and_dist(struct pci_dev *provider, struct pci_dev *client,
> }
>
> map_through_host_bridge:
> - if (!cpu_supports_p2pdma() &&
> - !host_bridge_hmat_p2p(provider, client) &&
> - !host_bridge_whitelist(provider, client, verbose)) {
> - if (verbose)
> + host_bridge_allowed = cpu_supports_p2pdma() ||
> + host_bridge_whitelist(provider, client,
> + false);
> + /*
> + * The coordinates are only used to rank providers, which happens in
> + * process context. Skip the firmware lookup on the mapping path once
> + * the CPU or the whitelist has already permitted the path.
> + */
This feels backwards to me. If ACPI is kind enough to include
information on P2PDMA support then I feel like we should use it
exclusively. Not prioritize the old janky whitelists.
--
In general this series looks really nice. And I'm so glad someone is
finally adding this stuff to ACPI so that we can move away from the
annoying white list.
Thanks,
Logan
next prev parent reply other threads:[~2026-08-14 3:51 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-12 19:47 [PATCH RFC 0/7] PCI/HMAT: Describe P2PDMA reachability and performance Leon Romanovsky
2026-08-12 19:47 ` [PATCH RFC 1/7] ACPICA: Define PCIe P2P latency and bandwidth information Leon Romanovsky
2026-08-13 10:13 ` Rafael J. Wysocki (Intel)
2026-08-13 11:01 ` Leon Romanovsky
2026-08-12 19:47 ` [PATCH RFC 2/7] ACPI: HMAT: Make PCIe P2P paths available to consumers Leon Romanovsky
2026-08-12 19:47 ` [PATCH RFC 3/7] PCI/P2PDMA: Authorize HMAT-described cross-host-bridge P2P Leon Romanovsky
2026-08-12 19:47 ` [PATCH RFC 4/7] PCI/P2PDMA: Prefer providers with better HMAT performance Leon Romanovsky
2026-08-14 3:50 ` Logan Gunthorpe [this message]
2026-08-16 12:38 ` Leon Romanovsky
2026-08-17 16:09 ` Logan Gunthorpe
2026-08-17 18:27 ` Leon Romanovsky
2026-08-12 19:47 ` [PATCH RFC 5/7] ACPI: HMAT: Add KUnit tests for PCIe P2P matrix semantics Leon Romanovsky
2026-08-12 19:47 ` [PATCH RFC 6/7] PCI/P2PDMA: Add KUnit tests for HMAT policy boundaries Leon Romanovsky
2026-08-12 19:47 ` [PATCH RFC 7/7] PCI/P2PDMA: Add KUnit tests for HMAT provider ranking Leon Romanovsky
2026-08-24 20:15 ` [PATCH RFC 0/7] PCI/HMAT: Describe P2PDMA reachability and performance Alison Schofield
2026-08-24 20:24 ` Natu, Mahesh
2026-08-26 14:08 ` Leon Romanovsky
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=5e7eb09b-a47b-4cb5-8629-0ca5fa39f1f9@deltatee.com \
--to=logang@deltatee.com \
--cc=acpica-devel@lists.linux.dev \
--cc=bhelgaas@google.com \
--cc=lenb@kernel.org \
--cc=leon@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=mahesh.natu@intel.com \
--cc=rafael@kernel.org \
--cc=saket.dumbre@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