006、硬件视角:DPU、智能网卡与可编程交换芯片

问题初现：常规排查无果

  常规排查走了一圈：应用日志没异常，CPU/内存水位正常，网络带宽占用不到30%。直到我用 ethtool -S 扫了一眼网卡统计，发现 rx_missed_errors 和 rx_no_buffer_count 这两个计数器正在悄悄往上跳——问题出在网卡和数据包处理路径上。

传统网卡的数据处理瓶颈

  那时候我们还在用传统网卡，所有数据包都得经过内核协议栈，CPU大半时间花在搬运数据、处理中断和上下文切换上。

// 传统NAPI收包循环(简化版)
while(!budget_exhausted) {
  // 从网卡DMA环取描述符
  desc = rx_ring[ring_index];
  // 分配skb(这里踩过坑:高频分配碎片化内存直接搞崩kmem)
  skb = netdev_alloc_skb(dev, len);
  // DMA同步到CPU缓存(这步开销比想象中大)
  dma_sync_single_for_cpu(dev->dma_handle);
  // 送协议栈(后面还有软中断、内存拷贝连环套)
  netif_receive_skb(skb);
}

  CPU全程在干体力活：分配内存、同步缓存、处理中断、搬运数据。当AI训练需要100Gbps甚至更高带宽时，这套流程直接让CPU跪了——你买的是计算芯片，结果它一半时间在当搬运工。

智能网卡卸载：释放CPU算力

// 原本在CPU上做的TLS解密
ssl_ctx = SSL_new(ctx);
SSL_read(ssl_ctx, encrypted_data, len); // CPU算到冒烟

// 卸载到智能网卡后
// 配置流表规则(伪代码)
nic_flow_rule = {
  .match = { .dst_port = 443 },
  .action = ACTION_CRYPTO_DECRYPT,
  .key_id = ssl_key_handle // 密钥提前注入网卡安全区
};
// 后续443端口流量自动在网卡解密
// CPU看到的是明文数据