企业官网建设流程全解析

1. 摘要

昇腾950 平台驱动 NVMe SSD 有4 条可行路径，硬件支撑度从高到低：

关键差异（昇腾950）：

• 昇腾950AIV PCIE-THROUGH 硬件能力后续能力兼容
• 昇腾950调度链路受限：HSCB 1.0 硬连线，仅 STARS→AICORE/SDMA 单向，AICPU 不能调度 AICore，AICore 不能调度 CCU
• 因此 昇腾950 下 AIV 自治驱动 NVMe（路径2）AICPU 介入调度的能力弱，AIV 直接走 PCIe-THROUGH 反而更顺畅

2. 昇腾950 PCIe-Through 能力

结论：AIV 通过 PCIE-THROUGH 直接访问 PCIe（含 NVMe）的硬件能力在 昇腾950 即已具备，后续兼容未做机制性改动。

结论：昇腾950 是多 master 共享的 PCIe 访问机制，AICORE（含 AIV）是其中之一。

3. 四条 NVMe 驱动路径详解

路径 1：Host CPU + PCIe DMA（昇腾950 主流方案）

Host CPU 昇腾950 │ │ │ 1. PCIe 枚举发现 NVMe EP │ │ 2. NVMe driver 初始化 Admin/SQ/CQ│ │ 3. 提交 NVMe Read/Write SQE │ │◀────── PCIe Doorbell ─────────────│ │ │ │ STARS 调度 PCIe DMA ────┤ │ │ PCIe DMA 通道搬运数据 │◀────── PCIe DMA 数据 ─────────────┤ │ │ │ 4. CQ 中断（MSI-X）上报完成 │ │◀────── MSI-X ─────────────────────│

硬件支撑：

• STARS 调度 PCIe DMA 通道（昇腾950 原生支持）

软件链路：

1. Host CPU 运行标准 Linux NVMe driver
2. NVMe driver 经 PCIe BAR 发现 NVMe 控制器寄存器
3. STARS 或 Host CPU 配置 PCIe DMA 通道搬运 SQE/CQE/data
4. NVMe 完成后 MSI-X 中断上报 Host

优点：成熟、标准、大块数据高效
缺点：依赖 Host CPU，Device 侧不能自治

路径 2：AIV PCIE-THROUGH 直接搬运（AIV 自治）

AIV Kernel (昇腾950) │ │ DataCopy<AIV>::Copy(ubBuf, nvmeBufVA_in_PCIE_window, size) │ → MTE2 DMA MOV (pcie_through enabled) │ → BIF → NoC BUS → PCIe RC ATU → PCIe TLP → NVMe │ │ DataCopy<AIV>::Copy(nvmeBufVA_in_PCIE_window, ubBuf, size) │ → MTE3 DMA MOV (pcie_through enabled) │ → PCIe RC ATU → PCIe TLP → NVMe │ └─ 绕过 STARS / SDMA / PCIe DMA / AICPU

硬件支撑：

• AIV MTE2/MTE3 PCIE-THROUGH mode 完整支持
• AICORE → PCIE，支持 1B~512B
• 配置 VA→PCIe BUS 地址

配置要点：

1. boot-time 配置 PCIE-THROUGH VA window（≥1GB，对齐窗口大小）
2. 配置 AIV SMMU bypass（PCIe-through 走 bypass，由 PCIe ATU 翻译）
3. 配置 PCIe 把 VA window 映射到 NVMe BAR 空间
4. AIV Kernel 用 DataCopy 访问 VA window，保证 128B 对齐、stride×repeat 不跨窗口、单 burst ≤512B

NVMe 命令提交：AIV 不能直接 ring NVMe Doorbell（MMIO 寄存器需 CPU 类指令），需配合：

• 模式 A：Host CPU / STARS CPU 提交 NVMe 命令，AIV 只搬数据
• 模式 B：STARS CPU 运行精简 NVMe driver 子集，提交 Admin/SQ/CQ + Doorbell，AIV 搬运 data buffer

优点：无 STARS/SDMA 调度开销，AIV 自治，低延迟小数据
缺点：单 burst ≤512B、不支持 atomic、不支持 L2Cache hint、需配合 CPU 提交 NVMe 命令

路径 3：STARS + PCIe Through（STARS 直接与 Host 交互）

与 NVMe 关系：此路径主要用于 STARS↔Host 控制面交互，若 Host 侧 NVMe driver 把 SQ/CQ 暴露给 STARS，STARS 可直接提交 NVMe SQE。但 STARS 本身不搬运数据，数据搬运由 PCIe DMA（路径1）或 AIV PCIE-THROUGH（路径2）完成。

优点：STARS 主动调度，减少 Host CPU 介入
缺点：STARS 软件开发复杂，昇腾950 STARS 算力有限

路径 4：SDMA + PCIe BAR（大块数据搬运）

