testpmd 可以转发 l2fwd不能转发是什么情况

2020-01-14 转载【dpdk】使用libpcap-PMD驱动收发包

https://doc.dpdk.org/guides/nics/pcap_ring.html

ovs-dpdk-docker部署VNF实践

关于docker的基本概念相关，可以参考 官网介绍 ，介绍的挺全面的。另外这篇 文章 介绍的也很清晰，并附带有可以直接上手的实例。
关于container和vm的对比，需要重点关注下，直接放图如下：
由于我们公司大多的产品都是基于dpdk框架来实现，所以选取在docker中部署dpdk来进行预研。目前dpdk官网提供两种方案来支持container，如下图：
[图片上传失败...(image-848e3f-1591447286699)]
上图(1) 方案中需要NIC支持SR-IOV功能，物理NIC支持的VF个数也依赖于硬件资源；每个container的接口独占VF，多个VF共享下面的一个PF。基于这种方案实现的container，无论对硬件的依赖和绑定，还是container的迁移，支持性都做得不够好。
上图(2) 方案中需要在host中运行vswitch或者vRouter来将上层的containers和底层的物理NIC解耦，只要vswitch（当前比较流行的OVS+DPDK，将OVS放在用户态来实现）的性能足够，一样可以实现高性能的container app了。
基于以上比较，本次预研主要选取第二种方案来实现，该方案中container中涉及的组件如下图所示：
[图片上传失败...(image-36e69c-1591447286699)]
方案中使用virtual device(包括virtio-user和vhost-user backend）来实现高性能的container App 或者IPC。Virtio使用共享内存的方式来收发报文，传统的VM可以通过qemu来共享vhost后端的物理地址，但对container而言，作为系统的一个进程，使用这种方式则比较难。目前的思路是只能使用DPDK初始化的hugepages来进行内存共享。所以，要在container中使用dpdk，必须要分配足够的大页内存，且不同container在使用共享内存时要能够分区使用，避免地址重复。
hugepage的配置(配置使用1G大小的hugepagesize,同时最多分配8个)：
pktgen的安装依赖于DPDK，安装前确保RTE_SDK和RTE_TARGET环境变量设置正确。
可以检查系统配置如下：
至此ovs就启动并配置好了，vhost-user backend口已经创建好，相应的流表路由表项也已经添加好，接下来就该部署container了。
l2fwd和testpmd都属于dpdk提供的app，使用同一个container即可。创建container时把之前build的dpdk目录copy到docker中。
同理，把之前编译好的pktgen映射到container中即可。此外需要注意的是，pktgen依赖libpcap，所以需要在container中安装一份。使用时还发现运行container提示无法找到共享库libpcap.so.1, 而安装libpcap后只有libpcap.so,解决办法就是做个软链就可以了。
具体的配置步骤如下：
pktgen端：
pktgen端：
说明l2fwd已按照我们的预想进行了报文的转发。
本次预研实践主要还是集中在OVS上面的container App的互通以及container内部对dpdk的支持，分别验证了在container内部运行testpmd和l2fwd来进行报文转发。其中，dpdk app的运行模式可以为后续cneos平台server docker化提供一定的技术指导作用。
如果从更系统化的层面来考虑docker结合ovs以及dpdk的使用，更通用的使用场景应该是这样的：在ovs的南向通过dpdk pmd和硬件平台上物理nic的PF或VF绑定，高速收发报文；在ovs的北向，通过virtual device和docker container来共享收发报文，进行上层业务的处理。 南北向之间的流量需要配置flow table来指导转发。流量示意如下图所示：

标签：未分类 驱动 信息技术 互联网 编程语言