一、问题现象

1.在dpos飞腾平台适配过程中，发现dpos部署完成，运行一个晚上后，无法ping通交换机网关。

2.在虚机中通过dpos-pdump抓包，发现收到的交换机回复的icmp reply报文内容不正确，导致ping认为没有收到icmp回复。

 

二、问题分析

1. 排查确认问题与网元有关，与交换机无关

• 通过如下方法对e810网卡的vf进行端口镜像并抓包

• 对比镜像端口收到的icmp reply报文和vf收到的icmp reply报文，并与request报文对比，可以看到同一时间抓到的报文，PF收到的icmp id与request一致，但是vf收到的icmp id却与request不一致。

request报文：

06:42:03.986634 52:54:00:8f:fd:15 > 00:00:5e:00:01:c3, ethertype IPv4 (0x0800), length 106: 10.24.120.9 > 10.24.120.14: ICMP echo request, id 16887, seq 256, length 72

        0x0000:  0000 5e00 01c3 5254 008f fd15 0800 4500

        0x0010:  005c 0001 0000 4001 7659 0a18 7809 0a18

        0x0020:  780e 0800 97d6 41f7 0100 51bf 2f00 0000

        0x0030:  0000 3052 6c20 0000 0000 0000 0000 0000

        0x0040:  0000 0000 0000 0000 0000 0000 0000 0000

        0x0050:  0000 0000 0000 0000 0000 0000 0000 0000

        0x0060:  0000 0000 0000 0000 0000

PF vlan子接口收到的报文：

14:42:03.273504 00:00:5e:00:01:c3 > 52:54:00:8f:fd:15, ethertype IPv4 (0x0800), length 106: 10.24.120.14 > 10.24.120.9: ICMP echo reply, id 16887, seq 256, length 72

        0x0000:  5254 008f fd15 0000 5e00 01c3 0800 4500

        0x0010:  005c cd30 0000 ff01 ea28 0a18 780e 0a18

        0x0020:  7809 0000 9fd6 41f7 0100 51bf 2f00 0000                                                                                                                                                                                                                                            

        0x0030:  0000 3052 6c20 0000 0000 0000 0000 0000

        0x0040:  0000 0000 0000 0000 0000 0000 0000 0000

        0x0050:  0000 0000 0000 0000 0000 0000 0000 0000

        0x0060:  0000 0000 0000 0000 0000   

 

虚机vf收到的报文：

06:42:03.986583 00:00:5e:00:01:c3 > 52:54:00:8f:fd:15, ethertype IPv4 (0x0800), length 106: 10.24.120.14 > 10.24.120.9: ICMP echo reply, id 26026, seq 10082, length 64

        0x0000:  5254 008f fd15 0000 5e00 01c3 0800 4500

        0x0010:  0054 620a 4000 ff01 1557 0a18 780e 0a18

        0x0020:  7809 0000 7fee 65aa 2762 ba9c 5464 0000                                                                                                                                                                                                                                            

        0x0030:  0000 2131 0400 0000 0000 1011 1213 1415

        0x0040:  1617 1819 1a1b 1c1d 1e1f 2021 2223 2425

        0x0050:  2627 2829 2a2b 2c2d 2e2f 3031 3233 3435

        0x0060:  3637 0000 0000 0000 0000  

 

1. 排查确认问题与网元DPDK有关

• 在网元虚机中停止DPDK进程，并将内核态设备eth1配置相同的IP和掩码，持续ping交换机网关一个晚上，未出现ping不通的现象；

 

2. 排查确认问题与ARM平台有关

• 在另外一台海光x86平台的网元上，使用相同的驱动和软件版本，进行相同的测试，未出现ping不通的现象；
• 已经上线的intel x86平台网元也有采用e810网卡的配置，经过了解也未出现类似问题；

 

 

三、解决方法

1. ARM和x86 dpdk rx函数差异

经过对比发现，arm和x86 dpdk的rx函数不同，x86采用了avx512指令的收包函数，结合问题在x86上不复现，且问题现象主要是报文接收异常，重点怀疑arm的收包函数存在问题。

1.海光dpdk接收函数 iavf_recv_scattered_pkts_vec_avx2 ()

飞腾ARM DPDK接收函数iavf_recv_scattered_pkts ()

 

2. iavf_recv_scattered_pkts社区补丁

从dpdk社区中查询 iavf_recv_scattered_pkts 函数相关的patch，发现了一个“fix scalar Rx”的补丁比较相关。大概理解是，rx收报后，新分配的mbuf需要被添加到rxq的sw ring中，否则网卡遍历完一轮rx ring后，再次从sw ring中读取mbuf时获取到的是之前的mbuf，而不是网卡根据rxdp中的dma addr地址dma过来的报文。

 

通过patch分析可以确认遍历一轮rx ring后就会出现问题，网元配置的rx ring depth为4096，即接收4096个报文后再次收报即触发问题。因此，停掉网元中的BGP进程，保证VF只收发ping报，通过ping快速发送4096个报文，验证问题即可复现。

 

将上述patch合入网元使用的dpdk 19.08代码，按照上述复现问题的方法收发4096个包后，网元仍能正常ping通网关，且运行一个晚上后，也未在出现问题。

 

附：iavf收包函数概述