BPF CPU Usage High issue

Objective

Problem Statement

https://docs.google.com/document/d/1HlvGBoT8gL3LToCIB8KH88EG4toh7YiiQnNApNyosOo/edit

https://docs.google.com/document/d/1ibjJWueVClKet0by0fWbFHz2vEfj3viL5ss8byJuuA4/edit#heading=h.ubx3xrz6e41r

We met the bpf cpu high issue many times after the cilium conntrack table was full. It impacts the L4/L7 traffic reliability and also impacts the reliability confidence about cilium and the cilium rollout on tlb/gateway nodes.

We have taken some measures to try to avoid the conntrack table from getting full. However, if the load further increases or if the garbage collection is delayed for some reason, the conntrack table can still become full, which will trigger this issue. Therefore, we aim to address this problem fundamentally.

The disk-quota controller is a Kubernetes component that manages disk quotas for various resources in a Kubernetes cluster, including:

1. emptyDir volumes
2. Container root directories
3. Container log directories

网络问题是线上故障中最难定位的一类。症状千变万化——P99 延迟突然抖动、某个服务间歇性超时、容器之间偶发丢包——而根因可能藏在协议栈的任何一层：网卡驱动的 ring buffer 溢出、内核 backlog 队列打满、TCP 重传引发的滑动窗口收缩、iptables 规则误命中，乃至 NUMA 拓扑导致的中断不均衡。本文是本系列第十篇，聚焦于工具链与实战：从 ss 的每个输出字段到 bpftrace 脚本，从 /proc/net 的原始数字到三个完整的排查案例，构建一套系统化的网络诊断方法论。

在前几篇的基础上，本文聚焦于 Linux 网络栈中性能极限的挖掘：从硬件卸载、多队列扩展，到内核旁路（Kernel Bypass）技术，再到发送路径的零拷贝优化，最后落地到实际的诊断工具链。所有代码片段均取自 Linux 6.4-rc1 源码树，并附有源文件路径与行号，供读者对照阅读。

容器网络是现代云原生基础设施的底座。Docker、Kubernetes 依赖 Linux 内核提供的四大网络虚拟化原语——Network Namespace、veth pair、Linux Bridge、VXLAN——把跑在同一台物理机或跨越多台主机的容器连接成一张逻辑网络。本文基于 Linux 6.4-rc1 源码，逐层拆解这四个模块的内核实现，并在最后串联出一条完整的容器间数据包路径。

在前六篇中，我们依次拆解了 sk_buff 生命周期、网卡驱动收发路径、TCP/IP 协议栈、路由子系统、套接字层以及 NAPI/GRO 机制。本篇聚焦数据包过滤与处理的核心框架：Netfilter hook 体系、nftables 规则执行引擎、conntrack 连接追踪，以及近年来高速演进的 eBPF 网络程序（XDP、tc BPF、Socket Filter）。所有代码片段均源自 Linux 6.4-rc1。

Socket 是用户态程序与内核网络协议栈之间的唯一接口。它不仅是一个文件描述符，更是一套精心设计的多层抽象体系——从 VFS 层的 struct socket，到协议无关的 struct sock，再到 IPv4 专用的 struct inet_sock 和 TCP 专用的 struct tcp_sock，每一层都有其清晰的职责边界。本文基于 Linux 6.4-rc1 源码，深入剖析 socket 系统调用的完整实现路径、epoll 的内核机制，以及缓冲区管理与内存压力控制。

本系列前五篇分别覆盖了网卡驱动收发、NAPI、协议栈 IP/TCP 层、路由子系统和 netfilter，这一篇聚焦于最接近用户态的 socket 接口层，梳理从系统调用入口到数据进出内核缓冲区的全链路，并以 epoll 的内部实现为重点，阐释高并发服务器底层事件通知的工作机制。

TCP 拥塞控制是互联网稳定运行的核心机制之一。自 1988 年 Van Jacobson 在 SIGCOMM 发表奠基论文以来，拥塞控制算法经历了从 Tahoe、Reno、BIC 到 CUBIC，再到基于测量的 BBR 的演进历程。本文以 Linux 6.4-rc1 源码为基础，深入剖析内核拥塞控制框架的实现细节，覆盖从插件注册到状态机转换、从 CUBIC 三次函数到 BBR 带宽估计的完整链路。

拥塞控制算法面对的核心挑战是：如何在不知道网络容量的前提下，以尽可能高的速率发送数据，同时不引发严重拥塞？这个问题的本质是分布式资源竞争——互联网中每条流都是自私的，拥塞控制协议需要在个体利益（最大化自身吞吐）和集体利益（网络整体公平稳定）之间取得平衡。Jacobson 的原始方案用丢包作为拥塞的唯一信号，这在当时（网络带宽以 Kbps 计）是合理的。但随着网络带宽扩展到 Gbps、Tbps 量级，以及 bufferbloat（路由器缓冲区过大导致的延迟膨胀）问题的出现，基于丢包的方案暴露出越来越多的局限性，催生了 CUBIC 和 BBR 等新一代算法的诞生。

TCP 是互联网的基石协议，其可靠性、有序性和流量控制能力建立在一套精密的状态机和连接管理机制之上。本文基于 Linux 6.4-rc1 内核源码，深入剖析 TCP 协议栈从数据结构设计、三次握手、数据收发，到四次挥手和 TIME_WAIT 的完整生命周期，并给出实用的内核级诊断工具链。

IP 层（网络层）是 Linux 协议栈的核心，负责报文的寻址、路由、转发与分片重组。本文基于 Linux 6.4-rc1 源码，从 ip_rcv 入口函数出发，逐层拆解接收路径、FIB 路由查找、发送路径、分片重组和 netfilter 钩子的完整实现，并给出实用的内核诊断技巧。文中所有代码均来自 net/ipv4/ip_input.c、net/ipv4/ip_output.c、net/ipv4/fib_trie.c、net/ipv4/ip_fragment.c、net/ipv4/ip_forward.c 和 net/netfilter/core.c 等实际文件。