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-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-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 查表