引言

DPDK Eventdev库是DPDK基于事件驱动的编程模型。其中eventdev_pipeline实现了对该模型的应用例子。

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. 读取以太网数据；
2. 解析数据包；
3. 根据请求内容，确定返回内容；
4. 封装返回数据包；
5. 发送以太网数据。

注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 核心成员如下：

• 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；否则就是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回调的地方。