bob的博客

mbuf表示memory buffer或message buffer, 是DPDK中非常重要的数据结构, 一般用于存放网卡收发的报文, 但也可以用于存储控制消息, 事件等各种数据.本文基于DPDK 17.11版本的mbuf实现进行描述与编码.1 设计思想1.1 存储mbuf主要由元信息和数据两部分组成, 这两部分存放在一个连续的内存块中. 元信息和数据的关系类似于TCP/IP协议首部与协议数据的关系, 其中元信息描述了数据的属性, 如报文类型, 数据长度与起始地址, RSS hash值等等.mbu

不同的PMD可能需要不同的内核驱动程序才能正常工作。根据所用的PMD，应加载相应的内核驱动程序并将其绑定到网络端口。1、UIO一个小的内核模块，用于设置设备，将设备内存映射到用户空间并注册中断。在许多情况下，Linux内核中包含的标准uio_pci_generic模块可以提供uio功能。可以使用以下命令加载该模块：sudo modprobe uio_pci_generic注意：uio_pci_generic模块不支持虚拟函数的创建。作为uio_pci_generic的替代，DPDK还包括i

1、安装DPDK和源代码首先，解压DPDK源码包unzip DPDK-<version>.zipcd DPDK-<version>lsapp/ config/ examples/ lib/ LICENSE.GPL LICENSE.LGPL Makefilemk/ scripts/ tools/DPDK目录组成lib: DPDK库源码drivers：DPDK PMD源码app：DPDK应用（自动测试）源码examples：DPDK应用例子config、to

什么是Vhost/VirtioVhost/Virtio是一种半虚拟化的设备抽象接口规范， 在Qemu和KVM中的得到了广泛的应用，在客户机操作系统中实现的前端驱动程序一般直接叫Virtio， 在宿主机实现的后端驱动程序称为Vhost。与宿主机纯软件模拟I/O相比，virtio可以获得很好的性能，在数据中心中得到了广泛的应用。Linux kernel中已经提供了相应的设备驱动，分别是virtio-net，以及vhost-net，DPDK项目为了提高数据吞吐性能，相对应的，提供了Virtio的用户态驱动vir

X86体系早期没有在硬件设计上对虚拟化提供支持，因此虚拟化完全通过软件实现。一个典型的做法是通过优先级压缩（Ring Compression)和二进制代码翻译（Binary Translation)相结合，VMM在特权级ring 0, Guest操作系统在非特权级ring 1, Guest应用程序在ring 3。 由于Guest操作系统工作在非特权级ring 1中，这样当它执行特权指令时就会触发异常，由VMM截获异常并采用软件方式模拟指令并返回。 但由于X86体系在设计之初没有考虑虚拟化，所以一小部分特权指

本文会重点讨论下vhost pmd和lib库中的api如何使用。在前面的章节中描述过virtio-net设备的生命周期包括设备创建、配置、服务启动和设备销毁几个阶段。我们先回忆下整个生命周期：设备创建 vhost-user通过socket连接来创建。当创建一个virtio-net设备是，需要:分配新的virtio-net设备结构，并添加到设备链表中为该设备分配一个处理处理核并添加设备到数据面的链表中在vhost上分配一个为virtio-net设备服务的RX\TX队列配置利用VHOST

Virtio/Vhost是什么Vhost/Virtio是一种半虚拟化的设备抽象接口规范， 在Qemu和KVM中的得到了广泛的应用，在客户机操作系统中实现的前端驱动程序一般直接叫Virtio， 在宿主机实现的后端驱动程序称为Vhost。与宿主机纯软件模拟I/O相比，virtio可以获得很好的性能，在数据中心中得到了广泛的应用。Vhost有两种实现：内核态和用户态内核态实现vhost_net将部分的Virtio驱动从用户空间(其实是QEMU中)移到了kernel中，从而跳过QEMU，减少QEMU和内核之

