1. 基于OS内核转发的劣势

1.1. 数据路径长，协议栈处理开销大

• 内核路径：
  数据包需经过内核协议栈（如TCP/IP栈）的多层处理（链路层→网络层→传输层→应用层），涉及大量内存拷贝、校验和计算、上下文切换等操作。
• DPDK优化：
  直接绕过内核，在用户空间处理数据包，省去协议栈的逐层解析，实现零拷贝（Zero-Copy）和批量处理，显著降低延迟。

1.2. 中断与上下文切换

• 内核模式：
  每个数据包到达时触发硬件中断，导致CPU频繁切换上下文（用户态↔内核态）。高负载时，中断风暴可能占用大量CPU资源。另外，在基于多线程的服务器设计框架中，线程间的调度也会产生频繁的上下文切换开销，同样，锁竞争的耗能也是一个非常严重的问题。
• DPDK优化：
  使用轮询模式（Poll Mode）替代中断，主动从网卡队列拉取数据，避免中断开销。结合CPU亲和性（Affinity）绑定核心，减少上下文切换。

1.3. 内存访问效率低

• 内核瓶颈：
  内核通过sk_buff结构管理数据包，存在多次内存拷贝。正常情况下，一个网络数据包从网卡到应用程序需要经过如下的过程：数据从网卡通过DMA等方式传到内核开辟的缓冲区，然后从内核空间拷贝到用户态空间，在 Linux 内核协议栈中，这个耗时操作甚至占到了数据包整个处理流程的 57.1%。传统服务器内存页为4K，容易出现cache miss。
• DPDK优化：
  利用大页（HugePages） 和 预分配内存池，用户空间直接访问网卡DMA缓冲区，实现零拷贝，减少内存访问延迟。

1.4. 局部性失效、核竞争

• 内核锁竞争：
  内核协议栈的共享数据结构（如Socket缓冲区）需加锁保护，多核并发时锁竞争严重，扩展性差。一个数据包的处理可能跨多个CPU核心，比如一个数据包可能中断在cpu0，内核态处理在cpu1，用户态处理在cpu2，这样跨多个核心，容易造成 CPU缓存失效，造成局部性失效。如果是NUMA架构，更会造成跨NUMA访问内存，性能受到很大影响。
• DPDK优化：
  采用无锁队列（Lock-free Ring） 和 每核独享资源（如单独队列、内存池），支持线性扩展至数十个核心。

1.5. 确定性延迟难以保证

• 内核不确定性：
  内核调度、中断处理、任务抢占等机制引入随机延迟，难以满足超低延迟需求（如高频交易、5G控制面）。
• DPDK优化：
  通过独占CPU核心、禁用中断、实时线程优先级等手段，实现微秒级确定性延迟。

1.6. 吞吐量瓶颈

• 内核极限：
  传统内核协议栈的单核吞吐量通常在1-2Mpps（每秒百万包），难以应对高速网卡（如100Gbps、200Gbps）。
• DPDK优化：
  单核可处理10Mpps以上，结合多核负载均衡，充分发挥高速网卡性能。

1.7. 硬件卸载支持有限

• 内核支持滞后：
  对新硬件特性（如GPUDirect RDMA、智能网卡功能）的支持需等待内核更新。
• DPDK优势：
  通过PMD（Poll Mode Driver）直接管理网卡，快速集成硬件加速功能（如TSO、CRC校验卸载）

2. DPDK局限性

虽然DPDK性能优势显著，但也需付出代价：

1. 独占CPU核心：需预留专用核心运行轮询线程，可能浪费资源。
2. 生态依赖：需特定硬件（如支持SR-IOV的网卡）和驱动支持。
3. 协议栈缺失：需自行实现TCP等复杂协议

3. 对比