总结一下在使用ovs和dpdk过程中踩过的坑

之前经常碰到有sa找过来，问加了个新节点，为什么就是无法工作？此时可以排查一下如下的可能：

1.neutron节点和proton的非dpdk节点vxlan不工作

 查看一下vxlan的ofport是否正常。如果为-1，基本表明openvswitch.ko内核模块加载的有问题

 一般我们推荐用openvswitch自带的dkms版本，也就是和宿主机内核一起编译出来的openvswitch内核模块。（此时安装后应该有这么一个包openvswitch-datapath-dkms）

 当然按照社区的说法，在内核版本为3.12之后也可以直接使用内核自带的openvswitch.ko，不过我们基本不推荐这么用。

 lsmod|grep openvswitch，如果这里列出来的内容如果没有包含vxlan，gre等信息，那基本上表明内核模块加载的有问题。

2.neutron的外网不通

 neutron中我们会通过在/etc/network/interface中配置类似内容：

 auto br-wan-yz

 allow-ovs br-wan-yz

 iface br-wan-yz inet manual

   pre-up ovs-vsctl --may-exist add-br br-wan-yz

   pre-up ovs-vsctl --may-exist add-port br-wan-yz eth2.110

这种方式可以让vswitchd启动后自动执行这些命令，将相关的网卡加入ovs bridge。

这是一种可能，就是配置了对应的neutron public network，但是etc文件中没有相应的内容。

另外一种经常遇到的可能，就是eth2.110这个设备不存在，此时在ovs-vsctl show中可以看到eth2.110(No Such Device)的显示。这种一般是由于新加网段和vlan，忘记改相关的文件。

3.proton dpdk节点无法拉起ovsdb进程

 这个是最近使用proton的节点才遇到的新问题。

 之前在neutorn版本的时候，为了解决物理机重启时加载ovs的conf.db慢的问题（一般是计算节点或者l3节点，有比较多的port，或者残留port很多），在物理机启动时

 会删除conf.db再启动vswitchd，因此写了个服务叫做purge-ovs-residuals。

 但是在proton dpdk的ovs版本，由于我们的服务不是采用社区的那一套，conf.db是由我们自己的服务来生成，同时ovsdb和vswitchd服务单独重启。

 此时如果purge-ovs-residuals该服务继续存在，并且在ovsdb启动后再执行，那就会导致后续的agent服务无法连接conf.db数据服务。

 这个问题只需要删除purge-ovs-residuals服务然后重启物理机基本都能解决问题。

