深入浅出DPDK学习笔记（6）———报文转发

最新推荐文章于 2025-05-21 10:56:21 发布

原创

最新推荐文章于 2025-05-21 10:56:21 发布 · 4k 阅读

7 ·

CC 4.0 BY-SA版权

文章标签：

#dpdk

报文转发

网络处理模块划分
转发框架介绍
转发算法

网络处理模块划分

网络报文的处理和转发主要分为硬件处理部分与软件处理部分,以下模块构成:
·Packet input:报文输入。
·Pre-processing:对报文进行比较粗粒度的处理。
·Input classification:对报文进行较细粒度的分流。
·Ingress queuing:提供基于描述符的队列FIFO。
·Delivery/Scheduling:根据队列优先级和CPU状态进行调度。
·Accelerator:提供加解密和压缩/解压缩等硬件功能。
·Egress queueing:在出口上根据QOS等级进行调度。
·Post processing:后期报文处理释放缓存。
·Packet output:从硬件上发送出去。
如图5-1所示,我们可以看到在浅色和阴影对应的模块都是和硬件相关的,因此要提升这部分性能的最佳选择就是尽量多地去选择网卡上或网络设备芯片上所提供的一些和网络特定功能相关的卸载的特性,而在深色软件部分可以通过提高算法的效率和结合CPU相关的并行指令来提升网络性能。了解了网络处理模块的基本组成部分后,我们再来看不同的转发框架下如何让这些模块协同工作完成网络包处理。
网络处理模块细分

转发框架介绍

传统的Network Processor(专用网络处理器)转发的模型可以分为 run to completion ( 运行至终结 , 简称 RTC ) 模型和pipeline(流水线)模型。

pipeline模型

从名字上,就可以看出pipeline模型借鉴于工业上的流水线模型,将一个功能(大于模块级的功能)分解成多个独立的阶段,不同阶段间通过队列传递产品。这样,对于一些CPU密集和I/O密集的应用,通过pipeline模型,我们可以把CPU密集的操作放在一个微处理引擎上执行,将I/O密集的操作放在另外一个微处理引擎上执行。通过过滤器可以为不同的操作分配不同的线程,通过连接两者的队列匹配两者的处理速度,从而达到最好的并发效率。

run to completion模型

run to completion(运行至终结)模型是主要针对DPDK一般程序的运行方法,一个程序中一般会分为几个不同的逻辑功能,但是这几个逻辑功能会在一个CPU的核上运行,我们可以进行水平扩展使得在SMP的系统中多个核上执行一样逻辑的程序,从而提高单位时间内事务处理的量。但是由于每个核上的处理能力其实都是一样的,并没有针对某个逻辑功能进行优化,因此在这个层面上与pipeline模型比较,run to completion模型是不高效的。
DPDK转发模型
从图5-4a的run to completion的模型中,我们可以清楚地看出,每个IA的物理核都负责处理整个报文的生命周期从RX到TX。
在图5-4b的pipeline模型中可以看出,报文的处理被划分成不同的逻辑功能单元A、B、C,一个报文需分别经历A、B、C三个阶段,这三个阶段的功能单元可以不止一个并且可以分布在不同的物理核上,不同的功能单元可以分布在相同的核上(也可以分布在不同的核上)。以下我们来看DPDK中这两种方法的优缺点。
DPDK RTC与pipeline的比较

DPDK run to completion模型

普通的Linux网络驱动中的扩展方法如下:把不同的收发包队列对应的中断转发到指定核的local APIC(本地中断控制器)上,并且使得每个核响应一个中断,从而处理此中断对应的队列集合中的相关报文。而在DPDK的轮询模式中主要通过一些DPDK中eal中的参数-c、-l、-l core s来设置哪些核可以被DPDK使用,最后再把处理对应收发队列的线程绑定到对应的核上。每个报文的整个生命周期都只可能在其中一个线程中出现。和普通网络处理器的run to completion的模式相比 , 基于 IA 平台的通用 CPU 也有不少的计算资源 , 比如一个socket上面可以有独立运行的16运算单元(核),每个核上面可以有两个逻辑运算单元(thread)共享物理的运算单元。而多个socket可以通过QPI总线连接在一起,这样使得每一个运算单元都可以独立地处理一个报文并且通用处理器上的编程更加简单高效,在快速开发网络功能的同时,利用硬件AES-NI、SHA-NI等特殊指令可以加速网络相关加解密和认证功能。运行到终结功能虽然有许多优势,但是针对单个报文的处理始终集中在一个逻辑单元上,无法利用其他运算单元,并且逻辑的耦合性太强,而流水线模型正好解决了以上的问题。下面我们来看DPDK的流水线模型,DPDK中称为Packet Framework。

DPDK pipeline模型

pipeline的主要思想就是不同的工作交给不同的模块,而每一个模块都是一个处理引擎,每个处理引擎都只单独处理特定的事务,每个处理引擎都有输入和输出,通过这些输入和输出将不同的处理引擎连接起来,完成复杂的网络功能,DPDK pipeline的多处理引擎实例和每个处理引擎中的组成框图可见图5-5中两个实例的图片:zoom out(多核应用框架)和zoom in(单个流水线模块)。

Zoom out的实例中包含了五个DPDK pipeline处理模块,每个pipeline作为一个特定功能的包处理模块。一个报文从进入到发送,会有两个不同的路径,上面的路径有三个模块(解析、分类、发送),下面的路径有四个模块(解析、查表、修改、发送)。Zoom in的图示中代表在查表的pipeline中有两张查找表,报文根据不同的条件可以通过一级表或两级表的查询从不同的端口发送出去。
此外,从图5-5中的pipeline level我们知道,DPDK的pipeline是由三大部分组成的,逻辑端口(port)、查找表(table)和处理逻辑(action)。DPDK的pipeline模型中把网络端口作为每个处理模块的输入,所有的报文输入都通过这个端口来进行报文的输入。查找表是每个处理模块中重要的处理逻辑核心,不同的查找表就提供了不同的处理方法。而转发逻辑指明了报文的流向和处理,而这三大部分中的主要类型可参见表5-3。
DPDK Port、Table、Action支持的类型
用户可以根据以上三大类构建数据自己的pipeline,然后把每个pipeline都绑定在指定的核上从而使得我们能快速搭建属于我们自己的packet framework。
现在DPDK支持的pipeline有以下几种:
·Packet I/O
·Flow classification
·Firewall
·Routing
·Metering
·Traffic Mgmt
DPDK以上的几个pipeline都是DPDK在packet framework中直接提供给用户的,用户可以通过简单的配置文件去利用这些现成的pipeline,加快开发速度。
以Routing pipeline为例可以有以下构建形式:
关于具体如何使用DPDK的packet framework去快速搭建属于自己的高性能网络应用,可以参考DPDK源码中的sample。
DPDK Routing Pipeline