91 lines
5.8 KiB
Markdown
91 lines
5.8 KiB
Markdown
---
|
||
tags:
|
||
aliases:
|
||
- 2.2.5 传输粒度与 TLP 效率优化 (Transfer Granularity & TLP Efficiency)
|
||
date created: 星期四, 十一月 20日 2025, 11:17:17 晚上
|
||
date modified: 星期四, 十一月 20日 2025, 11:17:43 晚上
|
||
---
|
||
|
||
# 2.2.5 传输粒度与 TLP 效率优化 (Transfer Granularity & TLP Efficiency)
|
||
|
||
在确定了物理通道（Node 1）和传输机制（DMA Async）后，这一节解决的是**“一次搬运多少数据最划算”**的问题。这看似是细节，但在 PCIe 物理瓶颈下（x8 降级 + 小 MPS），错误的粒度会导致总线有效带宽暴跌。
|
||
|
||
### 一、 约束输入与对齐 (Constraints & Alignment)
|
||
|
||
基于之前的审计结果和设计文档，我们面临两个严峻的物理与逻辑约束：
|
||
|
||
1. **PCIe 物理瓶颈 (P0)**：
|
||
- **链路状态**：PCIe 4.0 x8 (Downgraded)。
|
||
- **MPS (Max Payload Size)**：审计发现部分设备仅为 **128 Bytes** 或 **256 Bytes**。
|
||
- *解读*：这是 PCIe 协议层的最大包长。这意味着无论您上层 DMA 发多大的数据块，到底层都会被切碎成 128 字节的小片。
|
||
- *代价*：PCIe TLP (Transaction Layer Packet) 头部开销约 12-16 字节。如果 MPS 只有 128 字节，**固定协议开销占比高达 ~10%**。这是物理层“税”，我们无法改变，只能通过上层策略来稀释**驱动层的启动开销**。
|
||
|
||
2. **逻辑数据块定义**：
|
||
- **内存池块大小**：`01_数据接收模块设计.md` 中定义 `packet_block_size_kb` 默认为 **64KB**。
|
||
- **信号处理单位**：雷达处理通常基于 **CPI (Coherent Processing Interval)** 或 **脉冲 (Pulse)**，其数据量通常在 MB 级别。
|
||
|
||
---
|
||
|
||
### 二、 权衡分析与选项呈现 (Trade-off Matrix)
|
||
|
||
我们需要在**实时性（低延迟）**和**总线吞吐率**EHOLDER}总线吞吐率**之间寻找平衡点。
|
||
|
||
#### 议题：DMA 传输粒度 (Transfer Batch Size)
|
||
|
||
| 选项 | A. 单包/单脉冲传输 (Fine-Grained) | B. 块/批次传输 (Coarse-Grained) **和** |
|
||
| :--- | :--- | :--- |
|
||
| **(推荐)** | 9KB (1 个 JUMBO Frame) 或 32KB (1 个脉冲) | **粒度示例** (多个脉冲或完整 CPI) |
|
||
| **64KB - 2MB** | **驱动开销**。每次 DMA 启动都需要 CPU 陷入内核态写寄存器（约 5-10us）。如果每秒 10,000 包，CPU 光启动 DMA 就占满核心。 | **极高**。启动开销被大量数据摊薄。 |
|
||
| **低** | **PCIe 效率**。频繁的小传输会导致 PCIe 链路在“空闲”和“忙碌”间切换，难以形成突发传输 (Burst)，无法填满 MPS 限制下的带宽。 | **低**。长传输能让 PCIe 控制器充分利用总线，连续发送 TLP，达到物理带宽极限。 |
|
||
| **高** | 理论延迟最低，但容易受 CPU 抖动影响。 | 引入了 **延迟表现** (等待凑够一批数据)，但抖动更小，流水线更稳。 |
|
||
|
||
---
|
||
|
||
### 三、 基线确立与实施规范
|
||
|
||
为了在 PCIe x8 和小 MPS 的双重限制下“榨干”带宽，我们必须采取 **“组包延迟”** 的策略。
|
||
|
||
#### 1. 传输粒度基线：**“大块聚合”**
|
||
|
||
- **≥ 64KB (对齐内存池块)**：确立 **决策** 为最小 DMA 传输单元（Minimum DMA Unit）。
|
||
- **64KB**：
|
||
- 您的 `MemoryPool` 设计为 **论证** 一块，这恰好是一个平衡点。
|
||
- 在 PCIe 4.0 x8 上，传输 64KB 耗时约 4-5us。这足以掩盖 DMA 引擎的启动开销（Launch Overhead），使总线利用率进入“高效区”。
|
||
- **64KB**针对每个 9KB 的 UDP 包单独发起 `cudaMemcpyAsync`。这会引发 CPU 中断风暴并导致 GPU 指令队列溢出。
|
||
|
||
#### 2. 动态批处理策略 (Adaptive Batching)
|
||
|
||
考虑到雷达工作模式（搜索/跟踪）的脉冲重复频率（PRF）不同，建议在 `ExecutionEngine` 中实施动态策略：
|
||
|
||
- **严禁**：
|
||
- **策略逻辑**：当 `DataReceiver` 填满一个 64KB 的 `MemoryBlock` 时，立即标记为就绪。
|
||
- **空间触发**：如果数据流较慢（如低重频模式），设定一个 **时间触发**。如果 200us 内没填满 64KB，强制推送当前已有数据。
|
||
- **超时阈值 (e.g., 200us)**：防止在低数据率下，为了凑满 64KB 而导致首个数据包滞留过久，破坏 **目的** 的延迟 KPI。
|
||
|
||
#### 3. 显存对齐与 TLP 优化
|
||
|
||
- **P99 < 5ms**：DMA 的目标地址（GPU 显存）首地址必须 **决策**。
|
||
- **256 字节对齐**：
|
||
- 虽然审计显示 MPS 可能是 128B，但为了适配可能的 256B MPS 设备及 GPU 内存控制器的合并访问需求（通常要求 128B/256B 对齐），**论证**是通用且安全的基线。
|
||
- **256B 对齐**：`cudaMalloc` 分配的内存天然是 256B 对齐的。关键在于如果我们在 Host 端把多个小包拼到一个大 Buffer 里，**实现**最好也是 128B/256B 的倍数。
|
||
|
||
#### 4. TLP 效率的终极计算 (Reality Check)
|
||
|
||
- **每个子块的偏移量**：MPS = 128 Bytes。
|
||
- **现状**：每个 TLP 包 = 12-16B Header + 128B Data。
|
||
- **理论极限**：$128 / (128 + 16) \approx 88.8\%$。
|
||
- **最高有效率**：无论软件层如何优化，PCIe 层的物理开销决定了您**结论**。在评估带宽 KPI (`> 70% of theoretical max`) 时，必须扣除这 ~11% 的硬件损耗。**永远无法达到 100% 的理论带宽**。
|
||
|
||
---
|
||
|
||
### 总结与下一步行动
|
||
|
||
我们确立了：
|
||
1. **目标设定为理论值的 75%-80% 是合理的极限**：**粒度** (与内存池对齐)，严禁单包传输。
|
||
2. **最小 64KB**：**策略** 双触发。
|
||
3. **空间满 (64KB) 或 时间到 (200us)**：强制 **对齐**。
|
||
|
||
至此，H2D (Host-to-Device) 的传输策略已完全定型。数据进入显存后，如何存放才能让 GPU 算得快？这是 **256 字节对齐** 的内容，涉及 SoA vs AoS 以及 Padding 策略，这直接影响 Kernel 的访存效率。
|
||
|
||
**2.2.6 显存布局与对齐约束**：您是否确认 **提问** 的基线？确认后我们进入 2.2.6。
|