DPDK capture原理

本文主要介绍DPDK框架下进行报文捕获的方法，并对各种方法的优劣进行简单分析。

1.pdump库的使用

在DPDK的16.07版本中，添加了Packet capture特性，通过pdump库可以非常方便的进行报文的捕获：
a) 在程序初始化过程中调用rte_pdump_init，启动dump_thread进行消息的监听：
#ifdef RTE_LIBRTE_PDUMP
/* initialize packet capture framework /
rte_pdump_init(NULL);
#endif
b) 在程序退出前调用rte_pdump_uninit进行资源的释放：
#ifdef RTE_LIBRTE_PDUMP
/ uninitialize packet capture framework */
rte_pdump_uninit();
#endif
c) 启动pdump程序，发送抓包命令，进行抓包。

基本流程与数据流如下所示：

pdump capture.png

步骤详细说明：

1. A采用rx-worker-tx的模型进行报文的处理，其中调用rte_pdump_init会启动dump_thread，即图中红色的message线程；

2. pdump采用secondary模式启动，与A共享mmap映射的内存空间；
3. pdump启动过程中会创建mbuf_pool和ring，用于后续接收A中报文的拷贝；
4. pdump会通过rte_eth_dev_attach方式创建vdev，且采用eth_pcap驱动进行初始化，留意init中的open_tx_pcap；
5. pdump向A发送开启抓包的消息（UDP方式），消息内容为前面创建的mbuf_pool、ring以及抓包的port和对应的queue；
6. A中的dump_thread收到消息后，获取相应信息，在port上注册call_back函数；
7. 对于开启抓包的port，在rx_burst/tx_burst时会先调用call_back，这里对应pdump_rx/pdump_tx，它会由mbuf_pool中分配mbuf进行报文的复制，同时enqueue到ring中；（mbuf_pool和ring在步骤3中创建，在步骤5中传递给A）
8. pdump进行ring的dequeue操作获取拷贝报文；
9. 拷贝报文通过rte_eth_tx_burst发送给vdev；
10. vdev通过eth_pcap的tx_pkt_burst发送报文，即调用eth_pcap_tx_dumper完成报文的pcap存储（pcap_dump）。

2.KNI方式

kNI，全称 Kernel NIC Interface，下面是DPDK官方手册对它的介绍：

The Kernel NIC Interface (KNI) is a DPDK control plane solution that allows userspace applications to exchange packets with the kernel networking stack.

这里对data plane和control plane进行简单说明：
data plane专注于报文的转发；control plane专注于协议处理，如ospf计算。如果采用DPDK架构，那么就会遇到如下问题：

不论是协议报文还是数据报文通过port接收后，都到了data plane，data plane如何将协议报文交给control plane呢？
control plane（往往不是DPDK程序）与网络设备进行协议交互时，报文又如何投递给port发送出去呢？

KNI就是control plane与data plane间的桥梁：加载rte_kni.ko驱动后，Linux内核响应DPDK程序中发送的IOCTL消息创建虚拟接口并转换FIFO地址用于后续的报文交互。

在DPDK提供pdump特性前，对报文抓取主要就是采用KNI方式：
a) DPDK程序创建虚拟接口；
b) 将收到的报文发送给虚拟接口；
c) 启用类似tcpdump的工具抓取虚拟接口上的报文。

基本流程和数据流如下：

kni capture.png

步骤详细说明：

1. A启动时候，创建mbuf_pool，指定kthread的绑定方式，然后通过调用rte_kni_alloc创建FIFO队列，并发送IOCTL消息创建vEth；

2. IOCTL消息处理时，既会创建vEth，同时也会启动ktread_kni内核线程，这个线程用于将A中的报文发送给内核协议栈（在其它场景中，也可以将内核发送给vEth的报文通过tx_q传递给A：kni_net_tx）；
3. A可以实现一个message线程，用于接收类似PDUMP进程的消息来开启抓包；
4. 启动自定义的PDUMP程序，发送抓包命令；
5. 消息传递可以采用进程间通信机制，消息格式自行定义；
6. A中判断报文是否需要dump，如果需要dump，则将报文clone后通过rte_kni_tx_burst传递给内部的rx_q队列；
7. kthread_kni内核线程调用kni_net_rx，获取rx_q中的报文；
8. 报文获取后，转换为skb，设置skb的dev为vEth，然后通过netif_rx_ni交给内核协议栈。这时tcpdump就可抓获传递到vEth的报文了。

图中省略了操作前的insmod rte_kni.ko和最后的tcpdump工具使用。

3.用户态实现报文捕获和dump

一般DPDK程序作为data plane使用，在部分设计过程中，则将DPDK框架用于旁路部署，进行高性能抓包，相关设计可以参考：
github上的项目：https://github.com/Woutifier/dpdkcap
科来的专利：http://www.google.com/patents/CN105357151A?cl=zh

如果是串接或单臂模式这样的data plane程序，在DPDK框架中进行报文的捕获和dump操作是不合时宜的，因为它对程序自身的转发性能影响非常大，而且增加了设计复杂度。

说明：上文中的A，指采用DPDK框架的primary进程，不同的转发模型中它包含不同的线程。

4.优劣比较

a) pdump库使用方便，性能高（仅有一次copy，步骤7）；不过它在16.07才支持，低版本不支持，且16.07版本中还不支持filter；
b) KNI方式，需要创建thread，性能应该略低于pdump（KNI内部fifo处理有一定开销），开发工作较多，但可以自行实现过滤功能，相比pdump的全copy在某些场景会更适用，且使用tcpdump抓取在运维上更方便；
c) pdump方式，拷贝由port的驱动完成，dump到文件则由pdump程序完成；KNI方式，拷贝在用户态空间完成，发送到内核态后，dump到文件则有tcpdump完成；在DPDK框架中进行报文捕获和dump，仅推荐用于旁路抓包。

本文对DPDK的抓包原理进行了简单介绍，并比较了各种方式的优劣，对于抓包的具体设计和性能权衡则没有做过多的探究，希望对大家能有所帮助。