3. 硬中断与软中断的区别：上半部与下半部机制，以及为什么软中断是性能瓶颈

在 Linux 网络协议栈中，中断处理被明确划分为两个阶段：上半部（硬中断） 和 下半部（软中断）。这种设计是为了在“快速响应硬件”与“灵活处理复杂逻辑”之间取得平衡。然而，正是这种机制，使得软中断在高并发收包场景下成为主要的性能瓶颈。

3.1 上半部（硬中断）：快速响应，最小化处理

当网卡（NIC）接收到数据包时，会通过 PCIe 总线向 CPU 发送一个硬件中断信号。CPU 立即暂停当前任务，执行中断服务程序（ISR, Interrupt Service Routine）。

• 核心目标：以最快的速度确认中断，并通知内核有数据需要处理。
• 典型操作：保存寄存器上下文、读取网卡中断状态寄存器、清除中断标志位、将数据包从硬件 FIFO 拷贝到内核缓冲区（sk_buff）、最后触发软中断。
• 关键约束：硬中断执行期间，当前 CPU 上的所有其他中断都会被屏蔽（或部分屏蔽）。因此，ISR 必须执行得极快，通常只做最必要的“脏活”，将耗时操作推迟到下半部。

3.2 下半部（软中断）：重负荷处理，可抢占

软中断是内核为处理那些“可以稍后执行”的任务而设计的机制。在网络收包路径中，NET_RX_SOFTIRQ 是最关键的软中断类型。

• 触发时机：由硬中断 ISR 在退出前标记触发，并在 irq_exit() 路径中被内核调度执行。
• 核心任务：执行实际的网络协议栈处理，包括：
  1. 从驱动层接收数据（NAPI 轮询）。
  2. 解析二层（MAC）、三层（IP）、四层（TCP/UDP）协议头。
  3. 执行路由查找、防火墙规则匹配（Netfilter）。
  4. 将数据包交付给对应的套接字（Socket）接收队列。
• 执行特性：软中断运行在 softirq 上下文中，可以响应高优先级的中断，但自身不能被其他软中断抢占（同一 CPU 上）。

3.3 硬中断 vs. 软中断：核心差异对比

下表从多个维度清晰对比了上半部与下半部的机制差异：

3.4 为什么软中断是性能瓶颈？

尽管软中断机制设计精良，但在现代高速网络（如 10Gbps/25Gbps/100Gbps）下，它逐渐成为制约收包性能的核心瓶颈。主要原因如下：

1. CPU 资源消耗巨大：协议栈处理（TCP/IP 卸载、内存拷贝、锁竞争）是计算密集型任务。当 PPS（Packets Per Second）达到数百万甚至上千万时，软中断会耗尽单个 CPU 核心的所有算力，导致该核心无法处理用户态业务。
2. 缓存污染严重：软中断处理会频繁访问 sk_buff、协议头、路由表等数据结构，导致 CPU 的 L1/L2 缓存被大量刷新。当软中断和业务进程运行在同一核心时，业务进程的缓存命中率会急剧下降，造成性能抖动。
3. 锁竞争与 Cache Line bouncing：多个 CPU 核心可能同时处理同一类型的软中断（如 NET_RX_SOFTIRQ），它们会竞争共享的全局数据结构（如路由表、套接字锁），导致严重的缓存行 bouncing 和自旋锁开销。
4. 中断风暴与 RPS 不均：如果所有硬中断都路由到同一个 CPU，该 CPU 的软中断负载会瞬间饱和，形成“中断风暴”。即使使用 RPS（Receive Packet Steering）将软中断分散到其他核心，也会引入额外的跨 CPU 内存访问延迟。

3.5 软中断成为瓶颈的微观流程

下面的 SVG 图展示了从数据包到达网卡到软中断处理完成的完整路径，并标注了潜在的瓶颈点：

3.6 瓶颈的量化表现

在实际生产环境中，软中断瓶颈可以通过以下指标进行量化识别：

• /proc/softirqs：查看 NET_RX 行的数值。如果某个 CPU 的数值远高于其他 CPU，说明软中断分布不均。
• top 命令：观察 %si（软中断占用）指标。当 %si 持续超过 50% 甚至 80% 时，表明该 CPU 已不堪重负。
• perf top：分析热点函数。如果 tcp_v4_rcv、ip_local_deliver、__netif_receive_skb_core 等函数占比极高，说明协议栈处理是瓶颈。
• 丢包统计：ethtool -S eth0 | grep drop 或 netstat -i 显示 RX 丢包，通常意味着软中断处理速度跟不上网卡接收速度。