直接回答：收包路径：网卡 DMA 把包写入环形缓冲区（ring buffer）→ 触发硬中断 → 内核调度软中断（NET_RX）由 NAPI 轮询批量收包（避免每包一中断的中断风暴）→ 协议栈逐层处理（IP 路由/netfilter、TCP 重组与确认）→ 放入 socket 接收队列 → 唤醒等待的进程 → 应用 read()/recvfrom 拷贝到用户态。零拷贝发送有 sendfile/splice，接收侧主流仍是拷贝（除非 AF_XDP/io_uring 注册缓冲）。

展开解析：瓶颈地图：小包高 PPS 场景第一瓶颈是软中断处理（单核打满，看 /proc/softirqs 分布），对策是 RSS 多队列把流散到多核 + RPS/XPS 软件分流 + IRQ 亲和性绑定；netfilter 规则（iptables 长链、conntrack 表满——K8s NodePort 的经典坑）是隐形杀手，大规模部署用 IPVS/eBPF 绕过；socket 缓冲不足丢包看 netstat -s 的 listen overflow 与 TCPExt；应用侧瓶颈是唤醒与拷贝开销——epoll 边缘触发配合非阻塞读循环榨干每次系统调用，io_uring 把 syscall 次数再砍一档。观测工具链：ethtool -S 看网卡层丢包（ring 满）、dropwatch 找内核丢包点、ss -i 看单连接状态。调优清单：ring buffer 调大、GRO/LRO 合并、中断合并（interrupt coalescing）、NUMA 本地性（网卡中断绑到同 NUMA 的核）。云主机还有一层虚拟化开销（virtio/vhost），同规格裸金属与虚机 PPS 上限差数倍属正常。

追问方向：NAPI 的权重与预算机制是什么？XDP/eBPF 能把收包提前到哪一层？

（约 500 字）