共 7 篇
-
P2-03 · 🐧 对照：mTCP 与内核 TCP 状态机逐状态对比 对应路线图：Phase 2 (Day 50-91) ｜ DPDK 24.11.6 LTS ｜ 内核对照 v6.6.143代码出处：source/mtcp/mtcp/src/tcp_in.c vs source/linux-stable/net/ipv4/tcp_input.c，引用均标 文件:行号上一篇：P2-02 mTCP 源码架构 ｜ 下一篇：P2-04 libmtcp-v3 设计一句话定位同一份 RFC 793 状态机，mTCP 用 65 行 switch 写完，内核用一个 switch + 一条快路径 + 半连接队列 + TW 子机写完。逐状态对照一遍，用户态栈"简化了什么、为什么敢简化"就全清楚了。两个分发器先摆一起mTCP 的 switch（tcp_in.c:1298-1363，节选）： switch (cur_stream->state) { case TCP_ST_LISTEN: Handle_TCP_ST_LISTEN(mtcp, cur_ts, cur_stream, tcph); break; case TCP_ST_SYN_SENT: Handle_TCP_ST_SYN_SENT(mtcp, cur_ts, cur_stream, iph, tcph, seq, ack_seq, payloadlen, window); break; case TCP_ST_SYN_RCVD: /* SYN retransmit implies our SYN/ACK was lost. Resend */ if (tcph->syn && seq == cur_stream->rcvvar->irs) Handle_TCP_ST_LISTEN(mtcp, cur_ts, cur_stream, tcph); else { Handle_TCP_ST_SYN_RCVD(mtcp, cur_ts, cur_stream, tcph, ack_seq); if (payloadlen > 0 && cur_stream->state == TCP_ST_ESTABLISHED) { Handle_TCP_ST_ESTABLISHED(mtcp, cur_ts, cur_stream, tcph, seq, ack_seq, payload, payloadlen, window); } } break; // ... ESTABLISHED / CLOSE_WAIT / LAST_ACK / FIN_WAIT_1 / FIN_WAIT_2 // ... CLOSING / TIME_WAIT / CLOSED，共 11 个分支 }内核的 switch（tcp_input.c:6637-6684 + 6725 起，节选）： switch (sk->sk_state) { case TCP_CLOSE: SKB_DR_SET(reason, TCP_CLOSE); goto discard; case TCP_LISTEN: if (th->ack) return 1; if (th->rst) { /* ... */ goto discard; } if (th->syn) { // ... acceptable = icsk->icsk_af_ops->conn_request(sk, skb) >= 0; // ... consume_skb(skb); return 0; } // ... case TCP_SYN_SENT: tp->rx_opt.saw_tstamp = 0; tcp_mstamp_refresh(tp); queued = tcp_rcv_synsent_state_process(sk, skb, th); if (queued >= 0) return queued; // ... }最关键的架构差：内核 ESTABLISHED 之后根本不进这个 switch——普通数据包走 tcp_rcv_established 快路径（tcp_input.c:6009），只有 SYN/FIN/异常才落到 tcp_rcv_state_process（tcp_input.c:6627）慢路径。mTCP 每包都过同一个 switch，靠 static inline 的 handler 把分支成本压到可接受。逐状态对比（只看有料的三组）LISTEN：mTCP 直接转态 vs 内核建 request_sockmTCP 的 Handle_TCP_ST_LISTEN（tcp_in.c:750-764）收 SYN 直接 state = TCP_ST_SYN_RCVD 并 AddtoControlList 回 SYN/ACK——没有半连接队列，没有 SYN cookie。内核在 LISTEN 收 SYN 调 icsk_af_ops->conn_request（tcp_input.c:6660）建 request_sock 挂半连接队列，由 tcp_check_req（tcp_minisocks.c:602）在三路握手最后校验。半连接队列 + cookie 是防 SYN flood 的，mTCP 的假设是"信任内网/测试环境流量"——这就是简化权。SYN_SENT：主动打开路径mTCP（tcp_in.c:767-812）三步走：① ACK 不可接受（TCP_SEQ_LEQ(ack_seq, iss)）直接回 RST（:774-782）；② RST 则进 CLOSE_WAIT 报错（:787-798）；③ SYN+ACK 则 HandleActiveOpen 后置 ESTABLISHED、清 RTO（RemoveFromRTOList，:810）、RaiseWriteEvent 通知应用可写（:815）。内核把同时打开等边角情况交给 tcp_rcv_synsent_state_process（tcp_input.c:6675）单独处理，主 switch 只做收尾（tcp_input.c:6672-6683）。ESTABLISHED：mTCP 一个函数 vs 内核快慢双路径mTCP 的 Handle_TCP_ST_ESTABLISHED（tcp_in.c:906-953）顺序：SYN 异常回 ACK → payload 进 ProcessTCPPayload 并攒 ACK（ACK_OPT_AGGREGATE 延迟 / ACK_OPT_NOW 立即，:921-928）→ ACK 进 ProcessACK（:932）→ FIN 序号合法则转 CLOSE_WAIT 并 RaiseReadEvent（:937-947）。内核快路径 tcp_rcv_established（tcp_input.c:6009）只处理"序号连续、无标志异常"的段：校验 header pred、更新 ACK、直接进接收队列，全程不锁用户态锁、不做状态判断；一旦 tcp_validate_incoming（tcp_input.c:5862）判异常就跌回慢路径。TIME_WAIT：链表批查 vs TW 子机mTCP 收 FIN 转 TIME_WAIT 时挂进 timewait_list（tcp_in.c:1139），由主循环 CheckTimewaitExpire 每轮批查过期销毁（timer.c:444-487，ts_tw_expire 到期 → CLOSED + DestroyTCPStream）。TIME_WAIT 里再收到 FIN 重传就 re-arm 定时并补 ACK（tcp_in.c:1352-1360）。内核的 TW 是独立生命周期：tcp_time_wait（tcp_minisocks.c:280）把 sock 转成 inet_timewait_sock，由 tw_timer 定时回收，迟到的包走 tcp_timewait_state_process 专门处理。mTCP 一个链表搞定，内核一个子状态机搞定——复杂度差一个数量级。🐧 差异总表状态mTCP（tcp_in.c）Linux v6.6（tcp_input.c）差异本质LISTEN:750-764，SYN 直接转 SYN_RCVD:6642-6667，conn_request 建 request_sock无半连接队列/cookieSYN_SENT:767-812，ACK/RST/SYN+ACK 三分支:6672-6683，交 synsent_state_process内核单列同时打开SYN_RCVD:1308-1320，ACK 转 ESTABLISHED 且同包数据顺带处理:6726-6768，tcp_init_transfer + tcp_set_statemTCP 顺带处理是亮点ESTABLISHED:906-953，单函数全处理:6009 快路径 + 慢路径兜底快慢路径分离是内核最大工程FIN_WAIT_1:1033 起:6770-6779，先验 snd_una != write_seq内核多一层 FIN 序号防护TIME_WAITtimer.c:444 链表批查tcp_minisocks.c:280 TW 子机链表 vs 子状态机面试 3 问内核为什么需要 tcp_rcv_established 快路径？ → ESTABLISHED 占 99% 包量；快路径省掉状态 switch、锁与校验分支，只做 header pred + ACK 处理（tcp_input.c:6009）；异常段经 tcp_validate_incoming 跌回慢路径（tcp_input.c:5862）。mTCP SYN_RCVD 转 ESTABLISHED 时"顺带处理 payload"体现在哪？ → tcp_in.c:1314-1318：ACK 完成后若 state == TCP_ST_ESTABLISHED 且 payloadlen>0，直接再调一次 ESTABLISHED handler——同一轮循环把三次握手和数据都吃掉，省一轮事件。mTCP 为什么敢不要半连接队列？ → 定位是单机多核的 Web/LB 场景，SYN flood 交给前面的硬件/网关防；省掉 request_sock 结构、队列和定时器（对照 tcp_input.c:6660 与 tcp_minisocks.c:602）。🔧 动手实验用 tcpdump 抓一次完整的三次握手 + 四次挥手，对照本文行号逐包标出"哪个包触发了哪一行"。再做一个改动实验：把 mTCP tcp_timewait 配成 0（sample_mtcp.conf:71 默认就是 0）观察短连接压测下 TIME_WAIT 立即回收的吞吐差。数据落点 perf-data/P2/03-fsm.md。下一篇：P2-04 · libmtcp-v3 设计：RFC、模块图、内存模型 -
P2-04 · libmtcp-v3 设计：RFC、模块图、内存模型 对应路线图：Phase 2 (Day 50-91) ｜ DPDK 24.11.6 LTS ｜ 内核对照 v6.6代码出处：code/libmtcp-v3/（当前为骨架，本文如实标注"计划中"的部分），对照 source/mtcp/上一篇：P2-03 TCP 状态机对照 ｜ 下一篇：P2-05 实现（上）RX/TX一句话定位libmtcp-v3 的目标：把 mTCP 的精华（每核私有、批量 I/O、批量事件）用 DPDK 24.11.6 的现代接口重写一遍，代码量控制在 mTCP 的十分之一——它是 uNOS 数据面 TCP 栈的预研，不是第二个 mTCP。先说实话：这个项目现在只有两个真实文件。Makefile 和 13 行的头文件。这正是"先定接口，再填实现"的 TDD 式开局。现状：两个真实文件的全部内容include/libmtcp_v3.h（全文，共 13 行）：#ifndef LIBMTCP_V3_H #define LIBMTCP_V3_H #include <stdint.h> int mtcp_socket(int domain, int type, int protocol); int mtcp_listen(int sockfd, int backlog); int mtcp_accept(int sockfd, void *addr, void *addrlen); int mtcp_connect(int sockfd, const void *addr, void *addrlen); int mtcp_send(int sockfd, const void *buf, int len, int flags); int mtcp_recv(int sockfd, void *buf, int len, int flags); int mtcp_close(int sockfd); #endifMakefile 声明了实现文件的清单（SRCS-y，第 6 行）：RTE_SDK ?= $(HOME)/myshare/dpdk-roadmap-v3/source/dpdk-stable-24.11.6 include $(RTE_SDK)/mk/rte.vars.mk APP = libmtcp_v3 SRCS-y = src/mtcp_socket.c src/mtcp_rx.c src/mtcp_tx.c src/mtcp_fsm.c src/mtcp_conn.c CFLAGS += -O2 -Wall -Wextra -std=c11 CFLAGS += -I$(PWD)/includeAPI 与 mTCP 的差异是刻意的：mTCP 每个函数都要传 mctx_t（mtcp_api.h:91 mtcp_socket(mctx_t, ...)）因为它支持多核多上下文；libmtcp-v3 定位单线程单上下文（uNOS 的一个 RSS worker），所以 API 就是裸 POSIX 风格——少一个参数，应用代码移植成本更低。模块设计模块（Makefile SRCS-y）职责mTCP 参照mtcp_socket.csocket/listen/accept/connect/close 封装，socket id 从 mempool 分配api.cmtcp_conn.c4-tuple 连接表（rte_hash），RX 每包查一次tcp_stream.c:62 HashFlow + fhash.cmtcp_fsm.cRFC793 简化状态机（11 态）tcp_in.c:1298mtcp_rx.crx_burst 收批 → 解析 → 查表 → fsm → 攒批 ACKdpdk_module.c:464 + tcp_in.cmtcp_tx.ccwnd 限速 + 发送缓冲 + tx_burst 攒批tcp_out.c:753 WriteTCPDataList内存模型（与 mTCP 同哲学，用 DPDK 原生设施落地）：conn 池：rte_mempool_create("conn_pool", max_concurrency, sizeof(struct conn), ...) ——对照 mTCP 的 MPCreate("flow_pool_%d", sizeof(tcp_stream), ...)（core.c:947）。每核一个池，运行时零分配。4-tuple 连接表：rte_hash_create，key = 12 字节（saddr/sport/daddr/dport，字段序对齐 mTCP EqualFlow 的 tcp_stream.c:104-107），value = conn 池索引。用 rte_hash 而不是 mTCP 的拉链表——见 P2-05。接收缓冲：定长 ring（每 conn 一个 rte_ring 太重，计划用固定 8KB 环形数组，对照 mTCP rcvbuf = 8192，sample_mtcp.conf:57）。事件队列：rte_ring 存待通知的 socket id（mTCP 用 TAILQ + 锁，我们用免锁 ring，P1-03 学的正好派上用场）。要实现的 RFC（按优先级裁剪）只列设计目标，编号是公开知识：RFC 793（状态机主体）→ RFC 1122（实现建议：延迟 ACK、Nagle 可关）→ RFC 2018（SACK 解析，先只解析不主动用）→ RFC 6298（RTO 计算，取 mTCP 简化版）→ RFC 5681（慢启动/拥塞避免/快重传，对照 mTCP tcp_in.c:447-451）。第一版明确不做：窗口缩放可配、TCP 选项里只认 MSS 和时间戳、不实现 cookie/半连接队列（理由见 P2-03）。🐧 内核对照决策点Linux v6.6mTCPlibmtcp-v3（计划）连接查找全局 ehash 带锁（tcp_hashinfo，tcp_ipv4.c:93）每核拉链 hash（fhash.c:109）每核 rte_hash（布谷鸟 + sig）状态存储struct tcp_sock 内嵌 sock，随 skb 走锁tcp_stream 从 mempool 取（core.c:947）struct conn 从 rte_mempool 取定时器每 sock 独立 timer（tcp_timer.c:666 起）时间轮批查（timer.c:384）时间轮批查（抄 mTCP）发送每包进 qdisc攒批 tx_burst（dpdk_module.c:375）攒批 tx_burst内核那一栏的作用不是"抄"，而是"不抄"：每个决策点先问"内核为什么这样"（P2-03 已答过半），再问"单核单租户下能否简化"。面试 3 问libmtcp-v3 的 API 为什么不带 mctx 参数？ → mTCP 支持多核多上下文才需要 mctx 定位每核状态（mtcp_api.h:91）；v3 定位单线程（一个 RSS worker 一个实例），上下文全局唯一，省参数的同时杜绝"传错上下文"这类 bug。conn 池为什么必须用 mempool 而不是 malloc？ → 热路径建连/断连频繁，mempool 预分配 + 每核 cache（P1-02 的机制），malloc 有锁且碎片化；mTCP 同款理由（core.c:947）。Makefile 里 SRCS-y 为什么在 .c 还不存在时就写好？ → 接口先行：先定 7 个 API 和 5 个模块边界，编译失败本身驱动实现顺序（先 socket.c 让链接过，再 conn.c……）。🔧 动手实验make -C code/libmtcp-v3 一次，把报错记录下来（预期：No rule to make target 'src/mtcp_socket.c'）。然后按依赖序实现：mtcp_socket.c（只用 mempool 分配 id）→ 编译过 → mtcp_conn.c（rte_hash 建表）→ 编译过……每一步都保持可构建。里程碑与报错日志落点 perf-data/P2/04-design-notes.md。下一篇：P2-05 · libmtcp-v3 实现（上）：RX/TX 路径与 4-tuple 查表
-
P2-05 · libmtcp-v3 实现（上）：RX/TX 路径与 4-tuple 查表 对应路线图：Phase 2 (Day 50-91) ｜ DPDK 24.11.6 LTS ｜ 内核对照 v6.6代码出处：source/dpdk-stable-24.11.6/lib/hash/（真实接口）+ code/libmtcp-v3/（骨架）+ source/mtcp/（对照实现）上一篇：P2-04 libmtcp-v3 设计 ｜ 下一篇：P2-06 实现（下）状态机与 RTO一句话定位RX/TX 路径上真正的技术含量在连接表：每包一次 4-tuple 查表，查慢了全栈都慢。这篇先把 rte_hash 的真实接口读透——它是 DPDK 里为"数据面查表"造的最称手工具。为什么弃 mTCP 的拉链表，选 rte_hashmTCP 的流表是朴素拉链法：StreamHTSearch 算 hash → TAILQ_FOREACH 遍历桶（fhash.c:109-126），hash 函数是手写的 12 字节混合（tcp_stream.c:82-94）。它能跑，但有三个问题：① 桶冲突时线性遍历，尾延迟不可控；② key 比较是全 12 字节 memcmp 语义，没短路；③ 每桶一个 cache line 但冲突链会跨行。rte_hash 的解法（lib/hash/rte_cuckoo_hash.h，真实代码）：/** * Number of items per bucket. * 8 is a tradeoff between performance and memory consumption. * When it is equal to 8, multiple 'struct rte_hash_bucket' can be fit * on a single cache line (64 or 128 bytes long) without any gaps * in memory between them due to alignment. */ #define RTE_HASH_BUCKET_ENTRIES 8 // rte_cuckoo_hash.h:102 /** Bucket structure */ struct __rte_cache_aligned rte_hash_bucket { uint16_t sig_current[RTE_HASH_BUCKET_ENTRIES]; // :139 先比签名 RTE_ATOMIC(uint32_t) key_idx[RTE_HASH_BUCKET_ENTRIES]; // :141 再取 key uint8_t flag[RTE_HASH_BUCKET_ENTRIES]; void *next; // :145 扩展桶 };两级查找：先比 16 位签名（sig）过滤绝大多数不命中的槽，签名命中才拿 key_idx 去 key_store 取 12 字节 key 做全比较。签名表紧凑到 8 槽 x 2 字节，一次加载就覆盖整桶。真实创建参数（rte_hash.h:81-90）struct rte_hash_parameters { const char *name; /**< Name of the hash. */ uint32_t entries; /**< Total hash table entries. */ uint32_t reserved; /**< Unused field. Should be set to 0 */ uint32_t key_len; /**< Length of hash key. */ rte_hash_function hash_func; /**< Primary Hash function used to calculate hash. */ uint32_t hash_func_init_val; /**< Init value used by hash_func. */ int socket_id; /**< NUMA Socket ID for memory. */ uint8_t extra_flag; /**< Indicate if additional parameters are present. */ };libmtcp-v3 计划中的 mtcp_conn.c 建表（设计稿，实现见仓库后续提交）：struct rte_hash_parameters conn_tbl_params = { .name = "conn_tbl", .entries = 1 << 17, /* 128K 连接，对齐 mTCP NUM_BINS_FLOWS=131072 */ .key_len = sizeof(struct flow_key), /* 12 字节 4-tuple */ .socket_id = rte_socket_id(), .extra_flag = 0, /* 单线程读写，无需 RW_CONCURRENCY 开销 */ }; conn_tbl = rte_hash_create(&conn_tbl_params); /* rte_hash.h:146 */extra_flag 是性能关键：RTE_HASH_EXTRA_FLAGS_RW_CONCURRENCY_LF（rte_hash.h:56）之类并发旗标都有成本，单核单线程场景全关掉——这是 mTCP"零共享锁"哲学在查表环节的等价物。查表热路径（rte_hash.h:454 / :500 / :559）int rte_hash_lookup_data(const struct rte_hash *h, const void *key, void **data); // rte_hash.h:454 int rte_hash_lookup(const struct rte_hash *h, const void *key); // rte_hash.h:500 /* 批量版：一次查 64 个 key，摊平函数调用与 cache 未命中延迟 */ int rte_hash_lookup_bulk_data(const struct rte_hash *h, const void **keys, uint32_t num_keys, int32_t *positions, void **data); // rte_hash.h:559mTCP 是一次 burst 里逐包调 StreamHTSearch（core.c:792-795 循环）。libmtcp-v3 计划用 lookup_bulk_data：把一批包的 key 指针数组收集起来一次查——把 N 次函数调用和 N 次串行 cache miss 变成一次批量流水。这是 mTCP 都没想到的 DPDK 24.11 红利。key 布局沿用 mTCP 的字段序（tcp_stream.c:104-107 的 EqualFlow 比的就是这 4 个字段）：struct flow_key { /* 计划中，12 字节，无 padding */ uint32_t saddr; /* 本端视角，同 tcp_in.c:1247-1250 */ uint16_t sport; uint32_t daddr; uint16_t dport; };RX/TX 路径总览RX（mtcp_rx.c 计划中，对照 mTCP dpdk_module.c:464 的 dpdk_recv_pkts）：rte_eth_rx_burst 收一批 → 逐包偏移到 TCP 头 → 组装 flow_key → rte_hash_lookup_data 取 conn 指针 → 未命中（SYN）走建流慢路径 → 命中则校验 seq 后进状态机（对照 tcp_in.c:1261-1298）→ ACK 攒批。TX（mtcp_tx.c 计划中，对照 mTCP dpdk_send_pkts dpdk_module.c:318）：mtcp_send 拷进 conn 的发送缓冲 → 按 min(cwnd, peer_wnd) 限速（对照 tcp_out.c:387 的 window = MIN(sndvar->cwnd, sndvar->peer_wnd)）→ mbuf 攒进 wmbufs（对照 dpdk_module.c:333）→ 攒够 rte_eth_tx_burst（对照 :375）。🐧 内核对照：同一件事，内核怎么做内核的连接表 tcp_hashinfo（tcp_ipv4.c:93）也是 hash，但桶上挂自旋锁，查找要 __inet_lookup_established（tcp_ipv4.c:1803）读锁保护，key 还有通配语义（TIME_WAIT 期间允许部分 4-tuple 重入）。rte_hash 免锁的前提是"每核私有表 + 单读者单写者"——把并发从机制上消灭，而不是用锁管理并发。 内核 ehashmTCP fhashlibmtcp-v3（计划）结构桶 + 自旋锁链TAILQ 拉链布谷鸟 8 槽桶 + sigkey 比较通配匹配（TW 复用）全 4 字段相等（fhash.c:104）全 4 字段相等 + sig 短路并发锁无（每核私有）无（每核私有）批量 API无无lookup_bulk（rte_hash.h:559）面试 3 问rte_hash 为什么先比 signature 再比 key？ → sig 是 16 位，8 槽共 16 字节一次加载即全比对（rte_cuckoo_hash.h:139）；不命中连 key_store 都不访问，省掉一次随机访存。RTE_HASH_BUCKET_ENTRIES 为什么是 8？ → 8 槽让 rte_hash_bucket 正好对齐一个 cache line，无空隙（rte_cuckoo_hash.h:95-101 注释原文）；4 槽省内存但多冲突，16 槽跨行。什么时候该关掉 rte_hash 的并发旗标？ → 单核单读者单写者时。extra_flag 里的 RW_CONCURRENCY 等旗标要维护读锁/序号（rte_hash.h:34-56），全关掉就是免锁最快路径——libmtcp-v3 的每核私有表正好满足。🔧 动手实验写一个 12 字节 4-tuple 的 rte_hash 微基准：100 万 key 全命中查找，对比 ① 逐包 rte_hash_lookup_data ② 批量 rte_hash_lookup_bulk_data（64/批）③ mTCP 的 fhash 同规模查表（把 fhash.c/tcp_stream.c 的 hash 函数抽出来单测）。记录 cycles/key 与 cache-miss/key（perf stat -e cache-misses），数据落点 perf-data/P2/05-hash-bench.md。下一篇：P2-06 · libmtcp-v3 实现（下）：状态机、RTO 与 cwnd 简化版
-
P2-06 · libmtcp-v3 实现（下）：状态机、RTO 与 cwnd 简化版 对应路线图：Phase 2 (Day 50-91) ｜ DPDK 24.11.6 LTS ｜ 内核对照 v6.6.143代码出处：source/mtcp/mtcp/src/timer.c、tcp_in.c（真实实现）+ source/linux-stable/net/ipv4/tcp_timer.c、tcp_cong.c（对照）+ code/libmtcp-v3/（计划中）上一篇：P2-05 实现（上）RX/TX ｜ 下一篇：P2-07 性能调优实录一句话定位状态机决定"包往哪走"，RTO 决定"丢了怎么办"，cwnd 决定"发多快"。libmtcp-v3 的取舍是：状态机抄 mTCP 的 switch，定时器抄 mTCP 的时间轮，拥塞控制只做 Reno 主干——先跑通，再谈 RACK/BBR。mTCP 的 RTO：一个公式 + 指数退避mTCP 没有每流定时器，所有待重传流挂时间轮，主循环每轮扫到期槽（timer.c:384-441，P2-02 的 ④）。到期后进 HandleRTO：HandleRTO(mtcp_manager_t mtcp, uint32_t cur_ts, tcp_stream *cur_stream) { // timer.c:183 uint8_t backoff; // ... /* count number of retransmissions */ if (cur_stream->sndvar->nrtx < TCP_MAX_RTX) { cur_stream->sndvar->nrtx++; // timer.c:201-202 } else { /* if it exceeds the threshold, destroy and notify to application */ // ... state = TCP_ST_CLOSED; RaiseErrorEvent / DestroyTCPStream return ERROR; // timer.c:203-220 } /* update rto timestamp */ if (cur_stream->state >= TCP_ST_ESTABLISHED) { uint32_t rto_prev; backoff = MIN(cur_stream->sndvar->nrtx, TCP_MAX_BACKOFF); rto_prev = cur_stream->sndvar->rto; cur_stream->sndvar->rto = ((cur_stream->rcvvar->srtt >> 3) + cur_stream->rcvvar->rttvar) << backoff; // timer.c:229-233 // ... } else if (cur_stream->state >= TCP_ST_SYN_SENT) { /* if there is no rtt measured, update rto based on the previous one */ if (cur_stream->sndvar->nrtx < TCP_MAX_BACKOFF) { cur_stream->sndvar->rto <<= 1; // timer.c:240-244 } } /* reduce congestion window and ssthresh */ cur_stream->sndvar->ssthresh = MIN(cur_stream->sndvar->cwnd, cur_stream->sndvar->peer_wnd) / 2; // timer.c:249 if (cur_stream->sndvar->ssthresh < (2 * cur_stream->sndvar->mss)) { cur_stream->sndvar->ssthresh = cur_stream->sndvar->mss * 2; // :250-252 } cur_stream->sndvar->cwnd = cur_stream->sndvar->mss; // :253三个要点：① rto = (srtt>>3 + rttvar) << backoff 是 RFC 6298 的一元简化（srtt 存 8 倍定点数，>>3 还原）；② 重传次数到 TCP_MAX_RTX 直接销毁连接——不做内核的"路由失效探测"；③ 超时减窗一句话：ssthresh 砍半（下限 2MSS），cwnd 回到 1MSS。mTCP 的快重传：三重复 ACK（tcp_in.c:417-473）ProcessACK（tcp_in.c:310）里数 dup_acks，到 3 就动手： /* Fast retransmission */ if (dup && cur_stream->rcvvar->dup_acks == 3) { // tcp_in.c:417 // ... if (TCP_SEQ_LT(ack_seq, cur_stream->snd_nxt)) { // ... cur_stream->snd_nxt = ack_seq; // 回退发送指针 :441 } /* update congestion control variables */ /* ssthresh to half of min of cwnd and peer wnd */ sndvar->ssthresh = MIN(sndvar->cwnd, sndvar->peer_wnd) / 2; // :447 if (sndvar->ssthresh < 2 * sndvar->mss) { sndvar->ssthresh = 2 * sndvar->mss; } sndvar->cwnd = sndvar->ssthresh + 3 * sndvar->mss; // :451 // ... AddtoSendList(mtcp, cur_stream); // 立即重传 :464 } else if (cur_stream->rcvvar->dup_acks > 3) { /* Inflate congestion window until before overflow */ if ((uint32_t)(sndvar->cwnd + sndvar->mss) > sndvar->cwnd) { sndvar->cwnd += sndvar->mss; // :466-473 } }🐧 内核对照：同一件事的完整版定时器侧：内核没有"时间轮统一扫"，而是每 sock 一个 write timer，tcp_write_timer_handler 按 icsk_pending 分派四类事件（tcp_timer.c:666-698）：REO_TIMEOUT（RACK 乱序超时）、LOSS_PROBE（尾丢探测）、RETRANS（重传，进 tcp_retransmit_timer tcp_timer.c:511）、PROBE0（零窗探测）。tcp_retransmit_timer 的真实行为（tcp_timer.c:511 起）：!tp->packets_out 直接返回（:531）→ 零窗时转 PROBE0（:538-573）→ tcp_write_timeout 判超时死亡（:576）→ tcp_enter_loss(sk)（:600）→ tcp_retransmit_skb 重传队头（:603）→ 失败则按 TCP_RESOURCE_PROBE_INTERVAL 节流重试（:607-609）→ 最后 inet_csk_reset_xmit_timer(..., TCP_RTO_MAX) 夹上限（:656-657）。mTCP 的 30 行，内核用了 150 行——多出来的都是状态机：零窗、loss recovery、资源节流。拥塞控制侧：内核是插件化（struct tcp_congestion_ops），Reno 只是 fallback（tcp_cong.c:532 struct tcp_congestion_ops tcp_reno）。三个真实函数：__bpf_kfunc u32 tcp_slow_start(struct tcp_sock *tp, u32 acked) { u32 cwnd = min(tcp_snd_cwnd(tp) + acked, tp->snd_ssthresh); acked -= cwnd - tcp_snd_cwnd(tp); tcp_snd_cwnd_set(tp, min(cwnd, tp->snd_cwnd_clamp)); return acked; // tcp_cong.c:457-465 } __bpf_kfunc void tcp_cong_avoid_ai(struct tcp_sock *tp, u32 w, u32 acked) { if (tp->snd_cwnd_cnt >= w) { tp->snd_cwnd_cnt = 0; tcp_snd_cwnd_set(tp, tcp_snd_cwnd(tp) + 1); // tcp_cong.c:474-477 } tp->snd_cwnd_cnt += acked; // 每 ACK 记学分 :479 // ... } __bpf_kfunc u32 tcp_reno_ssthresh(struct sock *sk) { // ... return max(tcp_snd_cwnd(tp) >> 1U, 2U); // tcp_cong.c:520 }慢启动按 acked 字节加窗（还处理 stretch ACK，tcp_cong.c:448-456 注释）；拥塞避免用 snd_cwnd_cnt 学分制实现"每 RTT +1"；丢包减半在 tcp_reno_ssthresh。mTCP 直接 cwnd += MSS（每包），是"每 ACK 一个 MSS"的粒度放大版。libmtcp-v3（mtcp_fsm.c 计划中）的取舍清单状态机：照抄 mTCP 的 11 态 switch 结构（tcp_in.c:1298 布局），handler 全部 static inline；定时器：时间轮 + 每轮批查（抄 timer.c:384 的 CheckRtmTimeout 模式），不做内核的每流 timer；RTO：(srtt>>3 + rttvar) << backoff（timer.c:232 原式），SYN 阶段 rto <<= 1（timer.c:243）；快重传：三重复 ACK 触发（tcp_in.c:417），cwnd = ssthresh + 3MSS（tcp_in.c:451）；明确不做：RACK/Probe0/SACK 主动恢复/PRR——第一版目标是"和 mTCP 行为等价"，内核的完整版是 P3+ 的课题。面试 3 问mTCP 的 RTO 公式 (srtt>>3 + rttvar) << backoff 里 >>3 是什么？ → srtt 存的是 8 倍定点数（3 位小数位），>>3 还原成真实值；backoff 是重传次数的指数退避（timer.c:229-233）。内核为什么需要 LOSS_PROBE 事件而 mTCP 不需要？ → 尾丢场景（发了一批丢最后几个）RTO 触发太慢，内核用 TLP 提前探测（tcp_timer.c:687-688）；mTCP 的简化模型里这类优化不存在，代价是尾丢恢复慢一个 RTO。三重复 ACK 后为什么 cwnd = ssthresh + 3MSS？ → 3 个 dupack 证明有 3 个包已离开网络，加 3MSS 补偿这 3 个"已确认离网"的段（tcp_in.c:451），对应 RFC 5681 的 fast recovery 简化。🔧 动手实验用 tc netem 给测试对端注入 5%/10% 丢包，跑 mTCP 的 epserver/epwget 大文件传输，tcpdump 抓重传：① 验证快重传（3 dupack 触发，重传包 seq 连续）；② 验证 RTO 指数退避（重传间隔 1x/2x/4x）；③ 对照内核 iperf3 同丢包率下的恢复曲线。抓包与时间线落点 perf-data/P2/06-rto.md。下一篇：P2-07 · 性能调优实录：从 perf top 到单核 14.88 Mpps
-
P2-07 · 性能调优实录：从 perf top 到单核 14.88 Mpps 对应路线图：Phase 2 (Day 50-91) ｜ DPDK 24.11.6 LTS ｜ 内核对照 v6.6工具出处：source/dperf-main/（压测）+ perf 工具链（P0-05 所学）上一篇：P2-06 实现（下）状态机与 RTO ｜ 下一篇：P3-01 OVS-DPDK 数据面一句话定位调优不是玄学，是闭环：perf top 找热点 → 火焰图看调用链 → perf c2c 查伪共享 → 批量化改代码 → dperf 压测验证。每轮只改一个变量。本文是 P2 收尾的方法论 + dperf 实操手册；14.88 Mpps（10G 64 字节线速）是阶段目标，实测数据随调优进度补进 perf-data/P2/07/。压测工具：dperf 的真实用法dperf（source/dperf-main/）是百度开源的 DPDK 流量发生器。它的入口流程（src/main.c:56-86）很短：int main(int argc, char **argv) { // ... if (config_parse(argc, argv, &g_config) < 0) { // main.c:60 return 1; } // ... if (dpdk_init(&g_config, argv[0]) < 0) { // main.c:76 printf("dpdk init fail\n"); return 1; } dpdk_run(lcore_main, NULL); // main.c:81 // ... }命令行只认 -c/--conf 配置文件（config.c:1730）。README 给了一个非常有用的参考系（README.md 实测，100G E810 双口）：单核 16.8 Mpps、6 核 105.2 Mpps、12 核 204.6 Mpps；HTTP CPS 单核 400 万。这意味着在 10G 网卡上"单核线速"（14.88 Mpps）是 dperf 远没到极限的工况——压测工具必须比被测对象强，先确认这一点。flood 压测的真实配置（test/performance/tx-pps/flood-1.conf，全文）：mode client cpu 0 slow_start 30 tx_burst 128 launch_num 10 payload_size 1 duration 10d protocol udp flood cc 16k cps 1k keepalive 1ms #port pci addr gateway port 0000:5e:00.1 6.6.234.4 6.6.234.1 # addr_start num client 6.6.234.4 1 # addr_start num server 6.6.213.4 1 # port_start num listen 80 1注意 tx_burst 128：dperf 自己就用大 burst，验证了"批量化是第一优先级"（对照 P1-05 的 ixgbe RDT 攒批与 dpdk_module.c:375 的 tx_burst）。方法论四步（每步配一条真实命令）① perf top 找热点：perf top -C 2 -d 1 钉住数据面 lcore 2，看谁烧 CPU。常见三兄弟：rte_eth_rx_burst（说明收包是瓶颈，查 batch 与 mempool cache）、查表函数（说明 hash 太散，见 P2-05）、memcpy（说明拷包太多，该改零拷贝）。② 火焰图看调用链：perf record -g -F 999 -- ./app + FlameGraph 脚本出 SVG。找"宽度异常"的调用路径——比如状态机 handler 里藏着日志/断言（mTCP 的 TRACE_* 宏链），宽度即成本。③ perf c2c 查伪共享：perf c2c record + perf c2c report --stats。HitM 高的相邻字段就是伪共享——P1-03 的 RTE_CACHE_GUARD（rte_ring_core.h:116 附近）就是为这类问题准备的。多核下伪共享的杀伤力大于任何算法优化。④ 批量化改代码：burst 放大（32→128）、ACK 攒批（对照 mTCP ACK_OPT_AGGREGATE，tcp_in.c:924）、批量查表（rte_hash_lookup_bulk_data，rte_hash.h:559）、批量 free mbuf（dpdk_module.c:444-447 的 free 循环是反面教材——rte_pktmbuf_free 有批量版 rte_pktmbuf_free_bulk，热路径少一次循环开销）。每次只改一个，改完回到 ⑤。⑤ dperf 验证：./dperf -c test/performance/tx-pps/flood-1.conf（对端跑 server 配置），每秒输出长这样（README.md 节选）：seconds 22 cpuUsage 52 pktRx 3,001,058 pktTx 3,001,025 bitsRx 2,272,799,040 bitsTx 1,920,657,600 dropTx 0 ierrors 0 oerrors 0 imissed 0三个数字看三件事：pktRx 是否达到 14.88M × 秒数、dropTx 是否非零（发送侧丢包）、imissed 是否非零（网卡丢包，通常是 burst 太短或 CPU 被抢占）。三者全绿才算数。为什么目标定 14.88 Mpps10G 线速小包：10^10 bit/s ÷ (64+12+8) byte ÷ 8 bit = 14,880,952 pps。P1-05 的结论是"内核单核百万级 PPS，DPDK 单核可达线速"，P2 的目标就是亲手把这个结论复现到 libmtcp-v3 的 RX 路径上。参考系：dperf README 在 100G 上单核 16.8 Mpps（README.md PPS 表），说明 DPDK 单核收包能力在 10G 上留有 10 倍余量——我们的瓶颈只会在自己的代码里。🐧 内核对照同一套 perf 工具看内核侧：perf top -C <软中断核> 会看到 tcp_v4_rcv（tcp_ipv4.c:1999）、__inet_lookup_established（:1803）等——软中断预算（budget）把单核 PPS 锁在百万级，这是 P0-07/P1-05 已经验证过的基线。调优 DPDK 路径时，同一份数据也可以丢进内核对照表：同样的热点，两种解法。面试 3 问perf c2c 报告里 HitM 高说明什么？ → 两个核心反复无效化对方的同一 cache line（伪共享）；解法是把热点字段拆分到独立 cache line（P1-03 的 RTE_CACHE_GUARD 范式）。为什么压测工具（dperf）必须比被测对象强？ → 否则瓶颈在工具上，测出来的曲线是工具的曲线；dperf 单核 16.8 Mpps（README.md）远超 10G 线速 14.88 Mpps，才有资格压测 10G 数据面。burst 从 32 加到 128 为什么通常能提速？ → 均摊每次 burst 的固定成本（函数调用、描述符回写、寄存器访问）；P1-05 的 RDT 攒批（ixgbe_rxtx.c:1965 附近）与 dperf tx_burst 128 是同一原理。🔧 动手实验流程：① 建 libmtcp-v3 的 RX-only 最小程序（P2-04/05 的骨架），先跑通 flood 收发；② 按四步法逐轮调优，每轮记录 perf top 采样 + dperf 输出到 perf-data/P2/07/（命名 round-N-*.txt）；③ 达到或逼近 14.88 Mpps 后，把同机型上内核 iperf3 的 PPS 基线补进对照表。未达标时的检查清单按 ①②③④ 顺序走一遍，不要在没数据的情况下改代码。上一篇：P2-06 · libmtcp-v3 实现（下）：状态机、RTO 与 cwnd 简化版
-
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: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 的循环条件，回答"全部连接关闭后主循环为什么退出"。下一篇：P2-02 · mTCP 源码架构：core/tcp_in/eventpoll 三个入口
-
P2-02 · mTCP 源码架构：core/tcp_in/eventpoll 三个入口 对应路线图：Phase 2 (Day 50-91) ｜ DPDK 24.11.6 LTS ｜ 内核对照 v6.6代码出处：source/mtcp/mtcp/src/，引用均标 文件:行号上一篇：P2-01 mTCP 论文精读 ｜ 下一篇：P2-03 TCP 状态机对照一句话定位mTCP 整个栈可以压缩成一句话：一个 while 循环扮演"用户态软中断"，每轮做九件事。看懂 RunMainLoop，就懂了 mTCP 的全部调度哲学。注：本仓库的 mTCP 是 fork 版本，入口叫 RunMainLoop（core.c:762），由 MTCPRunThread（core.c:1153）拉起；上游旧版叫 mtcp_run_event_loop，职责相同。入口一：core.c 主循环（RunMainLoop 九步）static void RunMainLoop(struct mtcp_thread_context *ctx) // core.c:762 { mtcp_manager_t mtcp = ctx->mtcp_manager; // core.c:764 // ... while ((!ctx->done || mtcp->flow_cnt) && !ctx->exit) { // core.c:776 // ... gettimeofday(&cur_ts, NULL); mtcp->cur_ts = TIMEVAL_TO_TS(&cur_ts); // ① 取时间戳 :781-783 for (rx_inf = 0; rx_inf < CONFIG.eths_num; rx_inf++) { recv_cnt = mtcp->iom->recv_pkts(ctx, rx_inf); // ② 批量收包 :789 for (i = 0; i < recv_cnt; i++) { pktbuf = mtcp->iom->get_rptr(mtcp->ctx, rx_inf, i, &len); if (pktbuf != NULL) ProcessPacket(mtcp, rx_inf, ts, pktbuf, len); // ③ :795 } } if (mtcp->flow_cnt > 0) { CheckRtmTimeout(mtcp, ts, CONFIG.max_concurrency); // ④ 定时器 :824 CheckTimewaitExpire(mtcp, ts, CONFIG.max_concurrency); // :825 // ... } if (mtcp->ep) { FlushEpollEvents(mtcp, ts); // ⑤ 批量事件 :834 } if (mtcp->flow_cnt > 0) { HandleApplicationCalls(mtcp, ts); // ⑥ 应用调用 :839 } WritePacketsToChunks(mtcp, ts); // ⑦ 写发送块 :842 for (tx_inf = 0; tx_inf < CONFIG.eths_num; tx_inf++) mtcp->iom->send_pkts(ctx, tx_inf); // ⑧ 批量发送 :847 mtcp->iom->select(ctx); // ⑨ 空闲才睡 :860 } }两个最关键的细节：① ④⑤⑥⑦的顺序不能乱——先查超时（重传/回收），再刷事件（应用才能看到新数据），再消费应用攒下的调用（connect/send/close），最后才写发送块，保证应用视角一致性；② ⑨ 的 select 是"没活干才睡"——有包收就不睡（这正是 P1-05 说的"把中断换成轮询"），但流空闲时也让出 CPU，避免空转烧核。入口二：tcp_in.c 状态机（每包都过这里）ProcessPacket（eth_in.c:9）按以太类型分发：ETH_P_IP → ProcessIPv4Packet，最终落到 ProcessTCPPacket（tcp_in.c:1205）：int ProcessTCPPacket(mtcp_manager_t mtcp, uint32_t cur_ts, const int ifidx, const struct iphdr *iph, int ip_len) { // tcp_in.c:1205 struct tcphdr* tcph = (struct tcphdr *) ((u_char *)iph + (iph->ihl << 2)); uint8_t *payload = (uint8_t *)tcph + (tcph->doff << 2); int payloadlen = ip_len - (payload - (u_char *)iph); // ... s_stream.saddr = iph->daddr; // 注意：4-tuple 是"本端视角" s_stream.sport = tcph->dest; // 与网卡方向相反 s_stream.daddr = iph->saddr; s_stream.dport = tcph->source; // tcp_in.c:1247-1250 if (!(cur_stream = StreamHTSearch(mtcp->tcp_flow_table, &s_stream))) { /* not found in flow table */ cur_stream = CreateNewFlowHTEntry(mtcp, cur_ts, iph, ip_len, tcph, seq, ack_seq, payloadlen, window); // tcp_in.c:1252-1258 } /* Validate sequence. if not valid, ignore the packet */ if (cur_stream->state > TCP_ST_SYN_RCVD) { ret = ValidateSequence(mtcp, cur_stream, cur_ts, tcph, seq, ack_seq, payloadlen); // tcp_in.c:1261-1263 } // ... switch (cur_stream->state) { // tcp_in.c:1298 状态分发 case TCP_ST_LISTEN: Handle_TCP_ST_LISTEN(mtcp, cur_ts, cur_stream, tcph); break; case TCP_ST_ESTABLISHED: Handle_TCP_ST_ESTABLISHED(mtcp, cur_ts, cur_stream, tcph, seq, ack_seq, payload, payloadlen, window); break; // ... 共 11 个状态分支，逐状态对比见 P2-03 } }流表是每核私有的拉链 hash：StreamHTSearch 就是算 hash 下标 + TAILQ_FOREACH 遍历桶（fhash.c:109-126），hash 函数 HashFlow 对 12 字节 4-tuple 做 Jenkins 风格混合后 & (NUM_BINS_FLOWS - 1)（tcp_stream.c:82-94，13 万桶）。入口三：eventpoll.c 事件桥（应用线程的接口）应用线程不碰包路径，只调 mtcp_epoll_wait（eventpoll.c:363）等事件。栈线程侧只做入队 AddEpollEvent（eventpoll.c:569）：inline int AddEpollEvent(struct mtcp_epoll *ep, int queue_type, socket_map_t socket, uint32_t event) { // eventpoll.c:569 if (socket->events & event) { return 0; /* 同一事件只入队一次 */ } if (queue_type == MTCP_EVENT_QUEUE) { eq = ep->mtcp_queue; /* 栈线程 → mtcp_queue */ } else if (queue_type == USR_EVENT_QUEUE) { eq = ep->usr_queue; /* 应用线程 → usr_queue */ } index = eq->end++; socket->events |= event; eq->events[index].sockid = socket->id; // eventpoll.c:604-609 }状态机在关键跃迁点调 RaiseReadEvent/RaiseWriteEvent/RaiseErrorEvent（tcp_stream.c:125/146/198），它们内部就是 AddEpollEvent(..., MTCP_EVENT_QUEUE, ...)。然后主循环 ⑤ 统一 flush（core.c:461-472 把 mtcp_queue 搬进 usr_queue）+ 单次 pthread_cond_signal（core.c:483）。这是"批量事件"的完整闭环。🐧 内核对照环节Linux v6.6mTCP收包循环软中断 net_rx_action（budget 限流）→ tcp_v4_rcv（tcp_ipv4.c:1999）RunMainLoop 每轮 burst（core.c:789），无预算连接查找__inet_lookup_established 全局 ehash（tcp_ipv4.c:1803）每核私有 fhash（fhash.c:109）空闲行为NAPI 空闲后重新开中断iom->select 睡眠（core.c:860）面试 3 问RunMainLoop 九步顺序为什么是"超时→事件→应用调用→发送"？ → 超时先处理保证重传/回收优先；事件在应用调用之前刷，应用读到最新状态；发送放最后让本轮的 ACK/重传/新数据一起进发送块（core.c:824-847 行序）。ProcessTCPPacket 的 4-tuple 为什么是"反的"？ → 流表 key 是本端视角：收到的包 saddr=对端，所以存表时 saddr 取 iph->daddr（tcp_in.c:1247-1250）。mTCP 是纯轮询吗？ → 不是：有包收就转（core.c:776 循环），无流无包时 iom->select 让出 CPU（core.c:860），是"轮询 + 可选睡眠"的混合模型。🔧 动手实验在 source/mtcp/ 按 autotools 流程构建（README.md/README.config 有 DPDK 路径配置说明），跑 apps/example/epserver -f epserver.conf + epwget（配置模板 config/sample_mtcp.conf：io = dpdk、port = dpdk0、max_concurrency = 10000）。用 gdb 在 RunMainLoop 每步各打一个断点，统计 1 秒内各断点命中次数——"九个动作的负载画像"。数据落点 perf-data/P2/02-eventloop.md。下一篇：P2-03 · 🐧 对照：mTCP 与内核 TCP 状态机逐状态对比
· 第 1/1 页 · 本页 7 条 · 共 7 条