STARS → SDMAM → SDMAA → HA → PCIe BAR → NVMe ↑ SDMAA → PCIe Bar 支持 128B/256B/512B，close门控

硬件支撑：

• SDMAA 经 HA→PCIE 访问 PCIe BAR，支持 128B/256B/512B
• 昇腾950 支持 STARS→SDMA 单向调度
• 跨 PCIe 搬运 SDMAA 根据地址拆分请求，不受 HA MRRS 限制；PCIe 不支持 atomic，跨 PCIe reduce 需下发到目的地址所在片

约束

• 跨 PCIe 搬运需用目的地址同片的 SDMAM
• PCIe 不支持 atomic，reduce 需片内做
• SDMAA 请求拆分不受 HA MRRS 限制
• Bypass SMMU 模式下用 PA 搬运

优点：大块数据高带宽，SDMA 40 通道并行
缺点：调度开销高（STARS SQE + SDMAM 解析），不适合低延迟小数据

4. 昇腾950 NVMe 驱动推荐方案

4.1 主流方案：Host CPU + PCIe DMA（路径1）

适用绝大多数生产场景。Host CPU 运行标准 NVMe driver，STARS 调度 PCIe DMA 搬运大块数据。硬件支撑度最高，软件最成熟。

4.2 低延迟方案：AIV PCIE-THROUGH（路径2）

适用 AIV 需要低延迟访问 NVMe 小批量数据的场景（如 KV-Cache 拉取、梯度写回）。配置要点：

1. SC boot-time: - 配置 PCIe RC TX ATU：VA window (≥1GB) → NVMe BAR 空间 - 配置 AIV MTE PCIE-THROUGH VA window（与 ATU 对应） - 配置 AIV SMMU bypass 2. STARS CPU 运行精简 NVMe driver: - 枚举 NVMe EP（经 PCIE TH，系统参数行42） - 初始化 Admin/SQ/CQ，ring Doorbell - 在 HBM 分配 NVMe data buffer，ATU 映射 3. AIV Kernel: - DataCopy<AIV>::Copy 从 PCIE window 读 data buffer 到 UB (MTE2) - 计算 - DataCopy<AIV>::Copy 从 UB 写回 PCIE window (MTE3) - PipeBarrier 等待完成 4. STARS CPU 检查 CQ，确认 NVMe 写完成

昇腾950 特有优势：因 AICPU 不能调度 AICore ，AIV 直接经 PCIE-THROUGH 访问 NVMe 避免了对 AICPU 调度链路的依赖。

4.3 大块数据方案：SDMA + PCIe BAR（路径4）

适用 HBM↔NVMe 大块数据搬运（模型加载、checkpoint 落盘）。STARS 调度 SDMA，SDMAA 经 PCIe BAR 搬运。需遵守跨 PCIe 拆分约束。

5. AIV + NVMe 读写性能不对称与读易受干扰

从硬件机制层面解释 AIV 经 PCIE-THROUGH 驱动 NVMe 时，读性能显著低于写性能且读易受干扰的根因。

5.1 典型现象

5.2 根因一句话

写路径单向、顺序、无需重排、资源占用瞬时释放；读路径双向、乱序、必须 ROB 重排、资源长期占用且对 BUS 反压敏感。

5.3 根因分层

┌─────────────────────────────────────────────────────────────┐ │ 应用层：NVMe Read 需介质访问(50~100us)，Write 只需 ACK(<1us) │ ├─────────────────────────────────────────────────────────────┤ │ PCIe 层：Read TLP 需 Completion TLP 返回(乱序)，Write TLP │ │ 即发即弃(缓冲吸收) │ ├─────────────────────────────────────────────────────────────┤ │ MTE 层：读需 ROB 重排+拼接(64B块)，占用 TAGID+ROB entry； │ │ 写保持 128B 粒度，无需拆分，资源瞬时释放 │ ├─────────────────────────────────────────────────────────────┤ │ BUS 层：读通道受 back pressure(TAGID满/BUS反压)，写通道反压小 │ ├─────────────────────────────────────────────────────────────┤ │ 资源层：outstanding 读 64~128 笔，TAGID 共享，ROB 容量有限； │ │ 写 outstanding 同等但占用时间短 │ └─────────────────────────────────────────────────────────────┘

5.4 写路径的"快"来自

• 写路径 back pressure（小）; 写通道反压仅在TAGID 全部占用或BUS 主动反压时触发。由于 Write TLP 是 posted，PCIe 端缓冲深度大，BUS 反压概率低；TAGID 占用时间短（发出即释放，不等 ACK）。因此写路径反压窗口极小。

• 写路径无需 ROB 重排; 写路径数据来自 UB，顺序读出，MTE 按顺序发 write request，不需要 ROB 重排。

5.5 读路径的"慢"来自

• 读路径 back pressure（大，核心干扰点）

读路径有双重反压：

