龙瑜的博客

secondary 进程也要映射 primary 进程的 fbarray_* 文件，这个动作在 rte_eal_init 中间，如果 eal_clean_runtime_dir 在此前执行，primary 进程的 fbarray_* 文件就会被释放，这样 secondary 进程就无法再运行。既然 rte_eal_init 函数执行失败的问题都必须要解决，而它又是这个问题出现的前提，这样再去调整 eal_clean_runtime_dir 函数在 rte_eal_init 函数中的位置就没太大意义。

在不支持 sse3 及其以后的 x86_64 向量指令的环境中运行 dpdk 程序的修改思路

dpdk 缺省以大页的单位做内存映射创建大页内存文件的方式会随着映射文件数目的增多，使用更多的 fd，当系统对 dpdk 进程的 open file max 限制很低时就容易出现 fd 不足的问题。这时候使用 single-file-segments 参数能够很好地解决该问题，甚至于可以缺省配置该参数，从根源上解决此类问题。

dpdk 对网卡 lsc 中断的支持与配置及其隐含的问题

dpdk 中有许多向量指令的使用场景，收发包函数优化就是一个很典型的示例，一般来说一个网卡都有几套收发包函数，根据向量指令划分，有支持 sse、avx、avx512 这几个版本，实际应用中编译环境一般只有一套，运行环境却可能存在多套，这样就存在不兼容的问题。

dpdk 驱动对 virtio modern 设备会先尝试使用 modern pci ops 的方法读写网卡寄存器，当尝试失败后再继续尝试 legacy pci ops，这个顺序并不能调整，如果将 legacy pci ops 尝试放到前面，那一些 virtio modern 网卡就不能使用 modern pci ops 来读写网卡寄存器，性能会下降。，毕竟 qemu 并不区分虚拟机中的内核与用户态程序，而且其实内核与用户态程序只是分时执行代码，qemu 侧不应该有这个区别。

许多问题的复杂性不在于问题本身，而是难以获取到足够根因闭环的信息。这些信息的缺失一部分来源于框架自身实现与信息收集工具的缺失，另一部分来自于维护者对框架的理解的不足。对这两点不足进行反思并持续改进，当维护者对框架实现了然于胸，可用的工具也一抓一大把时，许多看似困难的问题将会迎刃而解。

本文描述了 dpdk 多进程程序在 k8s 环境运行的一个问题，从 dpdk 代码实现上来看，dpdk 对这种场景的支持并不好，可能还存在其它问题。上半年我写的程序启动顺序引发的血案之 dpdk 进程死锁这篇博客描述了 dpdk 多进程共享用户态锁潜在的死锁问题，在这个场景中也存在。这些问题比较隐晦，缺少对 dpdk 底层原理的理解则很难在方案设计前期识别出来，是一个风险点。

dpdk-16.04 中，使用 rte_mempool_create 与 rte_pktmbuf_pool_create 都可以创建出支持多生产者与多消费者的 pktmbuf pool。rte_pktmbuf_pool_create 只能创建多生产者与多消费者的 pktmbuf pool，使用 rte_mempool_create 却可以创建诸如单生产者与单消费者的 pktmbuf pool。尽管低版本有这样的行为，在高版本这两个接口却会有不同的行为。

业务程序使用 x710 网卡，收发一万多个巨帧包后就无法正常收包，查看网卡收发包统计发现 imissed 字段一直增加，问题必现。

在 x710 hash 分片与非分片 tcp 报文异常问题 这篇文章中，我描述了 x710 网卡同时 hash 分片与非分片报文的问题。实际的应用场景中，同一条流的包一般会被 hash 到同一个队列中，业务程序在同一个队列中处理同一条流的报文。当一条流同时包含分片与非分片报文时，由于分片报文与非分片报文五元组存在区别，当配置的 hash 规则不正确时，这些属于同一条流的报文可能会被网卡 hash 到不同的队列中，此时业务程序就会产生异常。...

