PCIe ARI (Alternative Routing-ID Interpretation)介绍

✨1. ARI 背景介绍

---

Alternative Routing-ID Interpretation，顾名思义，可替换的Routing ID，意味着这是一种要把Routing ID的部分或全部替换掉的机制。通常来讲，Requester ID和Comleter ID等Routing ID由Bus Number, Device Number, Function Number (BDF) 3个字段组成，其中Bus Number 8-bit，Device Number 5-bit，Function Number 3-bit，一共16-bit。

即最多支持256个Bus、32个Device及8个Function。由于PCIe采用端到端的传输方式，每一个链路仅挂载一个设备，Device数量为1，Device Number恒为0，采用5-bit宽的Device Number没有意义；此外3-bit Function Number最高支持8个Function，对有多个VM的SR-IOV系统而言，8个Function稍显不足。

 基于以上原因，从PCIe Gen3开始提供一种ARI机制，取消了Device Number字段，合并到Function Number字段中，这样Routing ID便变成了8-bit Bus Number + 8-bit Function Number的格式，最多支持的Bus数量不变，支持的Function数量增大到256个。

✨2. ARI 扩展能力结构

---

 具备ARI能力的PCIe设备需实现ARI扩展能力结构。ARI扩展能力结构如下图图1所示，有ARI扩展能力头标、ARI控制寄存器、ARI能力寄存器三部分。以下ARI扩展能力结构仅适用于Device，不适用于RP、Switch下行端口、RCiEP、RC事件收集器等。

图1 ARI Extended Capability

•        ARI Extended Capability Header: ARI扩展能力头标（图2），用以指示该设备具备ARI能力、ARI能力版本及下一能力的偏移。
• ARI Capability Register：ARI能力寄存器（图3），MFVC Function Groups Capability用以指示具备MFVC能力的ARI设备是否支持Function Group粒度的仲裁，ACS Function Groups Capability用以指示具备ACS P2P出口控制的ARI设备是否支持Function Group粒度的访问，这两个字段仅用于Function0，其余Function该字段需置零。Next Function Number字段用以指示该Device中的下一Function Number，若没有则置零。
•        ARI Control Register：ARI控制寄存器（图4），用以开启MFVC Function Group Capability及ACS Function Group Capability，Function Group字段用以指示当前Function所属的Function Group Number。

• 

  图2 ARI Extended Capability Header

  

  图3 ARI Capability Register

  

  图4 ARI Control Register

  ✨3. ARI 能力使用准备工作

  ---

  在正式使用ARI能力之前有两个重要工作要做，即 ① 检测组件是否具备ARI能力，② 配置各组件的ARI能力，详细介绍如下。

     软件枚举PCIe拓扑并判断组件是否支持ARI扩展能力。对于常规ARI设备，可检测设备是否实现了ARI扩展能力结构来判断其是否具备ARI扩展能力；对于具备ARI能力的Switch下行端口，则要检测设备能力2寄存器来判断其是否支持ARI。

     软件使能各组件的ARI功能，应注意以下细节：

     1️⃣ 在紧接的下游组件为ARI设备的ARI Switch下行端口中，软件配置其设备控制2寄存器ARI Forwarding Enable位（图5）来打开该端口的ARI转发功能，这样当Switch下行端口在把Type1类型的配置请求转换为Type0类型时，就会关掉Switch原有的Device Number字段，确保配置请求能够访问到该下行端口下游紧邻的ARI设备中的扩展Function（扩展Function是指ARI设备中Function ID大于7的Function）。如果没有开启Switch下行端口的ARI转发功能，那么软件在枚举的时候将无法发现并配置该端口下游ARI设备中的扩展Function。

     2️⃣ ARI设备中，扩展Function必须响应Type0类型的配置请求。

     3️⃣ 若ARI设备实现了带有Function仲裁的多Function VC (MFVC)能力结构，同时实现了MCFVC Function Group，则软件需对多个Function进行归类，归类到指定的Function Group。最大支持8个Function Group；对于相同Function Group的Function，其Function Group Number相同；

     4️⃣ 若ARI设备支持ACS P2P出口控制，访问控制的粒度可以基于Function亦可以基于Function Group。

     5️⃣ 对于支持并开启了 多Function VC仲裁 或 ACS P2P出端口控制 的情况，若非必须基于单Function的细粒度仲裁/控制，那么采用基于Function Group粒度的仲裁/控制不失为一种更优的选项。

     6️⃣ 为提升枚举性能减少不确定性，软件可基于Function Number链表来对PCIe拓扑中的Function进行枚举。Function 0是链表的头，若检测到其ARI能力寄存器Next Function Number字段非零则进行下以Function的扫描。⚠️注意：Function Number不一定是连续的。

   具备ARI能力的设备Function不支持Phantom Function功能，但仍然支持扩展Tag及10-bit Tag的请求者。因此需要把Function设备能力寄存器的Phantom Functions Supported置零（图6）。

   💡 注：Function Group是ARI设备内一组可配置的Function，可作为ARI设备内多Function间VC仲裁或访问控制的基础单位。

  

  图5 Device Control 2 Register

  

  图6 Device Capabilities Register

• ✨4. ARI 应用举例

  ---

  4.1 带有ARI 设备的PCIe系统

  下图（图7）是带有两个ARI设备的PCIe系统拓扑图，其中一个ARI设备Device_X上游紧邻RP_A，若要访问Device_X的扩展Function，RP_A必须支持并开启ARI转发功能；另一ARI设备Device_Y位上游紧邻Switch的下行端口D，若要访问Device_Y的扩展Function，Switch的下行端口D必须支持并开启ARI转发功能。

  

  图7 带有ARI设备的PCIe系统拓扑图

    由于RP_B及下行端口C没有紧邻ARI Device，为减小处理开销，不建议开启RP_B及下行端口C的ARI转发功能。

• 4.2 ARI 功能不可随意开

  ⛔️ 对于下游紧接非ARI设备的Switch下行端口，不建议开启其ARI功能。如若不然，Switch下行端口剔除了Routing ID中的Device Number，但非ARI设备仍然按照有Device Number的Routing ID进行处理，其提取出来的Device ID实则为ARI转换后Function Number的一部分而非预期中的0，继而按照Device Number不匹配对该请求事务进行响应。送往同一Function Group的多笔请求也会因为解析出不同的Device Number而导致非预期的行为。

   ⛔️ 若在Switch的下游端口重新热插拔了PCIe设备，建议软件清理掉先行关闭Switch下行端口的ARI功能，待确保新加的设备具备ARI能力后再行开启。