从 PCIe P2P 到 Linux NTB:高速互联驱动学习笔记 一

在学习 PCIe 高速互联时，很容易遇到几个看起来相近、但实际模型完全不同的概念：PCIe Switch、P2P、NTB、Fabric。它们都和“设备之间通信”有关，但解决的问题并不一样。

如果一开始没有分清楚这些概念，后面看 Linux 驱动时就很容易绕进去。比如看到 PCIe Switch，就以为一定要看 NTB；看到设备之间能互相访问，就以为一定是 NTB；看到芯片手册里写了 NTB capability，又以为 Linux 当前系统里一定能直接使用 NTB 子系统。

这些理解都不够准确。

这篇文章先不深入代码，而是把几个基础问题讲清楚：为什么要看 NTB？NTB 和 PCIe Switch 是什么关系？P2P 又是不是 NTB？

普通 PCIe 拓扑是一个树形结构：

Host 是整个 PCIe hierarchy 的管理者。系统启动后，BIOS 和操作系统会枚举 PCIe 设备，给每个设备分配 bus number、BAR 地址、中断资源等。

PCIe Switch 本身主要负责转发 TLP。比如 CPU 要访问某个 EP 的 BAR，或者某个 EP 发起 DMA 请求，Switch 会根据 PCIe 地址、BDF、Requester ID、Completion 信息等，把请求转发到正确端口。

在这个模式下，Switch 是“透明”的。Host 能看到 Switch 后面的设备，操作系统也会把整棵 PCIe 树统一管理起来。

所以普通透明 PCIe Switch 更像是一个 PCIe 拓扑扩展器。它让一个 Root Complex 后面可以挂更多设备，也让设备之间可能存在更短的转发路径。

P2P，全称 Peer-to-Peer，指的是一个 PCIe 设备直接访问另一个 PCIe 设备，而不是先把数据搬到 Host 内存再转发。

例如：

EP0 DMA write -> EP1 BAR

源设备 EP0 的 DMA engine 发出 Memory Write TLP，目标地址是 EP1 的某个 BAR 地址：

dst = EP1_BAR + offset

Switch 看到这个地址属于 EP1，就把 TLP 转发到 EP1。EP1 收到访问后，可能通过 BAR 或 inbound iATU，把这次访问落到自己的本地寄存器、SRAM 或 DDR。

可以画成：

所以在 P2P 模式下，通信主体不是 Switch，而是两个 EP 设备。Switch 只是按硬件路由转发。

P2P 能否成功，取决于很多条件：

如果两个 EP 在同一个 Switch 下，P2P 通常更容易成立。如果跨多个 Switch、跨 Root Port，甚至跨 CPU socket，情况就复杂得多。

NTB，全称 Non-Transparent Bridge，非透明桥。它解决的不是普通 EP 和 EP 之间的互访问题，而是多个 Host 或多个 Root Complex 之间的通信问题。

普通 PCIe 模型里，一个 hierarchy 通常只有一个 Root Complex。如果两个 Host 直接透明连接，会出现问题：两个 Host 都想枚举总线，都想分配 BAR 地址和 bus number，资源管理会冲突。

NTB 的作用就是在两个 Host 之间建立一个“隔离但可通信”的边界：

Host A / RC A / OS A             |           NTB             |Host B / RC B / OS B

两边不会互相完整枚举对方的 PCIe 拓扑。Host A 看不到 Host B 后面的完整设备树，Host B 也不会直接管理 Host A 的资源。

但 NTB 提供了一组受控通信机制：

典型数据路径是：

Host A memory         |    NTB MW         | Host B memory

也就是说，NTB 更像是 Host-to-Host 的通信桥，而不是普通 EP-to-EP 的透明转发。

很多高端 PCIe Switch 芯片内部会集成 NTB 能力。也就是说，NTB 不一定是单独一颗芯片，它可能是 Switch 里的某些端口或功能模块。

可以理解成：

但这里要特别注意：

芯片支持 NTB，不等于 Linux 当前就能使用 NTB。

Linux 能不能用 NTB，要看系统枚举时是否真的暴露了 NTB PCI function，并且是否有对应的 NTB 硬件驱动绑定它。

如果没有启用 NTB，系统可能只看到：

如果 NTB function 被配置并暴露出来，Linux 才可能看到类似 Non-Transparent Bridge 或 NT function 的设备。之后硬件驱动绑定它，调用 ntb_register_device()，上层 ntb_pingpong、ntb_transport 等 client 才能使用。

顺序通常是：

P2P 和 NTB 最容易混。

P2P 更像：

典型路径：

EP0 -> Switch -> EP1

NTB 更像：

典型路径：

Host A memory -> NTB MW -> Host B memory

二者的差异可以这样理解：

P2P 面向 EP-to-EP，目标地址常是 peer BAR，依赖 PCIe 透明转发或 Fabric route，不一定需要 Linux NTB 子系统。

NTB 面向 Host-to-Host 或 RC-to-RC，目标通常是 peer host memory，依赖 NTB function 和 NTB driver，需要 NTB core/client 参与。

因此，如果目标是让两个普通 PCIe EP 互相访问板上内存，通常要看的是 P2P、BAR、DMA engine、iATU、Switch route、ACS/IOMMU 等。如果目标是两个独立 Host 之间通信，才更应该看 NTB。

即使最终项目不一定直接使用 Linux NTB 子系统，学习 NTB 仍然很有价值。

第一，NTB 把 PCIe 中很多关键概念集中到了一起：BAR、Memory Window、doorbell、中断、地址转换、peer 关系、link 状态、DMA buffer。这些概念对理解 PCIe Fabric 和设备间通信非常有帮助。

第二，Linux NTB 驱动分层非常清晰：

这种结构很适合学习 Linux 内核如何把硬件细节抽象成通用 API。

第三，ntb_pingpong、ntb_transport 这些 client 是很好的学习材料。前者展示了 doorbell/message 的最小通信闭环，后者展示了如何在 Memory Window 之上封装 queue pair。

最后，NTB 和 P2P 的边界搞清楚之后，面对实际平台时就不会盲目套驱动。看到 PCIe Switch，不会立刻以为一定要用 NTB；看到设备间通信，也不会默认是 P2P。应该先判断当前系统暴露出来的硬件模型是什么，再决定软件路径。

写至此处，也该画上句号了。常言道，程序员的世界由0和1构成，但我逐渐意识到——更多的时候，我们面对的是“咦？这怎么又出错了？”

感谢您的阅读，希望我的些许探索，能够助您避开一些陷阱，更接近事实的真相。

敬请关注「码上求真」，期待下次与您相逢。