DPDK多进程通信：从MP通道到数据通道的架构与实践

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 多进程通信拆成两条路来看，这样设计代码会清楚很多：

千万不要把控制通道当成业务通道去压测。我见过有人把一次流表更新消息塞进 rte_mp_msg 的 param 里批量下发，结果消息量一大，EAL 的 IPC 线程忙不过来，反而把正常的主从协调消息堵死了。流表这类高频数据应该走共享内存里的 ring，控制通道只负责通知“新表已发布，请到地址 X 读取”。后面我会详细展开这两条路各自怎么搭。

2. mp_socket 是怎么被支起来的：命名、监听与握手

2.1 primary 和 secondary 如何互相发现

所有 rte_mp_* 消息的底层传输载体是 Unix domain socket。primary 进程在 EAL 初始化阶段会创建一个监听 socket，这个 socket 文件通常出现在运行目录下面，文件名在绝大多数 DPDK 版本里就是 mp_socket。你可以用下面的命令看它到底在哪：

bash复制find /var/run/dpdk -name mp_socket -type s 2>/dev/null
ls -la /var/run/dpdk

如果权限不足或者发行版把 /var/run 的处理改过，那就直接看 primary 进程打开的文件描述符：

bash复制ls -l /proc/<primary_pid>/fd | grep socket

secondary 启动时不会自己去创建监听 socket，它要做的是找到 primary 已经创建好的那个 socket 文件并 connect 上去。两端必须住在同一个“运行目录”里，否则互相看不见。判断运行目录的关键因素有两个：一是 --file-prefix，二是 hugepage 挂载目录。社区里最常见的连不上原因，就是主备进程启动参数里 --file-prefix 不一样。primary 用 --file-prefix=app1 起，secondary 图省事没加，结果两边算出来的共享内存名和 socket 路径对不上，连接直接失败。

2.2 file prefix 不只是文件前缀

很多 DPDK 初学者以为 --file-prefix 只影响 hugepage 映射文件的名字，实际上它影响的范围包括共享内存配置文件名、mp_socket 所在路径、以及 multiprocess 之间互相识别的命名空间。可以说，--file-prefix 就是多进程世界的“门牌号”。同一台机器上跑多套 DPDK 应用时，每套应用必须用不同的 file prefix，否则后来的 primary 会发现自己要创建的共享内存文件已经被占用，或者直接报共享内存冲突。

这一点在排查 MP 通道问题时特别重要。如果你看到日志里出现 Cannot connect to primary process，不要先怀疑代码逻辑，先确认两边运行参数：

bash复制# primary
./dpdk-app --file-prefix=pf1 --proc-type=primary
# secondary
./dpdk-app --file-prefix=pf1 --proc-type=secondary

两个进程的 --file-prefix 必须完全一致。另一个隐蔽点是容器场景：如果 primary 跑在容器 A，secondary 跑在容器 B，即使文件路径看起来一样，Unix domain socket 也无法跨 network namespace 连通。很多人在容器化部署 DPDK 多进程时踩过这个坑，解决办法是把两个进程放进同一个 network namespace，或者把 secondary 也塞进 primary 所在的 Pod/容器里。

2.3 socket 生命周期与重连问题

mp_socket 是 primary 进程创建出来的本地套接字文件，它跟着 primary 的生命周期走。primary 正常退出时，EAL 会清理这个文件；但 primary 被 kill -9 强杀或者宿主机异常重启时，这个 socket 文件很可能残留下来。残留文件对 secondary 会造成一种很迷惑的现象：文件明明存在，connect 却返回 Connection refused，因为监听端已经没了。

我自己遇到过一次：primary 崩溃后立刻重启，新 primary 在初始化时发现旧 mp_socket 文件还在，有的版本会主动清理，有的版本如果处理不干净，就会导致新 primary 创建 socket 失败。这种情况的通用处理方式很简单：

