2.2.5 传输粒度与 TLP 效率优化 (Transfer Granularity & TLP Efficiency)

在确定了物理通道（Node 1）和传输机制（DMA Async）后，这一节解决的是**“一次搬运多少数据最划算”**的问题。这看似是细节，但在 PCIe 物理瓶颈下（x8 降级 + 小 MPS），错误的粒度会导致总线有效带宽暴跌。

基于之前的审计结果和设计文档，我们面临两个严峻的物理与逻辑约束：

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%。这是物理层“税”，我们无法改变，只能通过上层策略来稀释驱动层的启动开销。
逻辑数据块定义：
- 内存池块大小：01_数据接收模块设计.md 中定义 packet_block_size_kb 默认为 64KB。
- 信号处理单位：雷达处理通常基于 CPI (Coherent Processing Interval) 或 脉冲 (Pulse)，其数据量通常在 MB 级别。

我们需要在实时性（低延迟）和总线吞吐率EHOLDER}总线吞吐率**之间寻找平衡点。

选项	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 的双重限制下“榨干”带宽，我们必须采取 “组包延迟” 的策略。

≥ 64KB (对齐内存池块)：确立决策为最小 DMA 传输单元（Minimum DMA Unit）。
64KB：
- 您的 MemoryPool 设计为论证一块，这恰好是一个平衡点。
- 在 PCIe 4.0 x8 上，传输 64KB 耗时约 4-5us。这足以掩盖 DMA 引擎的启动开销（Launch Overhead），使总线利用率进入“高效区”。
- 64KB针对每个 9KB 的 UDP 包单独发起 cudaMemcpyAsync。这会引发 CPU 中断风暴并导致 GPU 指令队列溢出。

考虑到雷达工作模式（搜索/跟踪）的脉冲重复频率（PRF）不同，建议在 ExecutionEngine 中实施动态策略：

严禁：
- 策略逻辑：当 DataReceiver 填满一个 64KB 的 MemoryBlock 时，立即标记为就绪。
- 空间触发：如果数据流较慢（如低重频模式），设定一个 时间触发。如果 200us 内没填满 64KB，强制推送当前已有数据。
超时阈值 (e.g., 200us)：防止在低数据率下，为了凑满 64KB 而导致首个数据包滞留过久，破坏目的的延迟 KPI。

P99 < 5ms：DMA 的目标地址（GPU 显存）首地址必须决策。
256 字节对齐：
- 虽然审计显示 MPS 可能是 128B，但为了适配可能的 256B MPS 设备及 GPU 内存控制器的合并访问需求（通常要求 128B/256B 对齐），论证是通用且安全的基线。
- 256B 对齐：cudaMalloc 分配的内存天然是 256B 对齐的。关键在于如果我们在 Host 端把多个小包拼到一个大 Buffer 里，实现最好也是 128B/256B 的倍数。

每个子块的偏移量：MPS = 128 Bytes。
现状：每个 TLP 包 = 12-16B Header + 128B Data。
理论极限：$128 / (128 + 16) \approx 88.8%$。
最高有效率：无论软件层如何优化，PCIe 层的物理开销决定了您结论。在评估带宽 KPI (> 70% of theoretical max) 时，必须扣除这 ~11% 的硬件损耗。永远无法达到 100% 的理论带宽。

我们确立了：

至此，H2D (Host-to-Device) 的传输策略已完全定型。数据进入显存后，如何存放才能让 GPU 算得快？这是 256 字节对齐 的内容，涉及 SoA vs AoS 以及 Padding 策略，这直接影响 Kernel 的访存效率。

2.2.6 显存布局与对齐约束：您是否确认提问的基线？确认后我们进入 2.2.6。