<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Pcie on Damien Dye&#39;s Blog</title>
    <link>https://blogs.damiendye.uk/en/tags/pcie/</link>
    <description>Recent content in Pcie on Damien Dye&#39;s Blog</description>
    <generator>Hugo</generator>
    <language>en-GB</language>
    <lastBuildDate>Thu, 13 Aug 2026 09:00:00 +0100</lastBuildDate>
    <atom:link href="https://blogs.damiendye.uk/en/tags/pcie/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Tri-Mode Adapters Buy Flexibility With Your NVMe Queues</title>
      <link>https://blogs.damiendye.uk/en/hardware/tri-mode-adapters-nvme-as-sas/</link>
      <pubDate>Thu, 13 Aug 2026 09:00:00 +0100</pubDate>
      <guid>https://blogs.damiendye.uk/en/hardware/tri-mode-adapters-nvme-as-sas/</guid>
      <description>A tri-mode adapter lets any bay take SAS, SATA or NVMe, which is why U.3 backplanes exist. What it hides: your NVMe drives arrive in Linux as SCSI disks on mpt3sas, queue depth 128, sharing one tag pool and one x8 uplink. Two Gen4 drives saturate the card, one Gen5 is already past it. Whether the trade still makes sense in 2026.</description>
    </item>
    <item>
      <title>PCIe Resizable BAR and Modern GPUs — Intel Arc, NVIDIA and AMD</title>
      <link>https://blogs.damiendye.uk/en/proxmox/pcie-resizable-bar/</link>
      <pubDate>Fri, 07 Aug 2026 11:00:00 +0100</pubDate>
      <guid>https://blogs.damiendye.uk/en/proxmox/pcie-resizable-bar/</guid>
      <description>Resizable BAR lets the CPU map a GPU&amp;#39;s whole framebuffer instead of peering at it through a 256MB window. Intel calls it required for Arc, NVIDIA enables it per game, AMD sells it as Smart Access Memory — and for AI work it changes the transfer, not the maths.</description>
    </item>
    <item>
      <title>PCIe Passthrough Performance on Proxmox VE — The IOMMU Tax and How to Minimise It</title>
      <link>https://blogs.damiendye.uk/en/proxmox/pcie-passthrough-performance-the-iommu-tax/</link>
      <pubDate>Fri, 07 Aug 2026 10:00:00 +0100</pubDate>
      <guid>https://blogs.damiendye.uk/en/proxmox/pcie-passthrough-performance-the-iommu-tax/</guid>
      <description>Why PCIe devices lose throughput when passed through to a VM via VFIO, and the practical tuning steps that claw most of it back.</description>
    </item>
    <item>
      <title>PCIe ASPM and Why You Should Disable It for Passthrough</title>
      <link>https://blogs.damiendye.uk/en/proxmox/pcie-aspm-passthrough/</link>
      <pubDate>Fri, 07 Aug 2026 09:20:00 +0100</pubDate>
      <guid>https://blogs.damiendye.uk/en/proxmox/pcie-aspm-passthrough/</guid>
      <description>Active State Power Management saves a few watts on idle PCIe links. Under VFIO passthrough, it adds latency jitter that&amp;#39;s hard to diagnose and easy to fix.</description>
    </item>
    <item>
      <title>PCIe MaxPayloadSize — A Free Performance Win for Passthrough</title>
      <link>https://blogs.damiendye.uk/en/proxmox/pcie-maxpayloadsize/</link>
      <pubDate>Fri, 07 Aug 2026 09:00:00 +0100</pubDate>
      <guid>https://blogs.damiendye.uk/en/proxmox/pcie-maxpayloadsize/</guid>
      <description>QEMU&amp;#39;s virtual root complex defaults to 128-byte TLP payloads. Most devices support 256 or 512. One kernel parameter fixes it.</description>
    </item>
    <item>
      <title>Always Use Q35, Not i440fx — Why It Matters on Proxmox VE</title>
      <link>https://blogs.damiendye.uk/en/proxmox/q35-not-i440fx/</link>
      <pubDate>Fri, 07 Aug 2026 08:45:00 +0100</pubDate>
      <guid>https://blogs.damiendye.uk/en/proxmox/q35-not-i440fx/</guid>
      <description>The two QEMU virtual chipsets are not interchangeable. Q35 provides a proper PCIe topology that passthrough, modern Windows, and the wider KVM ecosystem all depend on.</description>
    </item>
  </channel>
</rss>