所谓前后端通知，必然涉及两个方向：前端通知后端，后端通知前端。而我们知道vhost有txq和rxq，对于每种queue都伴随有这两种通知。而通知方式又根据是否支持event_idx有着不同的实现，最后virtio1.1引入的packed ring后，通知相对split ring又有不同。下面我们以txq，rxq的两个方向共四种情况来分析前后端的通知实现。其中前端以kernel4.9 virtio_net实现为例分析，后端以dpdk 18.11 vhost_user实现分析。在展开前后端通知分析前，我们先了解

消息机制当使用vhost-user时，需要在系统中创建一个unix domain socket server，用来处理qemu发送给host的消息。如果有新的socket连接，说明guest创建了新的virtio-net设备，vhost驱动会为之创建一个vhost设备，之后qemu就可以通过socket和vhost进行通信了；当socket关闭，vhost就会销毁对应的设备。常用的消息包括：//driver\net\virtio\virtio_user\vhost_kernel.c/* vhost

这里在分析一下guset内部对于开启mergeable接收会有什么影响，顺便分析一下开启GUEST_GSO/GUEST_TSO时，guset内部的接收流程。首先我们从vhost-user，发送端分析一下，两种情况是如何更新used->ring的。mergeable情况在reserve_avail_buf_mergeable（dpdk代码）函数中有一下逻辑：/*fill_vec_buf的作用是找一个desc chain，用来存放mbuf，然后buf_vec记录这些desc的信息*/

