对应路线图：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:1180InitializeMTCPManager 里最值得看的是流池：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 桶上挂的是自旋锁。
| 维度 | Linux TCP（v6.6） | mTCP（NSDI'14 设计） |
|---|---|---|
| 收包触发 | 硬中断 + 软中断（budget 限流） | 应用线程主动轮询，无预算 |
| 包容器 | 每包构造 skb（分配+引用计数） | 预分配 mbuf 池 |
| 连接表 | 全局 ehash + 桶锁 | 每核私有 hash，无锁 |
| 定时器 | 每 sock 独立 timer | 时间轮批查（P2-06 展开） |
| 事件 | 每事件一次唤醒 | 批量事件 + 单次唤醒 |
| 系统调用 | read/write 每次陷进内核 | 用户态函数调用 |
一句话总结：内核 TCP 不是算法差，而是每包的固定税太重（中断、锁、skb、syscall）；mTCP 把这四项税全部改成"批量均摊"，这就是 25 倍的来源。
论文的评测方法（为什么它的数字可信）
论文的可信度来自三个设计（公开知识转述，精确数字建议复核原文）：
- 对照公平：mTCP 和 Linux TCP 跑同一台机器、同一批应用（如 lighttpd/epwget 类工作负载），差别只在协议栈；
- 工作负载分层：短连接（CPS 型）、长连接（吞吐型）、混合型分开测——短连接最能暴露"每包固定税"，这正是 25 倍量级数字出现的场景；
- 可扩展性单独测：从 1 核加到 8/16/32 核画吞吐曲线，证明每核私有设计不随核数退化。
读论文时建议对照做一件事：把论文每个图对应的代码路径找出来——比如"batch I/O"对应 core.c:789 的 recv_pkts 循环，这正是本文第一节干的事。论文的图讲"现象"，代码行讲"机制"，两层对上才算读懂。
对 libmtcp-v3 的启示
这份"固定税清单"直接变成 P2-04 的验收标准：libmtcp-v3 每一行实现都要能回答"这一行在砍哪项税"——中断税（无，纯轮询）、锁税（每核私有）、skb 税（mempool 预分配）、syscall 税（用户态 API）。答不上来的代码就是过度设计，删。
面试 3 问
- mTCP 为什么能无锁跑满多核？ → 每个核一份完整 TCP 状态（flow_pool 每核独立，core.c:947），流经 RSS 钉死在核上（api.c:644），没有共享状态自然没有锁。
- mTCP 的 epoll 和内核 epoll 差在哪？ → 内核 epoll 每事件触发一次唤醒；mTCP 事件先进
mtcp_queue，主循环末尾批量 flush 到usr_queue再单次pthread_cond_signal（core.c:461-483）——唤醒次数从 O(事件数) 降到 O(批次)。 - 为什么说 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 的循环条件，回答"全部连接关闭后主循环为什么退出"。
评论 (0)