在 程序启动顺序引发的血案之 dpdk 进程死锁 这篇博客中，我描述了 dpdk 多进程之间共享的用户态锁在临界区被异常杀死后无法再获取到锁的问题。修改的方案是将这些在多个进程之间共享的锁修改为 pthread mutex 互斥锁。前期的测试验证与代码 review 及集成测试都没有发现异常，最近却发现又出现了死锁的问题。最开始我的想法是现在使用了 mutex 锁，出现了死锁也能够找到是谁占有了锁，问题应该不太困难，实际操作起来却发现有些想当然。在本文中我将完整地描述这一新死锁问题定位的过程。...

问题描述kvm arm 虚拟机中 dpdk 业务程序使用 virtio 网卡收包时触发段错误，断在如下位置：#0 0x00000000004f2f9c in virtio_recv_pkts_vec ().....................................................#5 0x00000000004e14d4 in rte_eal_mp_remote_launch ()#6 0x000000000044ac64 in main ()问题必现！分

前言池是一种常见的设计技术，它将程序中常用的核心资源提前申请出来，放到一个【池子】里面，由程序自行管理资源的释放与申请。dpdk 作为一种高性能数据转发套件，其中的关键资源是以 mbuf 结构描述的报文。程序收发包与中间的处理涉及到【频繁】的 mbuf 申请、释放操作，为了优化这一过程，dpdk 内部也使用了池技术来管理 mbuf。dpdk 提供了类似内存池的结构，这一结构在 dpdk 内部称为 mempool，【专用】于 mbuf 的 mempool 又称为 pktmbuf_pool。dpdk 中

某产品的数通引擎持续运行一段时候后出现段错误，排查段错误发现访问的 mbuf 中的 port 字段变为了-1（全 F），需要排查 dpdk 内部对 mbuf 中 port 字段的使用情况。

原始问题国产化 ngbe 网卡使用 dpdk pmd 驱动，出现不发包问题，需要在异常环境上排查是否是上层发出了一个异常的报文导致。能不能 dump 上层软件发出的异常报文？按照过往的认识，在出现问题的时刻，上层软件已经发完了报文，这时候报文应该已经被释放了，这样看来应该根本抓取不到异常报文了。上面的描述缺少一个确定的描述，应该这个词表露出可能存在认识的偏差。那到底能不能做到呢？给出做不到的结论很容易，但真的不能吗？回答能不能不应该单凭感性的认识，应该进一步思考并实际测试来验证。把上面的问题分析

问题描述对于五元组随机变化的 QinQ 报文，需要实现如下需求：dpdk 程序 rx 时网卡自动剥掉外层 vlan 头dpdk 程序 tx 时网卡自动添加一个指定的 vlan 头报文能够 hash 到不同的队列上基于 dpdk-19.11 版本与 x710 网卡QinQ 报文的格式如下图所示，QinQ 其实可以简单的理解为 vlan 里面套了 vlan 的形式，QinQ 写成 802.1Q in 802.1 Q 可能更形象一点。上图摘自：https://www.cnblogs.com/s

2021 年前的 dpdk 版本中默认的 log 为 stdout，在实际使用中发现在调用 rte_eal_init 之前关闭 stdout 时，dpdk 程序运行异常。表面上看有点匪夷所思，真正研究起来竟然发现在 dpdk 的框架中这个问题算是一个正常的现象，让人忍不住叹了叹气~在本文中我将探讨下这个正常的异常现象，同时也引申描述一个真实场景中的问题。

前言在 程序启动顺序引发的血案 这篇文章中，我描述了在某个场景中由启动顺序引发的程序无法启动的问题。问题的表象如下：容器内的 dpdk secondary 进程初始化报了如下错误：EAL: Detected 16 lcore(s)EAL: Detected 1 NUMA nodesEAL: Multi-process socket /var/run/dpdk/rte/mp_socketEAL: Selected IOVA mode 'PA'EAL: Probing VFIO support..

问题描述在某个特定的场景中，dpdk primary 进程在宿主机上运行，在 dpdk primary 进程运行前，宿主机上的某 A 程序负责创建 /dev/hugepages 目录并挂载 hugetlbfs 到此目录中。同时在此宿主机上也以容器为基本单位指定特权模式运行其它的 dpdk secondary 进程，dpdk secondary 进程需要与 primary 进程共享的目录通过容器启动参数来映射。容器的启动时机与 A 程序创建 /dev/hugepages 目录并挂载大页内存的时序没有严格