vhost_user在收包时（将数据包发往vm内部）会调用rte_vhost_enqueue_burst函数，这个函数的实现如下：rte_vhost_enqueue_burstuint16_t rte_vhost_enqueue_burst(int vid, uint16_t queue_id, struct rte_mbuf **pkts, uint16_t count){ struct virtio_net *dev = get_device(vid);

virtio1.1已经在新的kernel和dpdk pmd中陆续支持，但是网上关于这一块的介绍却比较少，唯一描述多一点的就是这个ppt：https://www.dpdk.org/wp-content/uploads/sites/35/2018/09/virtio-1.1_v4.pdf 。但是看ppt这东西总觉得还是不过瘾的。只是模糊的大概理解，但要想看清其本质还是要看代码。这篇文章主要是基于dpdk18.11中的vhost_user来分析virtio1.1具有哪些新特性，已经具体是如何工作的。virtio

Vhost库实现了一个用户空间virtio网络服务器，允许用户直接操作virtio。 换句话说，它允许用户通过VM virtio网络设备获取/发送数据包。 为了达到这个功能，一个vhost库需要实现：访问guest内存：对于QEMU，这是通过使用 -object memory-backend-file,share=on,… 选项实现的。这意味着QEMU将创建一个文件作为guest RAM。 选项 share=on 允许另一个进程映射该文件，这意味着该进程可以访问这个guest RAM。知道关于vr

vhost-user是vhost-kernel又回到用户空间的实现，其基本思想和vhost-kernel很类似，不过之前在内核的部分现在有另外一个用户进程代替，可能是snapp或者dpdk等。在网上看相关资料较少，就简单介绍下。虽然和vhost-kernel实现的目标一致，但是具体的实现方式却有所不同。vhost-user下，UNIX本地socket代替了之前kernel模式下的设备文件进行进程间的通信（qemu和vhost-user app）,而通过mmap的方式把ram映射到vhost-user app

dpdk自己实现了一个中断机制，例如定时器中断，uio中断。这个中断是应用层中断， 而不是像linux内核实现的硬件中断； 且dpdk实现的中断机制属于控制中断，用来实现一些控制操作，例如uio中断用来设置一些网卡的状态之类。网卡收发包过程，还是使用轮询的方式从网卡接收报文。一、中断事件管理dpdk实现了uio, 定时器alarm, vfio三种中断，且用链表来管理这些中断源。当应用层需要设置中断时， 设置好中断的触发回调后就可以调用rte_intr_callback_register接口注册一个中断源

基本的网络包处理主要包含：Packet input：报文输入。Pre-processing：对报文进行比较粗粒度的处理。Input classification：对报文进行较细粒度的分流。Ingress queuing：提供基于描述符的队列FIFO。Delivery/Scheduling：根据队列优先级和CPU状态进行调度。Accelerator：提供加解密和压缩/解压缩等硬件功能。Egress queueing：在出口上根据QOS等级进行调度。Post processing：后期报文处

一、为什么要用kni通常情况下dpdk用于二三层报文转发，接收到来自网卡的报文后，如果是二层报文则查找fdb表； 如果是三层报文，则进行dnat, snat处理后，查找路由表， 将报文转发给下一跳路由。这些二三层转发操作都是直接转发到另一台设备上，不需要经过内核，无需内核协议栈的参与。然而有些场景下报文是直接发给运行dpdk程序的这台设备本身的。例如ping运行dpdk程序这台设备；或者访问dpdk程序这台设备上运行的nginx服务器， ftp服务器，smtp邮件服务器等等。 这些操作都是发给运行dpd

dpdk可以通过两种方式来管理内存， 一种是调用rte_malloc， 在大页内存上申请空间； 另一种是使用内存池，也是通过在大页内存上申请空间方式。 两种有什么区别呢？虽然两者最终都是在大页内存上获取空间，但内存池这种方式直接在大页内存上获取，绕开了rte_malloc调用。rte_malloc一般用于申请小的内存空间。通常在需要非常大的缓冲区时，在大页内存上一次性申请一个大的缓冲区， 当做内存池，从而提高性能。一、内存池的使用内存池的使用非常简单，直接调用三个接口就好了。应用程序可以调用rte_me

dpdk用户态驱动初始化完成后，应用层就可以来对网卡进行设置操作。对于每一个网卡，应用层都需要调用相应接口进行配置。可以对网卡进行哪些设置操作呢？ 例如应用层将对网卡进行配置下发，将配置信息下发给网卡；应用层对网卡接收队列进行设置；应用层对网卡发送队列进行设置； 应用层启动网卡等操作。以l2fwd为例， 应用层调用rte_eth_dev_configure进行配置下发； 调用rte_eth_rx_queue_setup对网卡接收队列进行设置； 调用rte_eth_tx_queue_setup对网卡发送队列进

上一篇文件介绍了linux内存管理以及大页内存的原理，有了原理的支撑，接下里分析dpdk大页内存源码就轻松了，才不会云里雾里不知道在说啥。所谓的dpdk大页内存的实现，说白了就是dpdk自己实现了一套大页内存的使用库，这个和libhugetlbfs.so是类似的，就是自己实现了大页内存的申请，释放操作, 替代了传统的malloc, free系统调用。先从整体上看下dpdk大页内存有哪些内容。当应用层需要申请内存时，直接调用rte_malloc接口进行内存申请； 而rte_malloc实际上是从memzo

在分析dpdk大页内存的源码之前，有必要对linux内存管理的原理以及大页内存的原理有个了解，缺少这些底层基础知识，分析dpdk大页内存的源码将举步维艰。这篇文章详细介绍下linux内存管理以及大页内存的方方面面，为分析dpdk大页内存源码扫除障碍。一、linux内存管理原理1、mmu内存管理的引入在没有引入mmu内存管理单元时，对于32位操作系统，每个进程都有2的32次方的地址空间(4G)。如果进程A占用内存0x1000—0x2000物理地址空间， 而进程B也占用内存0x1000—0x2000物理地

一、dpdk uio驱动框架

在没有引入pmd用户态网卡驱动之前， 网卡在收到报文后，网卡驱动会将报文从网卡缓冲区拷贝到内核， 接着内核在把报文拷贝到应用层，整个过程需要2次的拷贝以及系统调用。当应用层需要发送数据时，应用层将报文拷贝到内核，接着内核拷贝到网卡缓冲区，由网卡负责发送，整个过程也需要2次的拷贝以及系统调用。 不管接收还是发送报文，系统调用以及内存拷贝都是需要消耗性能的。 在引入了pmd用户态驱动后，情况就完全不一样了。pmd为用户态驱动，这是应用层自己实现的一个网卡驱动程序，运行在应用层， 网络报文不经过内核，相当于把内核

上一篇文章已经介绍了pci设备的背景知识， 现在我们来分析下pci设备是如何探测到支持的驱动，进而与驱动进行关联；pci与驱动的解除绑定；pci设备与uio设备的关联。一、pci驱动注册网卡驱动的注册使用了一种奇技淫巧的方法，使用GCC attribute扩展属性的constructor属性，使得网卡驱动的注册在程序main函数之前就执行了。此时在main函数执行前，就已经把系统支持的驱动通过rte_eal_driver_register注册到驱动链表dev_driver_list中。struct

一、pci设备背景知识传统的sata，是一种 半双工设备， 同一时间只能有一个方向在传输数据，传输速率就比较慢了。pci设备是一种全双工设备， 同一时间可以发送数据到其他pci设备，也可以接收来自其他pci设备的数据。1、pci总线在系统加载的时候，会将所有的pci设备给挂载到pci总线上，并在/sys/bus/pci/devices目录下创建所有的pci设备文件。从上图可以看出，pci总线与pci设备之间是一颗树形结构。可以通过pci桥来扩展系统总线，从而可以支持更多的pci设备，这个pci桥和u

一、报文的接收流程传统方式接收报文时，当网卡接收到报文后会产生硬件中断，进而报文会通过协议栈，最后到达应用层，这个过程需要内核协议栈的处理。 和传统报文接收不同，当应用层想要接收来自网卡的报文时， 应用层通过while死循环的方式，调用rte_eth_rx_burst接口轮询接收来自网卡的报文，相当于绕过了内核协议栈，将内核旁路了。通过轮询的方式，报文不经过内核，提高了网络转发性能，同时也降低了内核与用户态系统调用的开销。来看下报文接收的整体流程。当网卡接收到报文时将会产生硬件中断，通知dma控制器接收

内核组件架构rte_eal+libc：内存的统一组织管理者，但是在这它不只是做内存工作。librte_malloc：对外提供分配释放内存的API，分配的内存都是rte_eal中所管理的内存。librte_ring：提供无锁队列，它使用了rte_eal管理的内存。librte_mempool：利用rte_eal管理的内存和rte_ring提供内存池的功能。librte_mbuf：提供dpdk应用程序数据存储释放操作的一系列接口。librte_timer：提供时间操作的接口，主要用于各种服务间同

一些基本的概念EAL首先必须明白的一点就是， DPDK 是以若干个 lib 的形式提供给应用链接使用，其中最终要的一个 lib 就是 EAL 了， EAL 的全称是(Environment Abstraction Layer, 环境抽象层)，它负责为应用间接访问底层的资源，比如内存空间、线程、设备、定时器等。如果把我们的应用比作一个豪宅的主人的话， EAL 就是这个豪宅的管家。lcore & socket这两个概念在 DPDK 的代码中随处可见， 注意 这里的 socket 不是网络编程里面

摘要intel dpdk 的makefile 写的很好，该好好学习他的这种架构，但在调试程序时候发现，它的编译选项优化级别很高；怎样去修改intel dpdk中的编译选项，达到自己一个一个满意的程度；其大部分makefile规则都定义在dpdk/mk目录下；最后再说一下怎样用gdb工具调试dpdk；# ls mk/arch rte.app.mk rte.extshared.mk rte.hostlib.mk rte.obj.mk rte.sdkdoc.mk

一、构建系统提供的有用的变量RTE_SDK： DPDK源码包的绝对路径。编译开发套件时框架会自动设置。当编译外部应用时，用户必须定义这个环境变量。RTE_SRCDIR： 源码的路径。当编译开发套件时RTE_SRCDIR等于RTE_SDK。编译外部应用时则指向外部应用的源码目录。RTE_OUTPUT： 输出文件的路径。通常情况下是$(RTE_SRCDIR)/build，通过make命令的O=选项可以重写该变量。RTE_TARGET：一个标识了编译目标的字符串。格式为arch-machine-exec

DPDK是INTEL公司开发的一款高性能的网络驱动组件，旨在为数据面应用程序提供一个简单方便的，完整的，快速的数据包处理解决方案，主要技术有用户态、轮询取代中断、零拷贝、网卡RSS、访存DirectIO等。1、UIO（Linux Userspace I/O）支持，提供应用空间下驱动程序的支持，也就是说网卡驱动是运行在用户空间的，减下了报文在用户空间和应用空间的多次拷贝。DPDK总体架构：...