工作窃取是用户态线程级任务调度策略，用于平衡多网卡通道下解包等计算密集型负载；需嵌入“取包→解包→处理”软件流水线，结合多队列采集、per-CPU任务队列、反馈式节奏调控与RFS亲和性优化。
工作窃取（Work-Stealing）本身不直接作用于网卡硬件或数据包收发路径，它是一种**用户态线程级的任务调度策略**，适用于解包、协议解析、业务逻辑处理等计算密集型阶段。要在自研网络通信组件中“优雅平衡多网卡通道的解包计算节奏”，关键不是让工作窃取去调度网卡中断或DMA，而是把它嵌入到**从网卡队列取包 → 解包 → 处理**这一软件流水线的计算层，与多网卡、多队列、多CPU核协同设计。
明确职责边界：网卡收包与计算解耦
真正的“并发数据包来源”来自多个网卡及其各自接收队列（如 eth0-rx-0、eth1-rx-0）。建议先完成底层分流：
- 启用硬件 RSS 或 RPS，确保不同网卡/不同流的数据包已分散到多个 CPU 核的软中断上下文（NET_RX_SOFTIRQ）
- 每个核绑定一个专用的“包采集线程”，负责轮询本核对应网卡队列（如通过 AF_XDP、io_uring 或传统 recvfrom），将原始数据包（含 metadata）推入本地无锁环形缓冲区（per-CPU ring buffer）
- 避免跨核搬运包数据——本地采集、本地入队、本地后续处理，减少 cache line bouncing
构建带窃取能力的解包任务池
解包不是原子操作：可能包含校验和验证、头部解析、TLS 拆帧、序列号重组、反序列化等子步骤。可将其建模为轻量级任务（PacketTask）：
- 每个 CPU 核维护一个双端队列（Deque）作为本地任务队列，由专属解包线程（Worker Thread）持续 pop_front 执行
- 当某核本地队列为空，且检测到其他核队列长度 > 阈值（如 ≥ 8），则尝试对目标核队列执行 pop_back ——这就是“窃取”
- 使用 C++17 std::deque + atomic size_hint / 原子计数器实现低开销窃取探测，避免锁竞争
- 任务对象应携带来源网卡 ID、接收时间戳、所属流哈希（用于 RFS 亲和性回填），便于后续路由或限速决策
节奏控制：用反馈机制调节采集与解包吞吐差
“解包计算节奏”失衡常表现为：采集太快导致本地队列积压（OOM 风险），或解包太慢拖垮端到端延迟。需闭环调控：
- 每个 Worker 线程周期性上报自身队列水位、平均处理耗时、丢包数（如因超时被丢弃）
- 全局协调器（可无状态）根据各核指标动态调整采集线程行为：水位高则降低 poll 频率或触发背压信号；耗时突增则暂停向该核推送新任务
- 对高优先级流量（如心跳、控制帧），支持任务标记 + 插入本地队列头部（push_front），保障低延迟，不参与窃取
与网卡通道协同的关键细节
所谓“多网卡通道”，不只是物理存在，更需在语义上可区分：
- 为每张网卡分配独立的 Worker 线程组（例如 eth0 → worker0~3，eth1 → worker4~7），再在组内启用工作窃取——既保留通道隔离性（故障域分离），又允许组内弹性伸缩
- 若某网卡突发流量远超其余通道，其本地任务队列会快速膨胀，窃取者优先从该队列尾部取任务，天然形成“溢出卸载”，无需中心调度器介入
- 结合 RFS（Receive Flow Steering），将同一 TCP 流的后续包尽量送回上次解包的 CPU 核，使 task 对象中的流上下文（如滑动窗口状态）更可能命中 L3 缓存，提升窃取后的执行效率
不复杂但容易忽略：工作窃取解决的是“计算负载不均”，不是“IO 负载不均”。务必先做好网卡多队列分发、中断亲和性绑定、零拷贝内存池等基础设施，再把窃取用在刀刃上——解包这个纯 CPU 的环节。
