dwceqos网络驱动性能优化

文章介绍

本文会分享一些在QNX系统下对io-pkt-v6-hc驱动模块cpu loading过高问题优化的经验，以及一些调优debug的方法。这些优化措施实施之后可以降低io-pkt-v6-hc在高负载的情况下的cpu loading。本文的调优是基于synopsys公司的dwceqos模块，理论上方法适用于所有采用了该IP core的SOC平台.

问题背景

硬件平台：BST A1000， QNX

ADAS域控通过以太网接收激光雷达部件发送过来的激光数据，测试过程中发现，在激活激光雷达功能的情况下，激光雷达的数据包会出现比较明显的丢帧现象.

初步调查发现，在发生丢帧时，整个系统的cpu loading非常的高（100%），而且持续处于这种状态，整个系统cpu资源处于过载的状态.

从上面的cpu loading表现来看，QNX的io-pkt-v6-hc的整体cpu loading很高.

由于这个问题的存在已经严重影响了功能的正常使用，所以我们想在不影响性能的前提下，尽可能优化cpu loading，已达到一个合理的范围。

调查过程

这里我们需要弄明白的第一个问题是：即当前在这种测试场景下，我们cpu loading表现是否正常？是否符合芯片设计的要求？

这里引出来几个话题：

一、我们的硬件设计是怎样的？了解硬件的整体框架对于我们进行问题调查和优化是必要的

从上面的示意图可以看到，Lidar部件通过以太网与RTL9068 switch进行连接，swtich则通过RGMII与SOC的MAC硬件进行直连.

二、软件框架是怎样的？io-pkt-v6-hc是和那个硬件模块交互？

同样的，我们也需要了解整个系统中与我们问题相关的模块的软件框架大致是怎么样的，特别是数据传输的整个过程.

上图示意了简单的软件框架，这其中涉及到几个部分：

a, app与QNX操作系统的网络模块io-pkt-v6-hc的交互，需要注意的是，io-pkt-v6-hc是QNX的网络服务框架，上面的示意图严格来说并不十分准确，因为APP并不会与io-pkt-v6-hc直接进行交互，但是所有的网络数据交互都会经过io-pkt-v6-hc,再由其调用实际的以太网驱动进行数据传输（图中是MAC-driver）。

有关io-pkt-v6-hc有关的信息可以参考：io-pkt-v6-hc

b, io-pkt-v6-hc与mac-drviver的交互

在我们平台上，io-pkt-v6-hc对接的MAC以太网驱动devnp-dwceqos-mv88e1512.so。在接收网络数据传输时，最先由MAC硬件接收，再由驱动进行处理，然后调用if_input注入qnx的网络子系统中.

io-pkt-v6-hc与mac驱动模块有很多交互，这里不展开，更多细节可以参考这个链接：writing a qnx network driver

c,mac 驱动与硬件的交互

在芯片层面，MAC这个硬件模块大致与CPU以及其他模块的连接大致如下（不完全准确）：

其中比较重要的是需要知道，MAC硬件模块与SOC的中断控制器（IC）有数条中断线进行连接，其中的中断号可以通过对应的手册查询到：

这里有必要研究明白mac模块中的中断是如何产生的，在mac硬件中有多中断，有的用于表明异常，有的用于表明状态，我们目前关注的中断是和数据传输相关的中断：

sbd_perch_tx_intr_o[]，传输中断

sbd_perch_rx_intr_o[]，接收中断

sbd_intr_o，通用中断

更多细节需要你参考手册中“*2.6Interrupts” *章节

三、当前的loading状态是否正常？

针对这个问题，我们最先和我们的芯片供应商进行了讨论，但是从反馈来看，他们似乎也并没有什么比较好的解决方法（他们知道这个问题的存在）.由于这个部分的驱动代码由ip core供应商开发，所以他们并不十分了解其中的细节.

查看了这个MAC的IP core状态，是synopsys公司的dwceqos模块，这个ip core不止在我们这个SOC上使用，同时在高通的多款芯片上也有应用。