4.proton版本openvswitch内核模块不能自动加载

 这个和前面的问题类似，也是因为proton版本下dpdk节点和非dpdk节点需要安装不同的ovs版本造成。

 ovs的dpdk版本，我们是直接使用systemd服务来启动，进程的启动参数，需要哪些前置条件全部是我们自己控制的。该服务在处理的时候，我们大部分考虑的是dpdk节点的问题，

 在dpdk节点上，我们使用的是user space模式，此时是可以不用安装openvswitch.ko这个内核模块。因此，我们在ovs的服务启动脚本中也不会去判断这个内核模块有没有加载，

 当然更不会去自动加载该服务。

 所以如果碰到这个问题，一般表明你装错版本了:(

再来说说dpdk的那些坑事儿

1. 如果你在使用命令行echo 4 > /sys/class/net/eth1/device/sriov_numvfs分配VF的时候报了个错误Permission denied，那你就要去查一下该网卡的datasheet，很大的可能这种网卡不支持VF功能。

2. 如果分配网VF后，发现分多了或少了，想重新调整，此时一定需要先做这个事情：echo 0 > /sys/class/net/eth1/device/sriov_numvfs

  就是先将PF的VF网卡数目降为0，再重新echo一个正数，否则是无法直接调整的。

3. 当VF分配出来后，此时我们用ip link list，除了能看到类似

  eth1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1600 qdisc mq master bond1 state UP mode DEFAULT group default qlen 1000

    link/ether 24:6e:96:4b:86:d0 brd ff:ff:ff:ff:ff:ff

    vf 0 MAC fa:65:0a:33:d9:d9, vlan 101, spoof checking on, link-state auto, trust off, query_rss off, query_rss off

    vf 1 MAC fe:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off, query_rss off, query_rss off

    vf 2 MAC aa:e4:8a:33:e3:c8, spoof checking on, link-state auto, trust off, query_rss off, query_rss off

 还应该能看到类似这种名字的网卡（网卡名字如何命名的，可以参考文档

 https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/networking_guide/sec-understanding_the_device_renaming_procedure）

 65: enp1s21f7: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000

    link/ether fa:f9:87:5c:e0:5a brd ff:ff:ff:ff:ff:ff

 66: enp1s22f1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000

    link/ether 1e:7f:33:77:3d:df brd ff:ff:ff:ff:ff:ff

 67: enp1s22f3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000

    link/ether 1e:15:70:74:b9:78 brd ff:ff:ff:ff:ff:ff

 但我们有时也会发现看不到这些网卡，只能看到vf 0/vf 1等等，那这些网卡哪里去了？

 其实网卡并没有消失，只不过是因为换了驱动，不显示了而已。

 通过命令行 ls -l /sys/class/net/eth0/device/ 你能看到每个vf的pci bus号，比如

 lrwxrwxrwx 1 root root        0 Dec 14 15:28 virtfn0 -> ../0000:05:02.0

lrwxrwxrwx 1 root root        0 Dec 14 15:28 virtfn1 -> ../0000:05:02.1

lrwxrwxrwx 1 root root        0 Dec 14 15:28 virtfn2 -> ../0000:05:02.2

lrwxrwxrwx 1 root root        0 Dec 14 15:28 virtfn3 -> ../0000:05:02.3

 这是一个软链接，进入链接后，发现到了目录/sys/bus/pci/devices/0000:05:02.0， 此时再ls -l driver,发现指向了

lrwxrwxrwx 1 root root 0 Dec 14 15:40 driver -> ../../../../bus/pci/drivers/vfio-pci

请注意：vfio-pci的驱动是无法让你看到网卡名字的，如果想重新看到，就需要通过工具改网卡驱动，比如dpdk-devbind。

通过重新改成ixgbevf(82599 VF)，i40evf(XL710 VF)就可以重新看到网卡名字啦。这个对于想要使用VF加入namespace来模拟虚拟机的人来说还是挺有用的。

4. PF或者VF上设置vlan失败

一般是因为设置网卡的数量超出了。此时可以查看你网卡的datasheet，一般都有说明，比如82599网卡最多允许设置64个vlan。

5.VF上无法接收或者发送报

 这种情况一般报文是被网卡的vlan filter或者mac filter过滤了。

 82599网卡在初始化的时候默认给VF使能了spoof check功能，PF则默认将该功能关闭。（其他网卡没调研过，不确认是否还是这个特性）

 一旦该功能开启，则在发送的时候会检查mac filter，只要发出或者接收的smac不在mac filter之内，则必然丢弃报文。

 而在接收的时候会另外检查一个特性，就是vlan filter。

 因此，对于VF来说，如果发送的时候报文的smac不等于VF的mac，则会丢包；接收的时候如果vlan不在VF允许的范围内，则会丢包，macda不是VF的mac 地址，也会丢包；

 对于PF来说，至少source mac是不会受限制的。

 如果想关闭该功能，也很简单，使用命令 ip link set eth0 vf 0 spoofchk off 就可以啦。建议没有特殊需要不要关闭该功能。

6.设置VF的mac失败，即使将vf的trust on置上也不行

 一般如果遇到一些莫名其妙的问题，升级网卡驱动是个可行的方法:)

7.hugepage不生效了

 设置hugepage的方法有很多，hugepage本身分成多种，比如2M的，4M的以及1GB的。社区推荐如果支持1GB的hugepage，尽量在使用dpdk的时候用1GB的page。

 1GB的hugepage通常在bios启动选项里设置，比如default_hugepagesz=1G hugepagesz=1G hugepages=16

 但是之前SA使用的hugepage都是2M的，配置在/etc/sysctl.d/hugepages.conf中（vm.nr_hugepages=2048）

 这里的配置会覆盖你在bios中的设置，导致使用的size是1GB，而huges确是vm.nr_hugepages。 那么按照上述配置，显然我们的物理机根本没那么多内存可用。

 此时就会发现cat /proc/meminfo|grep Huge几乎用光了你所有的内存，而不是你在bios里设置的那个值。

 建议不同的分配hugepage的方式不要同时使用，一定要同时使用的话，一定要做到心中有数。

 想知道更多具体的信息可以参考文档https://www.kernel.org/doc/Documentation/vm/hugetlbpage.txt

8.dpdk网卡性能怎么也无法上去

 也许很多人根本就没关注过，在编译的时候加上参数-g3 -O0虽然可以让调试很方便，但是却大大降低了性能。

 将该编译选项关闭，你想要的性能数据都能给你:)