happy最紧要1. 先把“MP 通道”拆开：你要找的不是一条路，而是两套机制
1.1 一个能真实复现的场景：secondary 连不上 primary
前阵子给一个转发项目做 DPDK 多进程改造，primary 进程跑得好好的，secondary 一启动就报 EAL: FATAL: Cannot connect to primary process。我第一反应是看两边启动参数，结果 --file-prefix 一模一样，hugepage 挂载点也一样，数据面共享内存的日志也正常。最后用 ls /var/run/dpdk/ 翻了下运行目录才发现，secondary 起来的时候去连的那个 mp_socket 文件根本不在预期路径下。说白了，我一开始只盯着共享内存，没把 DPDK 多进程里真正负责“说话”的控制通道当回事。
这里说的 DPDK MP (Multi-Process) 通道，就是 primary 和 secondary 之间用来协调控制消息的那条链路。很多人刚接触 DPDK 多进程时，会默认“反正大家都映射同一块 hugepage 内存，互相之间不就能通信了吗”，这个理解对了一半。共享内存解决的是数据共享问题，但进程间还要有“谁先初始化”“谁有权限做设备操作”“某个配置改了你需要知道”这类控制语义，光靠一块内存是说不清的。DPDK 在主从进程之间实际提供了一套完整的进程间消息机制，最终落地就是一个叫 mp_socket 的本地套接字，以及基于它的一组 rte_mp_* API。把这套机制理解透，多进程遇到的大部分“连不上”“收不到”“超时”问题都能快速定位。
1.2 primary 和 secondary 的关系：谁有资格“动配置”
一个标准 DPDK 多进程环境里，第一个启动的是 primary，它负责初始化 EAL、分配 hugepage、创建共享内存布局、探测 PCI 设备、启动网卡队列。之后启动的 secondary 会通过 --proc-type=secondary 附加进来，它不会重复初始化这些资源，而是把自己进程的地址空间映射到 primary 已经建立好的共享内存上。
注意 secondary 能拿到共享配置、能通过 rte_eth_rx_burst 直接收包，但它并不天然拥有 primary 那种“改全局状态”的权限。比如设备热插拔、某些驱动配置变更、需要在所有进程间广播一件事，这些操作如果 secondary 自己闷头做，轻则两边视图不一致，重则把共享内存里的状态写坏。DPDK 的解法是：这种控制操作通过 MP 通道发消息给 primary，或者由某个进程向所有 peer 广播，收到消息的进程各自在本地做处理。所以这条通道本质上是一套“控制面的信令系统”，不是给你传大数据包用的。
1.3 一条叫控制通道，一条叫数据通道
我在实际项目里通常会把 DPDK 多进程通信拆成两条路来看，这样设计代码会清楚很多：
| 对比项 | 控制通道（EAL IPC） | 数据通道（共享内存） |
|---|---|---|
| 底层实现 | Unix domain socket + mp_socket |
hugepage 共享内存 + 无锁 rte_ring |
| 核心 API | rte_mp_request_sync、rte_mp_reply、rte_mp_sendmsg |
rte_ring_create/lookup、rte_ring_enqueue/dequeue |
| 典型数据量 | 几十到几百字节 | 每个包几百字节到几 KB，甚至更大 |
| 频率 | 低频，秒级或毫秒级 | 高频，每核每秒百万级 |
| 用途 | 设备操作、配置变更、进程启停协调 | 业务报文、描述符、流表更新后的消息传递 |
| 延迟 | 微秒到毫秒级，涉及内核 socket | 纳秒到微秒级，无锁共享内存 |
千万不要把控制通道当成业务通道去压测。我见过有人把一次流表更新消息塞进 rte_mp_msg 的 param 里批量下发，结果消息量一大，EAL 的 IPC 线程忙不过来，反而把正常的主从协调消息堵死了。流表这类高频数据应该走共享内存里的 ring，控制通道只负责通知“新表已发布，请到地址 X 读取”。后面我会详细展开这两条路各自怎么搭。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. mp_socket 是怎么被支起来的：命名、监听与握手
2.1 primary 和 secondary 如何互相发现
所有 rte_mp_* 消息的底层传输载体是 Unix domain s