P2-01 · mTCP 论文精读（NSDI'14）：用户态协议栈为什么能快 25 倍

对应路线图：Phase 2 (Day 50-91) ｜ DPDK 24.11.6 LTS ｜ 内核对照 v6.6
代码出处：source/mtcp/mtcp/src/，引用均标 文件:行号；论文数字为公开知识转述，精确值以原文为准
上一篇：P1-07 RSS 与 rte_flow ｜ 下一篇：P2-02 mTCP 源码架构

一句话定位

mTCP（Jeong et al., NSDI'14）是"用户态 TCP 栈"这个品类的开山之作：每个核跑一个独立的 TCP 线程 + 批量收发 + 批量事件 + 流亲和，论文报告的典型数字约为小连接场景下 25 倍于 Linux TCP 的吞吐（建议复核原文）。读它 = 拿到一份"内核协议栈哪些开销可以砍掉"的完整清单。

论文四大论点 → 逐条对代码

论点 1：每核一个 TCP 线程，零共享锁。 全部连接状态（flow table、socket 池、定时器）按核私有。落地代码：线程入口 MTCPRunThread 每核一条，进来先绑核：

static void *
MTCPRunThread(void *arg)                        // core.c:1153
{
    mctx_t mctx = (mctx_t)arg;
    int cpu = mctx->cpu;
    // ...
    if (rte_lcore_id() == LCORE_ID_ANY)
        mtcp_core_affinitize(cpu);          // core.c:1164-1167

    /* memory alloc after core affinitization would use local memory
       most time */
    ctx = calloc(1, sizeof(*ctx));          // core.c:1172
    // ...
    mtcp = ctx->mtcp_manager = InitializeMTCPManager(ctx);   // core.c:1180

InitializeMTCPManager 里最值得看的是流池：MPCreate(pool_name, sizeof(tcp_stream), sizeof(tcp_stream) * CONFIG.max_concurrency)（core.c:947-948）——每核私有 mempool 预分配全部连接结构，运行时零 malloc。

论点 2：批量包 I/O。 论文批判内核"每包一次中断/一次分配"。mTCP 一次 rte_eth_rx_burst 收一批再逐包喂状态机（dpdk_module.c:464），发送攒进 wmbufs 一批 flush（dpdk_module.c:333-375）。详细拆解留给 P2-02。

论点 3：批量事件处理。 内核 epoll 每事件一次唤醒；mTCP 改造版 epoll 把事件先攒在 mtcp_queue，栈线程一轮循环末尾统一 FlushEpollEvents 搬到 usr_queue 再 pthread_cond_signal 一次（core.c:451-485）。一次唤醒处理一批事件，唤醒开销被摊平。

论点 4：RSS 流亲和，杜绝连接迁移。 论文还强调：同一连接永远落在同一核的 cache 里。落地代码 mtcp_init_rss（api.c:644）支持多 IP 的 RSS 流初始化；配合 P1-07 学的 Toeplitz 哈希，连接状态不再跨核漂移。

为什么内核做不到？看一段真代码

内核 TCP 收包入口（tcp_ipv4.c:1999 tcp_v4_rcv）每一包都要：查 ehash 连接表（__inet_lookup_established，tcp_ipv4.c:1803）→ 加锁（bh_lock_sock）→ 校验 → 进状态机。连接表全局共享（tcp_hashinfo，tcp_ipv4.c:93），hash 桶上挂的是自旋锁。

一句话总结：内核 TCP 不是算法差，而是每包的固定税太重（中断、锁、skb、syscall）；mTCP 把这四项税全部改成"批量均摊"，这就是 25 倍的来源。

论文的评测方法（为什么它的数字可信）

论文的可信度来自三个设计（公开知识转述，精确数字建议复核原文）：

1. 对照公平：mTCP 和 Linux TCP 跑同一台机器、同一批应用（如 lighttpd/epwget 类工作负载），差别只在协议栈；
2. 工作负载分层：短连接（CPS 型）、长连接（吞吐型）、混合型分开测——短连接最能暴露"每包固定税"，这正是 25 倍量级数字出现的场景；
3. 可扩展性单独测：从 1 核加到 8/16/32 核画吞吐曲线，证明每核私有设计不随核数退化。

读论文时建议对照做一件事：把论文每个图对应的代码路径找出来——比如"batch I/O"对应 core.c:789 的 recv_pkts 循环，这正是本文第一节干的事。论文的图讲"现象"，代码行讲"机制"，两层对上才算读懂。

对 libmtcp-v3 的启示

这份"固定税清单"直接变成 P2-04 的验收标准：libmtcp-v3 每一行实现都要能回答"这一行在砍哪项税"——中断税（无，纯轮询）、锁税（每核私有）、skb 税（mempool 预分配）、syscall 税（用户态 API）。答不上来的代码就是过度设计，删。

面试 3 问

1. mTCP 为什么能无锁跑满多核？ → 每个核一份完整 TCP 状态（flow_pool 每核独立，core.c:947），流经 RSS 钉死在核上（api.c:644），没有共享状态自然没有锁。
2. mTCP 的 epoll 和内核 epoll 差在哪？ → 内核 epoll 每事件触发一次唤醒；mTCP 事件先进 mtcp_queue，主循环末尾批量 flush 到 usr_queue 再单次 pthread_cond_signal（core.c:461-483）——唤醒次数从 O(事件数) 降到 O(批次)。
3. 为什么说 skb 构造是内核的固定税？ → 每收一包都要分配 skb、填字段、挂引用；mTCP 的 mbuf 从 mempool 来，收包只是换指针（对应 P1-02/P1-05 的 mempool/refill 机制），分配完全移出热路径。

🔧 动手实验

把论文四大论点逐一 grep 到代码行，形成"论点→行号"笔记（上面每个论点的行号就是答案），落点 perf-data/P2/01-paper-notes.md。检查项：① 找出一处 mTCP 仍用锁的地方（提示：ep->epoll_lock，core.c:457——它只保护栈线程与应用线程的队列边界，不在包路径上）；② 读 core.c:776 的循环条件，回答"全部连接关闭后主循环为什么退出"。

下一篇：P2-02 · mTCP 源码架构：core/tcp_in/eventpoll 三个入口