DPDK之eventdev_pipeline源码解析
引言
DPDK Eventdev库是DPDK基于事件驱动的编程模型。其中eventdev_pipeline实现了对该模型的应用例子。
参考源码版本: dpdk-stable-22.11.1
1 实现原理
整个eventdev有两个关键的概念,即event queue与event port。event queue是存放事件的队列,当网卡或CPU产生一个事件最终会放到事件队列中待消费者取出来执行;此外,DPDK Eventdev架构不能直接对event queue进行enqueue或dequeue操作,只能通过event port放入事件和获取事件,然后eventdev内部实现从event port关联(或者说link)的event queue进行dequeue操作(即link确定了port可以取哪些queue的事件)。一般地,Queue与业务处理阶段有关;Port与处理核对应。
假设我们做基于UDP的一个网络回复程序:那么我们可以将业务处理阶段划分为如下几步:
- 读取以太网数据;
- 解析数据包;
- 根据请求内容,确定返回内容;
- 封装返回数据包;
- 发送以太网数据。
注1 : 当网络设备具备RTE_EVENT_ETH_RX_ADAPTER_CAP_INTERNAL_PORT能力,由网络硬件实现接受数据,CPU只需要通过rte_event_eth_rx_adapter_queue_add设置好接收到数据包需放入的工作队列ID;
注2 : 当网络设备具备RTE_EVENT_ETH_TX_ADAPTER_CAP_INTERNAL_PORT能力,由网络硬件实现发送数据的功能,CPU只需要设置struct rte_mbuf的dst_addr和hash.txadapter.txq两个字段即可
1.1 数据接收
当硬件不具备RTE_EVENT_ETH_RX_ADAPTER_CAP_INTERNAL_PORT能力的时候,由CPU调度:
- 首先,通过rte_event_eth_rx_adapter_queue_add关联相应网卡号对应的接收队列收到数据后放入的工作队列ID;
- 然后,通过rte_event_eth_rx_adapter_service_id_get获取rx_adapter_id的rxadptr_service_id;
- 继续,通过rte_event_eth_rx_adapter_start启动rx_adapter_id;
- 最后,通过rte_service_run_iter_on_app_lcore不断在数据接收核上调度rxadptr_service_id接收数据。
注:本质上,rx adapter内部会创建一个event port,接收到数据后会通过该port发送到第一步指定的业务队列
1.2 数据发送
当硬件不具备RTE_EVENT_ETH_TX_ADAPTER_CAP_INTERNAL_PORT能力的时候,由CPU调度:
- 首先,通过rte_event_eth_tx_adapter_queue_add关联相应网卡号对应的发送队列;
- 然后,通过rte_event_eth_tx_adapter_event_port_get获取tx_adapter_id的event port号tx_port_id;
- 继续,通过rte_event_port_link将tx_port_id与业务创建的代表发送数据阶段的event queue关联起来;
- 继续,通过rte_event_eth_tx_adapter_service_id_get获取tx_adapter_id的txadptr_service_id;
- 继续,通过rte_event_eth_tx_adapter_start启动tx_adapter_id;
- 最后,通过rte_service_run_iter_on_app_lcore不断在数据发送核上调度txadptr_service_id发送event queue中的数据。
注:本质上,tx adapter内部也会创建一个event port,通过该port去获取event queue中的数据
1.3 事件调度
DPDK Eventdev库从编程模型(或者说概念架构上)有event queue,但是底层实现中queue只是一个事件分发配置或者说策略(例如driver/event/sw中的实现)。它的事件是存储在event port对应的数据结构中,那么就需要由CPU或者硬件去实现将一个event port中的事件根据策略搬移到对应的event port中。
当硬件不具备RTE_EVENT_DEV_CAP_DISTRIBUTED_SCHED能力的时候,由CPU调度:
- 首先,通过rte_event_dev_service_id_get获取event_dev_id的evdev_service_id;
- 然后,通过rte_service_run_iter_on_app_lcore不断在调度核上调度evdev_service_id实现事件分发。
Eventdev库定义了三种事件调度的策略,即有序调度、原子调度和并行调度:
- RTE_SCHED_TYPE_ORDERED
有序调度允许同一个queue中、flow_id相同的事件,可以被多个port通过dequeue获取并处理;但在enqueue下个相同queue时,会维持之前的事件顺序;对该事件显示调用enqueue执行RTE_EVENT_OP_RELEASE可提前释放该事件在flow中的保序工作。 - RTE_SCHED_TYPE_ATOMIC
原子调度允许同一个queue中、flow_id相同的事件,只能被单个port通过dequeue获取;直到对该port再次调用dequeue,或对该事件显示调用enqueue执行RTE_EVENT_OP_RELEASE释放流上下文。 - RTE_SCHED_TYPE_PARALLEL
并行调度按照优先级、负载均衡策略去调度,由应用程序去保序。
注:RTE_SCHED_TYPE_ORDERED与RTE_SCHED_TYPE_ATOMIC的区别:前者是可以被多个port在多核上并行执行的,一般应用场景是先用ORDERED并行处理、同时保证有序,最后用ATOMIC串行处理需要有序依次处理的部分。
1.4 struct rte_event
rte_event结构体记录着eventdev框架中流通的事件信息。
WORD0 核心成员如下:
- event_type :事件类型。
- flow_id :与事件分派保序有关;
- queue_id :指定enqueue到哪个队列;
- sched_type :调度类型/策略;
- op :事件enqueue操作类型,可以是RTE_EVENT_OP_NEW、RTE_EVENT_OP_FORWARD和RTE_EVENT_OP_RELEASE;
注:RTE_EVENT_OP_RELEASE除了会将当前事件从保序上下文中释放,还会释放mbuf/vec字段。
WORD1 核心成员如下:
- mbuf :事件中附带的单个收发数据包;
- vec :事件中附带的单个或多个收发数据包;
注:当调用rte_event_eth_rx_adapter_queue_add时,设置struct rte_event_eth_rx_adapter_queue_conf.rx_queue_flags参数带有RTE_EVENT_ETH_RX_ADAPTER_QUEUE_EVENT_VECTOR标志,那么WORD1就是vec(此时WORD0.event_type带有标记位RTE_EVENT_TYPE_VECTOR);否则就是mbuf。
2 核心API
- rte_event_dev_count / rte_event_dev_info_get / rte_event_dev_configure
rte_event_dev_count用于获取事件设备数量;rte_event_dev_info_get用于获取事件设备信息;rte_event_dev_configure用于配置配置事件设备。 - rte_event_queue_setup / rte_event_port_setup / rte_event_port_link
rte_event_queue_setup 用于配置事件队列;rte_event_port_setup用于配置事件端口;rte_event_port_link用于将端口关联到队列; - rte_event_dev_service_id_get / rte_event_eth_rx_adapter_service_id_get / rte_event_eth_tx_adapter_service_id_get
获取事件设备 / 接收适配器 / 发送适配器的服务ID - rte_event_dev_start / rte_event_dev_stop / rte_event_dev_close
启动/停止/关闭事件设备; - rte_event_eth_rx_adapter_create / rte_event_eth_tx_adapter_create
创建接收/发送适配器; - rte_event_eth_rx_adapter_queue_add / rte_event_eth_tx_adapter_queue_add
将网卡设备端口的接收/发送队列配置到接收/发送适配器; - rte_event_eth_rx_adapter_event_port_get / rte_event_eth_tx_adapter_event_port_get
获取软件实现的发送/接收数据的事件端口号;前者一般在应用层不常用; - rte_event_eth_rx_adapter_start / rte_event_eth_rx_adapter_stop
用于启动/停止接收数据适配器; - rte_event_eth_tx_adapter_start / rte_event_eth_tx_adapter_stop
用于启动/停止发送数据适配器; - rte_service_component_register / rte_service_component_runstate_set
rte_service_component_register用于注册事件服务;rte_service_component_runstate_set用于设置服务组件状态为运行或停止状态;一般事件设备和适配器内部实现隐式调用了这两个接口。 - rte_service_runstate_set / rte_service_set_runstate_mapped_check
rte_service_runstate_set将服务应用状态设置为启动或停止;rte_service_set_runstate_mapped_check启动服务状态检测功能;两者会在启动相关句柄之前调用。 - rte_service_run_iter_on_app_lcore
当硬件不支持的情况下,用于在特定核上运行服务,例如收发数据服务、调度服务; - rte_event_dequeue_burst / rte_event_enqueue_burst / rte_event_eth_tx_adapter_enqueue
rte_event_dequeue_burst从特定事件端口获取事件;rte_event_enqueue_burst将事件通过特定端口发送出去;rte_event_eth_tx_adapter_enqueue将事件通过指定的端口发送到硬件实现的发送端口绑定的队列上去。
3 源码解析
eventdev_pipeline将事件相关操作封装在fdata->cap变量中,这个结构体主要函数指针字段如下:
- check_opt :用于运行前对事件设备和适配器的相关能力检测;
- evdev_setup : 用于创建事件设备、事件端口、事件队列以及将队列与端口绑定;
- adptr_setup :用于网络设备端口的初始化、然后根据网络设备创建收发数据的事件适配器;
- scheduler :当硬件没有相关能力的时候,由软件去调度相关的服务(例如事件调度、收发数据);
- worker :用于获取事件并处理,完毕后投送到下各队列。
本实例程序提供两套fdata->cap的实现机制,一套我们称为generic实现、一套称为tx enq实现。
3.1 generic实现
只要有一个网卡设备不具备RTE_EVENT_ETH_TX_ADAPTER_CAP_INTERNAL_PORT能力,那么就需要采用generic实现,该实现发送数据由上述的软件方式实现
3.2 tx enq实现
当所有的网卡具备RTE_EVENT_ETH_TX_ADAPTER_CAP_INTERNAL_PORT能力,那么采用tx enq实现。该实现发送数据采用硬件实现。
tx enq的worker实现分为原子和非原子调度。原子调度是每个网络设备对应一个事件队列,各个网络设备不共享事件队列,每次递增struct rte_event.sub_event_type;非原子调度是每个网络设备对应cdata.num_stages + 1个事件队列,各个网络设备不共享事件队列,每次调度递增struct rte_event.queue_id。
当设备不具备接收数据能力的时候,它与generic实现一样采用软件实现,同时它与generic实现不同的是:tx enq实现是每个网络设备(或者说端口)创建一个对应的接收适配器并与之关联。
另外,tx enq实现中没有发现调用scheduler回调的地方。