bash复制# 先确认没有相关 primary 进程存活
pgrep -f "dpdk-app.*proc-type=primary"
# 确认没有之后，清理残留 socket 文件
rm -f /var/run/dpdk/*/mp_socket

比手动清理更可靠的做法是把 --file-prefix 当成“实例 ID”来用，每次发布新版本时换一个 ID，旧实例没清干净也不会影响新实例。后面第 6 节里我会专门讲多实例隔离。

3. 报文格式与收发语义：一条 MP 消息的真正生命周期

3.1 一个定长的消息壳子

MP 通道上跑的每条消息，在用户态 API 层面都是一个 struct rte_mp_msg。这个结构体很小，但信息密度很高，主要包括四部分：

name 的设计思路类似 Linux netlink 的消息类型，或者 HTTP 里的 URL 路径。发送方填一个字符串，比如 "CFG_UPDATE"，接收方进程内部维护了一张 action 名到回调函数的表。消息进来之后，EAL 的后台 IPC 线程按 name 查表，找到对应回调就执行，找不到就返回错误。这个设计让一条 socket 连接可以承载多种不同业务，而不是每类消息都单独开一条链路。

注意 param 的长度上限并不大。我在 DPDK 20.11 上看到的限制是 256 字节级别，具体值不同小版本可能调整，以你自己环境头文件里的宏定义为准。这意味着 MP 通道天然不适合传大块数据，适合传“指令 + 索引”这种轻量内容。真正的大块流表或报文内容应该放进共享内存，然后在 param 里告诉对端去读哪个地址。

3.2 一次同步请求的完整代码形态

接收端（通常是 primary）先注册动作：

c复制static int handle_config_update(const struct rte_mp_msg *msg,
                                const void *peer)
{
    struct rte_mp_msg resp;
    const struct app_cfg_msg *cfg = (const struct app_cfg_msg *)msg->param;

    memset(&resp, 0, sizeof(resp));
    strncpy(resp.name, "CFG_UPDATE", sizeof(resp.name));
    resp.len = snprintf((char *)resp.param, sizeof(resp.param),
                        "applied seq=%u", cfg->seq);

    return rte_mp_reply(&resp, peer);
}

int main(int argc, char *argv[])
{
    ...
    rte_mp_register("CFG_UPDATE", handle_config_update);
    ...
}

发送端（secondary）用同步接口发出请求并等待应答：

c复制struct rte_mp_msg req;
struct rte_mp_reply reply;
struct timespec ts = {
    .tv_sec = 1,
    .tv_nsec = 0,
};
struct app_cfg_msg cfg = {
    .seq = 100,
};

memset(&req, 0, sizeof(req));
strncpy(req.name, "CFG_UPDATE", sizeof(req.name));
memcpy(req.param, &cfg, sizeof(cfg));
req.len = sizeof(cfg);

if (rte_mp_request_sync(&req, &reply, &ts) == 0) {
    for (int i = 0; i < reply.nb_received; i++) {
        printf("reply from peer %d: %s\n",
               i, (char *)reply.msgs[i].param);
    }
}

这段代码里最容易出错的是 rte_mp_reply 的第二个参数。它接收的是回调函数传入的 peer，而不是自己随便填的进程名。peer 本质上是 socket 连接对端的地址信息，EAL 内部靠它找到应该把响应发回给谁。有次我图省事，在收到请求后自己构造了一个 peer，结果响应发不出去，对端一直等到超时。不要手动伪造这个参数，原样传下去就行。

3.3 同步、异步和单向消息：别在数据面线程里等答复

rte_mp_request_sync 是同步阻塞接口，它会阻塞当前调用线程直到收到应答或超时。因为 EAL 会把请求广播给同一运行域里的所有 peer 进程，所以 reply 结构里会有 nb_sent 和 nb_received 两个计数。nb_sent 是实际发出请求的 peer 数量，nb_received 是超时前收到响应的数量。两者不一致就说明有进程没及时响应。

同步接口的坑在于：千万不要在数据面的收包线程里直接调用它。数据面线程的任务是轮询 rte_eth_rx_burst 和 rte_ring_dequeue，一旦阻塞在 socket 等待上，这个核的收包能力立刻归零，队列很快被背压打满。正确的做法是在单独的控制线程、或者某个专门处理管理命令的 lcore 上执行同步请求。

如果不想阻塞任何线程，用异步接口：

c复制static void async_cb(const struct rte_mp_msg *request,
                     const struct rte_mp_reply *reply)
{
    /* 结果回来后在 EAL IPC 线程上下文执行 */
}

rte_mp_request_async(&req, &ts, async_cb);

还有一种是纯单向的 rte_mp_sendmsg，发出去就不管结果，适合做“内存不值一提”的通知类消息。比如 secondary 想告诉 primary “我要退出了，清理一下我注册的临时资源”，这种消息不需要应答，单向发送就够了。少一次应答等待，就少一类超时问题。

4. 数据面的另一条“通道”：共享 ring 为什么不能省

4.1 控制通道不是用来传包的

如果你把 MP 通道当成唯一通道，所有进程间数据都往 rte_mp_msg 里塞，很快就撞上一堵墙：报文大小受限、每次 sendmsg/recvmsg 都有系统调用、socket 线程还要做消息拆分和路由，吞吐量根本撑不住数据面要求。Unix domain socket 虽然比 TCP socket 快，但它毕竟要经过内核，并且一次一帧消息的处理方式和网卡收包那种批量轮询完全不是一个数量级。

数据面的正统做法是共享内存里的 rte_ring。rte_ring 是一个多生产者多消费者安全的无锁环形队列，核心设计是头尾指针配合 CAS，生产者只动头，消费者只动尾，在常见模型下不需要锁。两个 DPDK 进程如果共享同一块 hugepage 内存，它们看到的 rte_ring 是同一份物理内存，队列里的报文指针就能跨进程传递。

4.2 多进程共享 ring 的硬前提

要让两个进程共享一个 ring，必须满足两个条件：第一，ring 本身要创建在 primary 进程的共享内存空间里；第二，secondary 要通过名字查找，而不是自己再创建一个同名 ring。primary 里这样创建：

c复制struct rte_ring *tx_ring = rte_ring_create(
    "mp_data_ring",
    1024,
    rte_socket_id(),
    RING_F_SC_DEQ | RING_F_SP_ENQ
);

