创建仓库
This commit is contained in:
40
技术选择/DMA与内核旁路策略.md
Normal file
40
技术选择/DMA与内核旁路策略.md
Normal file
@@ -0,0 +1,40 @@
|
||||
---
|
||||
tags: []
|
||||
date created: 星期三, 十一月 19日 2025, 10:12:04 晚上
|
||||
date modified: 星期三, 十一月 19日 2025, 10:12:16 晚上
|
||||
---
|
||||
|
||||
### 2.1.5 DMA 与内核旁路策略 (DMA & Kernel Bypass Strategy)
|
||||
|
||||
- **概要**: 本节旨在确立数据从网络硬件到用户态页锁定内存 (`MemoryPool`) 的传输策略。核心目标是**最小化 CPU 参与**和**消除内核层面的内存拷贝**。基于当前 Feiteng/Kylin 平台的稳定性与现有设计兼容性考量，我们确立**优化标准 I/O**为基线方案，并以 AF\_XDP 作为 P0 级性能提升的风险备选方案。
|
||||
- **约束前提**
|
||||
1. **物理约束**: 采集链路为 **1GbE** (物理上限)。
|
||||
2. **协议基线**: **UDP/IP + JUMBO Frame (MTU 9000 字节)** (已确认)。
|
||||
3. **软件架构**: 模块已采用**多级流水线并发**和**页锁定内存池**。
|
||||
|
||||
---
|
||||
|
||||
### 基线方案（A）：优化标准 I/O 与批量接收 (`recvmmsg`)
|
||||
|
||||
- **设计哲学**: 平台兼容性优先，在确保系统稳健性的前提下，通过软件优化达到高性能目标。该方案与模块已设计的 **`UdpReceiver` I/O 线程**和 **`epoll` 事件循环**完全兼容。
|
||||
- **实现策略**:
|
||||
1. **内核 I/O 机制**: `UdpReceiver` 组件运行在专用的 I/O 线程中，利用 Linux 内核提供的 `recvmmsg()` 系统调用进行数据接收。
|
||||
2. **核心性能优化 (批量接收)**: `recvmmsg()` 的优势在于**一次系统调用可以处理多达 256 个数据包**，极大减少了用户态与内核态之间的切换开销，这是降低 I/O 线程 CPU 占用率 (KPI 目标之一) 的关键手段。
|
||||
3. **吞吐量放大**: 结合已确立的 **JUMBO Frame (MTU 9000)** 基线，每一次 `recvmmsg()` 调用都将传输大量的有效净载荷，使得系统调用的价值被最大化，有效压榨 1GbE 链路的极限吞吐量。
|
||||
4. **数据流**: **网卡 DMA** $\to$ **内核 Ring Buffer** $\to$ **用户态 `MemoryPool` (内存拷贝)**。虽然仍存在内核到用户空间的拷贝，但通过**批量接收**和**巨型帧**的组合，将拷贝效率提升至最高水平。
|
||||
|
||||
---
|
||||
|
||||
### 备选方案（B）：AF\_XDP 内核零拷贝 (P0 性能备选)
|
||||
|
||||
- **设计目标**: 达成真正的**内核旁路零拷贝**，将数据从网卡 DMA 区域直接映射到用户态，完全消除 I/O 线程中的内存拷贝开销，以达成更严格的 **CPU 资源占用率** KPI。
|
||||
- **实现策略与风险**:
|
||||
1. **技术路径**: 通过 eBPF 程序将网络流量重定向到 AF\_XDP Socket，绕过内核协议栈。
|
||||
2. **兼容性风险 (P1)**: 当前系统运行在 **Kylin Linux 4.19 内核**上。此内核版本对 XDP/eBPF 技术的支持成熟度和功能完整性低于主流 5.x 内核。同时，网卡驱动（Wangxun WX1860AL4）对 XDP 接口的适配状况未知。
|
||||
3. **启用时机**: 仅当 **基线方案 A (优化标准 I/O)** 无法满足 **I/O 线程 \< 5% (单核)** 的 CPU 资源占用率 KPI 时，才启动对 AF\_XDP 在当前平台上的兼容性验证和移植工作。
|
||||
|
||||
---
|
||||
|
||||
### 舍弃方案（C）：DPDK
|
||||
|
||||
- **舍弃理由**: DPDK 采用轮询模式（Poll Mode），与模块设计的 `epoll` 异步事件驱动模型相悖。且 DPDK 需要将网卡完全从内核中接管，在 **Kylin/aarch64 平台**上的部署、驱动绑定和调试成本过高，与项目的稳健性原则不符。
|
||||
49
技术选择/清单.md
Normal file
49
技术选择/清单.md
Normal file
@@ -0,0 +1,49 @@
|
||||
---
|
||||
tags: []
|
||||
date created: 星期四, 十一月 20日 2025, 8:52:43 晚上
|
||||
date modified: 星期日, 十二月 7日 2025, 9:26:50 晚上
|
||||
---
|
||||
流的设计模式：B. 多流乒乓/多缓冲 (Multi-Stream Ping-Pong) (推荐)
|
||||
但是 先设计 A. 单流串行 (Serial Stream) 作为代码调试阶段的轻量级。
|
||||
|
||||
1. 缓冲区管理状态机
|
||||
|
||||
```mermaid
|
||||
stateDiagram-v2
|
||||
%% 状态定义
|
||||
state "HOST_OWNED<br/>(主机所有)" as HOST
|
||||
state "DEVICE_OWNED_H2D<br/>(传输中: H->D)" as H2D
|
||||
state "DEVICE_OWNED_COMPUTE<br/>(计算中: Kernel)" as COMPUTE
|
||||
state "DEVICE_OWNED_D2H<br/>(传输中: D->H)" as D2H
|
||||
state "RELEASED<br/>(待归还)" as RELEASED
|
||||
|
||||
%% 流程流转
|
||||
[*] --> HOST : 从 MemoryPool 申请
|
||||
|
||||
HOST --> H2D : I/O线程填充数据\n并调用 cudaMemcpyAsync
|
||||
note right of HOST
|
||||
此时数据位于页锁定内存
|
||||
CPU 写入完成
|
||||
end note
|
||||
|
||||
H2D --> COMPUTE : 记录 H2D_Event\nStreamWaitEvent
|
||||
note right of H2D
|
||||
DMA 引擎正在搬运
|
||||
CPU 不阻塞
|
||||
end note
|
||||
|
||||
COMPUTE --> D2H : Kernel 执行完毕\n自动触发 D2H
|
||||
note right of COMPUTE
|
||||
GPU 核心正在计算
|
||||
数据驻留显存
|
||||
end note
|
||||
|
||||
D2H --> RELEASED : D2H 完成回调\n或 Event 同步
|
||||
note right of D2H
|
||||
结果已写回 Host
|
||||
end note
|
||||
|
||||
RELEASED --> HOST : DataPacket 析构\n自动归还 Pool
|
||||
|
||||
RELEASED --> [*]
|
||||
```
|
||||
Reference in New Issue
Block a user