基于这个背景，我们也同时测试了8155 q+a/8155 lv/8255 q+a/8295 q+a 这几个平台上的表现，发现表现基本相同，即在千兆以太网传输的case下，cpu loading普遍会很高.

从各方反馈的结果来看，测试结果似乎符合预期的？但是直觉上又感觉不合理，因为进行网络传输占用如此多都cpu资源似乎并不合理（相比其他平台进行网络传输并不会有很高的loading）。

调查思路

一般来说，cpu负荷过高通常有2个原因，一是，cpu现在的确一直在干活，那么优化的思路是优化cpu的工作内容，二是，cpu一直在被中断，反复的状态切换带来的高消耗。

优化尝试

1，确认是否启用DMA

2，修改网络模块收发buffer size

3，修改驱动加载参数

4，中断优化

基于中断合并的思路，我们翻阅了*"DesignWare Cores Ethernet Quality-of-Service
Databook" *这个ip core的datasheet，其中有一段描述：

这段话简单概括来说是，如果你想优化性能，那么最好使用IOC标志位&定时器来产生中断，而不是每次DMA传输完成都产生一次中断.

其中还有一段关于中断模式的描述：

简单概括来说就是，在中断模式0（default）的情况下，只要检测到RX/TX的IOC标志位都会立即触发通用中断（sbd_intr_o），而在1/2模式下，则完全不触发sbd_intr_o中断，而只会触发sbd_perch_tx_intr_o[]或者sbd_perch_rx_intr_o[]

到这里，我们又遇到了问题： 该如何确认我当前驱动工作在那个模式下？

通过驱动代码&SOC芯片手册，我们可以确定这个GMAC控制的寄存器地址，通过devmem2直接读取其值：

note:

1，这里读到的值是我修改过之后的值，默认情况下读到的值是0x0

2，如果devmem2工具不可用，那么可以用qnx提供的in32/out32来读写寄存器

4.1 中断模式修改

到这里，我们首先尝试直接修改中断模式，修改为1/2模式之后，网络驱动完全不可用，无法传输数据。想了下，原因其实很简单，因为驱动已经指定了中断触发的源是sbd_intr_o，我们更改模式之后，因为并没有中断源与当前驱动挂钩，所以即使有数据传输产生也不会产生任何函数调用。

我们通过修改驱动更新了中断源为sbd_perch_rx_intr_o，测试之后发现效果并没有什么变化

原因在于，现在每次DMA描述符都被设置了IOC标志位，意味着，每次传输完成都会产生sbd_perch_rx_intr_o中断，与我们预期还是不符合.

4.2 中断模式修改+修改中断源+定时器触发

基于上面的原因，我们清除了驱动中大部分都DMA描述符的IOC标志位，只在特定的DMA描述符上设置IOC标志位，比如4/16/32。

不过这个时候还是有问题，因为DMA传输只在有IOC标志位的描述符传输完成时产生中断，如果没有检测到IOC标识符则不会产生中断，那么数据的实时性就没有保证了，比如你只传递了一次数据，那么这个数据并不会及时得接收到（因为还未达到IOC触发阈值）.

为了解决这个问题，我们需要增加一个timer来定时触发中断，按照手册的描述：

当timer寄存器写入数值时，如果此时一个RX DMA传输完成，且IOC标志位没有被设置，那么timer将会启动，在RWT*RWTU个系统时钟后超时，并产生中断.

优化结果对比

优化前测试结果

iperf3传输速度：

cpu loading表现（每隔1s采样一次）

中断表现：

优化后测试结果

iperf3 测试表现：

cpu loading表现（每隔1s采样一次）

中断表现

代码修改点

1，在reset mac之后增加下面改动：

2，初始化dma是，只在特定的描述符上添加IOC描述位：

同时在接收处理函数中，重新初始化dma描述符时，执行同样的操作

3，修改mac的中断触发源为sbd_perch_rx_intr_o