八、TX Completion 为什么不会实时发生很多开发者第一次阅读DPDK发送代码时都会产生一个疑问既然一个数据包已经发送完成为什么不能立即释放对应的mbuf原因在于对于支持DMA的网卡而言CPU并不知道DMA什么时候真正结束。真正的数据路径如下Application │ ▼ TX Descriptor │ ▼ NIC DMA读取mbuf │ ▼ MAC发送 │ ▼ 硬件更新Descriptor状态 │ ▼ 驱动回收Descriptor │ ▼ 释放mbuf只有当网卡确认DMA已经完成并更新Descriptor状态以后。驱动才能安全释放对应mbuf。否则CPU可能提前释放一块仍然正在被DMA访问的内存这会造成严重的数据错误。因此TX资源释放永远滞后于rte_eth_tx_burst()。核心知识点四rte_eth_tx_burst()完成的是提交Submit而不是完成Complete。九、批量回收为什么更高效继续分析DPDK驱动。无论Intel还是NVIDIA PMD。通常都不会每完成一个Descriptor。立即执行资源回收。原因很简单。如果每发送一个Packet就读取一次TX Descriptor状态。PCIe访问次数将急剧增加。因此驱动通常采用批量检查。例如Packet1 Packet2 Packet3 ...... Packet32 ↓ 统一检查Completion ↓ 统一释放mbuf这样能够减少PCIe访问。提高发送吞吐。但是也带来了资源释放存在延迟。十、问题真正出现的位置继续分析应用统计。发现发送速度始终稳定。但是资源释放具有明显波动。例如时间 0ms ↓ 发送 10000 Packet ↓ 释放 9800 ---------------- 10ms ↓ 发送 10000 ↓ 释放 6000 ---------------- 20ms ↓ 发送 10000 ↓ 释放 13000可以看到释放速度并不是均匀发生。而是成批完成。于是系统中的Inflight mbuf开始周期性增长。核心知识点五对于高速交换机而言。真正重要的不是发送速度。而是发送资源的周转速度。如果资源回收慢。即使带宽没有达到极限。系统仍然可能出现吞吐下降。十一、为什么版本升级后才暴露继续比较两个版本。最终发现新版本调整了TX Queue参数。其中一个配置发生变化tx_free_thresh该参数控制驱动什么时候开始批量回收已经完成发送的Descriptor。阈值设置过高。意味着需要等待更多Descriptor完成才开始统一释放。于是mbuf停留时间更长。对象周转效率下降。需要说明的是tx_free_thresh的具体作用由 PMD 实现决定。DPDK API 对其定义的是回收触发阈值并不保证所有驱动都采用完全一致的回收策略因此调优时应结合具体 PMD 源码和官方文档。十二、如何验证为了进一步验证。增加TX Ring监控。同时统计可用mbuf数量。结果每当Inflight mbuf达到高点。可用mbuf同步下降。而TX Completion发生以后。二者同时恢复。整个过程完全一致。说明真正的问题不是发送慢。而是资源回收慢。十三、源码分析中的一个细节很多开发者注意到DPDK提供rte_eth_tx_done_cleanup()于是认为主动调用就可以立即释放所有资源。事实上并不是。该接口只是尝试回收已经完成的Descriptor。如果硬件尚未完成对应发送。那么依然不能释放mbuf。因此它并不能绕过NIC发送完成机制。这一点也是很多工程实践中容易误解的地方。核心知识点六TX资源回收最终仍然依赖硬件Completion。软件只能发现。不能制造。十四、工程优化方案经过分析最终进行了以下优化。一、重新评估TX回收参数结合业务Burst特点。调整TX回收阈值。避免资源长时间滞留。注意不是越小越好。过小意味着驱动需要更加频繁检查Completion。反而增加CPU开销。因此需要结合业务模型综合评估。二、保持发送Burst稳定以前应用发送8 32 64 12 48调整以后统一32 32 32减少Descriptor碎片化。提升回收效率。三、监控资源周转增加如下统计Inflight mbufTX Ring OccupancyCompletion Rate相比仅监控PPS。更容易提前发现资源回收异常。十五、优化结果连续压测24小时。结果如下指标优化前优化后PPS周期性下降稳定P99 Latency8.3 μs6.1 μsInflight mbuf周期波动基本稳定Completion Delay高明显下降整个过程中CPU始终保持100%。说明真正改善的是资源生命周期管理。而不是CPU利用率。十六、全文总结DPDK发送路径最大的特点就是异步。应用调用rte_eth_tx_burst()。仅仅意味着Packet已经提交给网卡。真正的数据发送、DMA完成、Descriptor回收、mbuf释放都是后续异步完成。因此很多性能问题。并不是发送速度不足。而是资源回收效率下降。对于高性能交换机而言。TX路径实际上也是一条完整的资源流水线。只有Descriptor、mbuf、DMA、Completion形成稳定闭环。系统才能长期保持高吞吐、低时延。全文核心知识点rte_eth_tx_burst()表示提交成功不代表发送完成。TX Descriptor 生命周期包含提交、DMA、发送、Completion、回收五个阶段。批量Completion能够提升吞吐但会引入资源释放延迟。TX性能不仅取决于发送速度还取决于资源周转速度。tx_free_thresh是重要调优参数但应结合具体PMD实现分析。rte_eth_tx_done_cleanup()只能回收已完成的Descriptor不能强制完成发送。监控 Inflight mbuf 和 Completion Rate比单纯监控 PPS 更容易发现TX路径瓶颈。工程实践建议对于100G及以上DPDK交换机建议建立一套完整的TX资源监控体系包括Inflight mbuf 数量TX Ring 使用率Descriptor 回收速率Mempool 可用对象数量Packet 生命周期。这样能够比传统的CPU、PPS和网卡错误统计更早发现系统进入资源周转瓶颈为持续优化提供可靠依据。
100G交换机时延却突然增加30%——一次DPDK TX Completion回收机制深度分析（下）
八、TX Completion 为什么不会实时发生很多开发者第一次阅读DPDK发送代码时都会产生一个疑问既然一个数据包已经发送完成为什么不能立即释放对应的mbuf原因在于对于支持DMA的网卡而言CPU并不知道DMA什么时候真正结束。真正的数据路径如下Application │ ▼ TX Descriptor │ ▼ NIC DMA读取mbuf │ ▼ MAC发送 │ ▼ 硬件更新Descriptor状态 │ ▼ 驱动回收Descriptor │ ▼ 释放mbuf只有当网卡确认DMA已经完成并更新Descriptor状态以后。驱动才能安全释放对应mbuf。否则CPU可能提前释放一块仍然正在被DMA访问的内存这会造成严重的数据错误。因此TX资源释放永远滞后于rte_eth_tx_burst()。核心知识点四rte_eth_tx_burst()完成的是提交Submit而不是完成Complete。九、批量回收为什么更高效继续分析DPDK驱动。无论Intel还是NVIDIA PMD。通常都不会每完成一个Descriptor。立即执行资源回收。原因很简单。如果每发送一个Packet就读取一次TX Descriptor状态。PCIe访问次数将急剧增加。因此驱动通常采用批量检查。例如Packet1 Packet2 Packet3 ...... Packet32 ↓ 统一检查Completion ↓ 统一释放mbuf这样能够减少PCIe访问。提高发送吞吐。但是也带来了资源释放存在延迟。十、问题真正出现的位置继续分析应用统计。发现发送速度始终稳定。但是资源释放具有明显波动。例如时间 0ms ↓ 发送 10000 Packet ↓ 释放 9800 ---------------- 10ms ↓ 发送 10000 ↓ 释放 6000 ---------------- 20ms ↓ 发送 10000 ↓ 释放 13000可以看到释放速度并不是均匀发生。而是成批完成。于是系统中的Inflight mbuf开始周期性增长。核心知识点五对于高速交换机而言。真正重要的不是发送速度。而是发送资源的周转速度。如果资源回收慢。即使带宽没有达到极限。系统仍然可能出现吞吐下降。十一、为什么版本升级后才暴露继续比较两个版本。最终发现新版本调整了TX Queue参数。其中一个配置发生变化tx_free_thresh该参数控制驱动什么时候开始批量回收已经完成发送的Descriptor。阈值设置过高。意味着需要等待更多Descriptor完成才开始统一释放。于是mbuf停留时间更长。对象周转效率下降。需要说明的是tx_free_thresh的具体作用由 PMD 实现决定。DPDK API 对其定义的是回收触发阈值并不保证所有驱动都采用完全一致的回收策略因此调优时应结合具体 PMD 源码和官方文档。十二、如何验证为了进一步验证。增加TX Ring监控。同时统计可用mbuf数量。结果每当Inflight mbuf达到高点。可用mbuf同步下降。而TX Completion发生以后。二者同时恢复。整个过程完全一致。说明真正的问题不是发送慢。而是资源回收慢。十三、源码分析中的一个细节很多开发者注意到DPDK提供rte_eth_tx_done_cleanup()于是认为主动调用就可以立即释放所有资源。事实上并不是。该接口只是尝试回收已经完成的Descriptor。如果硬件尚未完成对应发送。那么依然不能释放mbuf。因此它并不能绕过NIC发送完成机制。这一点也是很多工程实践中容易误解的地方。核心知识点六TX资源回收最终仍然依赖硬件Completion。软件只能发现。不能制造。十四、工程优化方案经过分析最终进行了以下优化。一、重新评估TX回收参数结合业务Burst特点。调整TX回收阈值。避免资源长时间滞留。注意不是越小越好。过小意味着驱动需要更加频繁检查Completion。反而增加CPU开销。因此需要结合业务模型综合评估。二、保持发送Burst稳定以前应用发送8 32 64 12 48调整以后统一32 32 32减少Descriptor碎片化。提升回收效率。三、监控资源周转增加如下统计Inflight mbufTX Ring OccupancyCompletion Rate相比仅监控PPS。更容易提前发现资源回收异常。十五、优化结果连续压测24小时。结果如下指标优化前优化后PPS周期性下降稳定P99 Latency8.3 μs6.1 μsInflight mbuf周期波动基本稳定Completion Delay高明显下降整个过程中CPU始终保持100%。说明真正改善的是资源生命周期管理。而不是CPU利用率。十六、全文总结DPDK发送路径最大的特点就是异步。应用调用rte_eth_tx_burst()。仅仅意味着Packet已经提交给网卡。真正的数据发送、DMA完成、Descriptor回收、mbuf释放都是后续异步完成。因此很多性能问题。并不是发送速度不足。而是资源回收效率下降。对于高性能交换机而言。TX路径实际上也是一条完整的资源流水线。只有Descriptor、mbuf、DMA、Completion形成稳定闭环。系统才能长期保持高吞吐、低时延。全文核心知识点rte_eth_tx_burst()表示提交成功不代表发送完成。TX Descriptor 生命周期包含提交、DMA、发送、Completion、回收五个阶段。批量Completion能够提升吞吐但会引入资源释放延迟。TX性能不仅取决于发送速度还取决于资源周转速度。tx_free_thresh是重要调优参数但应结合具体PMD实现分析。rte_eth_tx_done_cleanup()只能回收已完成的Descriptor不能强制完成发送。监控 Inflight mbuf 和 Completion Rate比单纯监控 PPS 更容易发现TX路径瓶颈。工程实践建议对于100G及以上DPDK交换机建议建立一套完整的TX资源监控体系包括Inflight mbuf 数量TX Ring 使用率Descriptor 回收速率Mempool 可用对象数量Packet 生命周期。这样能够比传统的CPU、PPS和网卡错误统计更早发现系统进入资源周转瓶颈为持续优化提供可靠依据。