问题描述VMWARE 虚机中，82545EM 虚拟网卡绑定 igb_uio 后，运行 dpdk 程序，dpdk 程序一直有如下报警信息：Eal:Error reading from file descriptor 33: Input/output error使用的 dpdk 版本为 16.04，程序为 l2fwd。问题分析1. dpdk 内部代码与报错相关的代码： bytes_read = read(events[n].data.fd, &buf, bytes_read);

问题描述i350 igb 电口，调用 dpdk rte_eth_stats_get 获取到的接口发包字节统计，每个包少了 crc len 长度，导致根据此统计计算的 bps 不准确。

某设备运行 dpdk 程序，free 的内存空间在逐渐下降。第一次查看：[root]# free -htotal used free shared buff/cache availableMem: 3.6G 1.5G 425M 403M 1.7G 534MSwap: 0B 0B 0B

问题描述系统运行时，内核 crash，oops 信息如下：<1>[17934.849450] BUG: unable to handle kernel NULL pointer dereference at 0000000000000030<1>[17934.849530] IP: [<ffffffffa009b135>] ixgbe_update_stats+0x38b/0xc7f [rte_kni].........

问题描述某设备运行 dpdk-16.04 版本程序，绑定的网卡中，某 igb 网卡出现一个口不能收包的情况。排查过程1. 确定问题此问题是测试同学反馈的，第一步需要做的是确定问题。在这一步需要确定如下几点： 对端是否在发包 ethtoool -S 多次获取统计信息是否能够说明接口不收包 接口是否处于 up 状态 其它口是否有类似的问题 dmesg 中是否有异常告警 配置文件是否正确 程序是否有段错误

问题描述使用 dpdk-20.11 testpmd 测试 ice 100G 网卡的时候发现设置 rss_hash 一直不生效，打流确认流量一直被 hash 到第一个队列上，其它的队列没有收到一个包。

问题描述1. ipackets 减掉 imissed 统计的问题ice 100G 网卡获取的 ipackets 会减掉 imissed 的报文，此时统计的是软件实际从网卡收包的 pps，但收包的 bps 中没有减掉这部分报文长度且硬件不能提供这部分信息用于计算，为此屏蔽 ipackets 中减掉 imissed 报文的统计以修复 pps 显示问题。2. ibytes 每个报文减掉 crc 长度导致显示带宽变少问题ice 100G 网卡 ibytes 统计会为每个报文减掉 crc 长度，bps 变

问题描述某千兆电口网卡性能测试时发现不同网卡测试出来的时延差异较大！

/*Begin scanning the H/W ring for done descriptors when thenumber of available descriptors drops below tx_free_thresh. Foreach done descriptor, free the associated buffer.*/if (txq->nb_tx_freetx_free_thresh)ixgbe_tx_free_bufs(txq);

某 amd 设备，dpdk 程序初始化的时候报错，程序异常终止。dmesg 中有如下报错信息：[Tue Jun 22 10:28:52 2021] AMD-Vi: Event logged [IO_PAGE_FAULT device=02:00.0 domain=0x005d address=0x000000024e398d40 flags=0x0010][Tue Jun 22 10:28:53 2021] AMD-Vi: Event logged [IO_PAGE_FAULT device=02

问题描述软件版本：vpp网卡类型与对端设备：某万兆 x710 bypass 卡对端连接测试仪问题现象：重启 vpp，x710 网卡灯不亮vppcli 查看接口信息:接口状态为 error，并报 pmd-init-fail 的错误复现方法与概率：重启 vpp 就能够复现，复现概率较大

dpdk 中的 mbuf

在某款新导入的硬件中，业务口使用四光口的 x710 网卡，dpdk 程序初始化的时候报了如下错误：EAL: PCI device 0000:16:00.0 on NUMA socket -1EAL: probe driver: 8086:1581 rte_i40e_pmdEAL: PCI memory mapped at 0x4200120000EAL: PCI memory mapped at 0x4200920000PMD: eth_i40e_dev_init(): FW 6.2