1. 请求侧反压：TAGID 耗尽或 BUS 反压 → 新读请求 on-hold → outstanding 不再增加 → 吞吐下降
2. 数据侧反压：ROB 重排后的数据写 UB 时，若 UB bank conflict 或写接口反压 → 数据滞留在 back pressure data FIFO → ROB 空间不释放 → 反向影响新数据接收

6. 读写不对称的 6 个根因（逐条对照）

根因 1：NVMe 介质延迟不对称（应用层，主导因素）

AIV 发一笔 512B write：PCIe RTT(~1us) + NVMe ACK(<1us) ≈ 2us 即可释放资源发下一笔。
AIV 发一笔 512B read：PCIe RTT(~1us) + NVMe 介质(50~100us) + ROB 重排 ≈ 50~100us 才能释放资源。

单笔延迟差 25~50 倍，这是读写不对称的最主要来源。

根因 2：PCIe 事务类型不对称（协议层）

Write TLP 不占 read completion 信用，PCIe 端缓冲深，几乎不反压。
Read TLP 占用 outstanding 信用（PCIe 协议层 credit），受 NVMe 响应速度制约，credit 回收慢。

根因 3：MTE 数据处理不对称（MTE 层）

读路径的 ROB 重排是写路径完全没有的额外环节。

重排需维护链表、按 recycle status 调度，有固有开销，且 ROB 容量有限。

根因 4：资源占用时长不对称（资源层）

读路径资源占用时长 = PCIe RTT + NVMe 介质 + ROB 重排，是写路径的 25~50 倍。资源长期占用导致 outstanding 耗尽快，新请求被 on-hold。

根因 5：outstanding 上限不对称的影响放大

MTE FS（PCIE mode）outstanding 限制：

• 512B burst：64 outstanding（line 1413）
• 256B/128B burst：128 outstanding

写路径：64 笔 outstanding × 512B = 32KB 在途，因释放快，可持续填满。
读路径：64 笔 outstanding × 512B = 32KB 在途，但因每笔占用 50~100us，32KB 耗尽后必须等回收才能发新请求。

读有效带宽上限≈ 32KB / 50us = 640 MB/s（最坏 NVMe 介质延迟下）
写有效带宽上限≈ outstanding × 512B / PCIe RTT ≈ 32KB / 2us = 16 GB/s（理论）

实际受 NVMe 控制器、PCIe link 带宽限制，但读写差距可达10~25 倍。

根因 6：读路径干扰源多（干扰敏感性）

读路径因资源长期占用 + 双重反压，对以下干扰源敏感：

写路径因资源瞬时释放，上述干扰源影响极小。

7. 读易受干扰的具体场景

7.1 场景 A：多 AIV 核并发读 NVMe

AIV0 读 NVMe LBA 0~63 ─┐ AIV1 读 NVMe LBA 64~127 ├─ 共享 TAGID 池（64~128 笔）+ ROB 容量 AIV2 读 NVMe LBA 128~191─┘ 问题： - 3 核各需 outstanding，TAGID 池快速耗尽 - ROB 容量被 3 条指令瓜分，每条指令重排空间不足 - NVMe 乱序返回 3 核的 completion 混杂，ROB 链表碎片化 - 读有效带宽随核数增加而下降（非线性）

7.2 场景 B：读与 AIC MTE 流量竞争 BUS

AIC MTE2 从 HBM 读 L1 数据（高带宽、持续） + AIV MTE2 从 NVMe 读（PCIE-THROUGH，低带宽、长延迟） 问题： - NoC BUS read 通道被 AIC MTE2 占用，AIV read request 仲裁延迟 - AIV read completion 经 BUS 返回时被 AIC 流量拥塞 - AIV TAGID 占用时间进一步拉长 → outstanding 耗尽 → on-hold

7.3 场景 C：读数据写回 UB 时 bank conflict

AIV 正在向 UB 写本地计算结果（UB Write，高优先级） + MTE2 ROB 重排完成后向 UB 写 NVMe 读回数据（BUS Write，低优先级） MTE FS line 1575: "When bank conflict between UB Write and BUS Write (write-write conflict), the BUS Write is back pressured." 问题： - BUS Write（NVMe 读回数据）被 UB Write 反压 - 数据滞留在 back pressure data FIFO - ROB 空间不释放 → 新 completion 无法进入 ROB → 恶性循环

7.4 场景 D：NVMe 介质延迟抖动

AIV 连续发 64 笔 512B read（outstanding 上限） 预期：每笔 50us 返回，流水线持续 实际： - NVMe 某些 LBA 命中缓存（<10us），某些需介质（100us） - completion 乱序加剧，ROB 链表需大跨度重排 - 介质慢的笔占用 TAGID 100us，outstanding 被少量慢笔耗尽 - "head-of-line blocking"：ROB 链表头部慢笔未到，后续快笔数据无法写出

7.5 缓解措施

8. 读写不对称对照表