Bug#1015871: Please enable CONFIG_PCI_P2PDMA
Hi, On 10/25/23 03:29, Emanuele Rocca wrote: I hesitate to actually enable it because I don't understand PCI good enough to judge it's a safe choice for the Debian kernel. There is a kernel API for "return the physical address of a BAR mapping on another PCI device, as seen from the point of view of this device." With the P2PDMA option disabled, that API always returns "no peer-to-peer capable path exists", which requires drivers to fall back to allocating a buffer. If the option is enabled, a driver exporting a DMA buffer (such as a video capture device or a GPU) can provide an address that is part of one of its BAR mappings. The driver importing the DMA buffer will then use the physical address it was given in DMA requests, which routes the requests directly and avoids passing through the root complex. I have successfully used this to make an nVidia GPU generate PCIe requests for textures that were answered by an FPGA card. :> The driver importing the buffer needs no special support. There is no generic mechanism to use peer-to-peer transfers if not at least one side is aware of that mechanism, as it essentially requires the exporting device to implement full support for prefetchable BAR mappings. Im principle, all platforms that support PCIe can benefit from this, as it allows peer-to-peer transfers even when the root complex does not support this, as long as all bridges on the path between the involved devices do. In practice, most transfers will happen between a GPU (in a slot directly connected to a root bridge) and some data capture device, so the benefit on platforms other than amd64 and ppc64le will be limited -- although these will just fall back to the current behaviour, and the only code paths affected are slow paths that usually end in TLB flushes for CPU and IO MMUs. Simon
Bug#1015871: Please enable CONFIG_PCI_P2PDMA
Hi Uwe, On 2023-10-24 06:48, Uwe Kleine-König wrote: > I hesitate to actually enable it because I don't understand PCI good > enough to judge it's a safe choice for the Debian kernel. I am also not familiar with the details, but I see that PCI_P2PDMA is 'y' on both Fedora Server 38 and openSUSE Tumbleweed so probably it's not particularly unsafe. If we decide to switch it on, let's do it for arm64 too. Emanuele
Bug#1015871: Please enable CONFIG_PCI_P2PDMA
Hello, On Fri, Jul 22, 2022 at 10:06:54PM +0200, Simon Richter wrote: > would it be possible to enable this option to allow PCIe devices to do > direct data transfers? Enabling it for amd64 and ppc64el would be done by the following change: diff --git a/debian/config/amd64/config b/debian/config/amd64/config index 42ac252164f1..c4b37af83061 100644 --- a/debian/config/amd64/config +++ b/debian/config/amd64/config @@ -194,6 +194,7 @@ CONFIG_NVDIMM_PFN=y ## ## file: drivers/pci/Kconfig ## +CONFIG_PCI_P2PDMA=y CONFIG_PCI_HYPERV=y ## diff --git a/debian/config/kernelarch-powerpc/config-arch-64-le b/debian/config/kernelarch-powerpc/config-arch-64-le index 14a2e754d39e..d0503b3e17f6 100644 --- a/debian/config/kernelarch-powerpc/config-arch-64-le +++ b/debian/config/kernelarch-powerpc/config-arch-64-le @@ -28,6 +28,11 @@ CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y ## CONFIG_CXL_BUS=y +## +## file: drivers/pci/Kconfig +## +CONFIG_PCI_P2PDMA=y + ## ## file: drivers/pcmcia/Kconfig ## @@ -38,3 +43,8 @@ CONFIG_CXL_BUS=y ## #. See #789070 # CONFIG_HIBERNATION is not set + +## +## file: mm/Kconfig +## +CONFIG_ZONE_DEVICE=y ZONE_DEVICE is a direct dependency of PCI_P2PDMA that isn't currently enabled on ppc64el. I hesitate to actually enable it because I don't understand PCI good enough to judge it's a safe choice for the Debian kernel. Also I wonder about "If unsure, say N" in the Kconfig help text. Is this only because people who benefit from this setting are expected to be sure? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