secondary 里这样找到它：

c复制struct rte_ring *tx_ring = rte_ring_lookup("mp_data_ring");
if (tx_ring == NULL) {
    /* 查不到说明 primary 还没创建或者 file prefix 不一致 */
}

注意 rte_ring_create 时名字非常重要，它是整个共享内存对象命名空间里的唯一标识。如果 secondary 用 rte_ring_create 而不是 rte_ring_lookup，它只会创建一块自己私有地址空间里的 ring，和 primary 那个完全是两回事。这个错误一犯，两个进程都以为自己数据发出去了，实际各发各的，谁也没收到。排查这类问题时，看一眼两个进程里打印出来的 ring 地址，如果地址空间差异巨大但内容互不可见，基本就是这个问题。

同样道理，报文池也推荐用 primary 创建、secondary lookup 的方式：

c复制struct rte_mempool *mp = rte_mempool_lookup("app_pktpool");

这样做还有个好处：一次启动时分配好 mbuf，secondary 不需要重复分配，内存占用也更好控制。

4.3 控制通道 + 数据通道的经典组合

实际部署里，我常用的结构长这样：

• primary 负责网卡初始化、流表下发、状态统计，控制平面指令通过 MP 通道广播。
• secondary 从同一个 rte_ring 里取流表更新事件，但真正的流表数据放在共享内存的另一块区域，rte_ring 里只放“数据已经就绪，请到地址 A 读取”的指针。
• primary 和 secondary 之间没有业务报文直接走 rte_mp_msg，业务报文要么通过 ring 指针传递，要么通过 mempool 分配后把地址写进 ring。

这套组合跑起来之后，MP 通道的负载会非常低，每秒可能只有几十条事件；业务数据通道则能跑满网卡线速。两者各司其职，不要互相替代。

5. 真实场景中的控制链路设计：不是所有事都该直接改共享内存

5.1 设备热插拔：为什么必须通过 primary

多进程环境里，设备管理存在一个很现实的问题：primary 在初始化时通过 PCI 扫描拿到设备列表，并把这些设备的资源映射进共享内存。secondary 如果要自己执行设备的 probe 或者 remove，很容易造成设备资源的管理状态在两个进程间不一致。更稳妥的方式是 secondary 给 primary 发一条消息，让 primary 去做设备操作，操作完成后再通过广播通知所有 secondary 刷新自己的设备视图。

我之前的项目里，有一个端口绑定关系需要在运行期动态调整。secondary 想加一个 virtio-user 端口，如果直接在 secondary 里调用设备初始化接口，第一步就会撞上 EAL 的设备锁。后来改成：

1. secondary 构造 rte_mp_msg，name 填 "DEV_ATTACH_REQUEST"，param 里放设备参数。
2. primary 收到后在 IPC 线程上下文异步派发一个工作线程执行 rte_eal_hotplug_add。
3. 执行完，primary 再广播一条 "DEV_ATTACHED" 事件给所有 secondary。
4. secondary 收到事件后，再去共享内存的 ethdev 列表里按名字查找新端口。

这套链路跑顺之后，主从两边的设备视图始终一致，不会出现“primary 看到 8 个端口，secondary 只看到 7 个”的诡异现象。

5.2 广播事件：让所有进程“知道”而不是“看到”

共享内存最大的问题不是慢，而是没有“通知”语义。A 进程改了一个字段，B 进程如果不主动轮询，根本不知道字段变了。控制通道正好补充这个缺失：它能让所有 peer 在同一时间点收到同一个事件。

比如我要做配置版本同步。primary 改了共享内存里的流表版本号，传统做法是 secondary 每次收包前都去比较版本号，浪费 CPU。更好的做法是 primary 改完后调用一次 rte_mp_sendmsg，广播一条 "CFG_VER_CHANGED" 消息。secondary 在回调里只要做一个动作：把自己缓存里的版本号字段失效。下次收包前的查询逻辑发现缓存失效，再去共享内存拉最新配置。这种“事件通知 + 按需拉取”的组合，比让每个 secondary 高频轮询省太多指令周期了。

写广播消息时，消息体尽量精简。我见过一个同事在广播里附上整个 2MB 的流表快照，后果就是所有进程的 IPC 线程同时卡住，连 primary 的心跳响应都发不出来。广播消息里放“版本号 + 变更类型 + 变更条目的共享内存地址”，就够了。

5.3 消息协议设计：给 param 里放一个自己的头

直接用裸的 param 数组传数据虽然可行，但项目一复杂就难维护。我习惯在 param 的最前面放一个自定义协议头，包含消息类型、序列号、长度、发送方角色，后面再跟具体业务数据：

c复制struct app_mp_header {
    uint16_t msg_type;
    uint16_t sender;
    uint32_t seq;
    uint32_t len;
};

加上序列号尤其重要。rte_mp_request_sync 虽然有超时机制，但超时不代表对端没收到请求，只代表对端没在规定时间内回复。如果业务上存在重发逻辑，没有序列号就可能把同一条配置重复执行两次。用 seq 做去重，等于给控制通道加了一层幂