本文共 919 字，大约阅读时间需要 3 分钟。

今天，我遇到了一个关于DPDK和KNI的问题。同事反馈在更新DPDK后，knir口无法正常创建，怀疑是rte_kni.ko模块的问题。于是我决定详细排查这个问题。

首先，我运行了产品服务器，发现knir口确实没有创建，并且服务器不断重启。为了进一步分析，我回顾了dmesg日志，发现没有相关的ioctl打印信息。这让我怀疑是否是打印级别的问题。

根据提到的内容，/proc/sys/kernel/printk文件控制了内核中printk的行为。Modify这个文件可能会影响打印信息的输出。我知道“console_loglevel”这个字段，如果消息的日志级别低于这个值才会打印，所以我把它调高到7，尝试重新运行程序，但结果依然没有打印信息。接着，我修改了KNI创建虚拟网络接口的代码，重新测试，仍然没有任何打印，这让我怀疑是否根本没有调用到相关函数。

接下来，我需要界定问题是在内核还是用户态程序中。用户态程序中创建KNI的步骤存在两个主要环节：初始化和分配。我记得在DPDK 16.04中，rte_kni_alloc中的代码确实存在问题，特别是KNI_MEM_CHECK这一部分。它检查了mz是否为NULL，如果是，程序就不会继续，直接返回，并且不会调用ioctl创建KNI口。

进一步排查发现，rte_memzone_lookup(mz_name)没有找到mz_name，导致mz为NULL。查找原因是因为没有人创建了mz_name。这让我怀疑是mempool没有正确初始化，或者相关的配置设置有误。

通过这些分析，我得出结论：问题出在用户态程序中，而不是内核。因为在rte_kni_alloc中，KNI_MEM_CHECK导致程序提前终止，没有调用ioctl，从而没有创建KNI口。进一步使用strace跟踪系统调用，确认程序是否调用了ioctl，结果显示没有调用到，只能说明问题确实在用户态程序中。

总结一下，排查问题的关键在于先对问题进行界定，确定是在内核还是用户态，进而采取相应措施。在解决过程中，我不断调整打印级别和检查调用链，最终找到了问题出在用户态程序的KNI初始化阶段，导致ioctl未被调用，进而没有创建KNI口。

转载地址：http://sldjz.baihongyu.com/