网络报文的分发以及保序一直以来是让人头痛的问题, 为了完整的解释Event Dev的背景,我们可以从两个基本概念的定义开始:

• 报文分发是指针对网络通信报文的某种特征(例如 5 tuples)对网络报文进行分类以及对这个分类进行对应的特定处理。这种分类通常称为是flow, 例如 src ip, src port, dest ip, dest port, 一致的报文被认为是一个flow, 还可以更进一步提取特征来加强判断同一flow的条件, 例如协议类型, tunnel id 等等。

• 保序, 是指在包文处理过程中不改变原有的顺序, 大多数情况下可以弱化为在同一flow内的包文顺序不变。这里和协议倒不是非常相关。

首先最常见的包文分发技术是基于NIC 多队列的 Receive Side Scaling, NIC 首先根据算法对包文进行分类,然后尽可能平均的把不同flow放置到不同的接受队列中。RSS虽然解决了包文分发到多个cpu core的问题, 但是RSS并不了解哪个flow应该到哪个cpu core, 也无法通过配置解决, 同时RSS只能分发没有其它选择, 为了解决这个问题 Intel 引入了更进一步的方案 Flow Director, 通过Flow Director, NIC 不但可以分发包文还可以指定特定的flow到特定的cpu core,同时除了分发也可以选择drop 包文。要更加精准和灵活， 更多细节请参考 Flow Director Ref。

无论RSS/Flow Director 都可以分发/同一flow保序 但是很难满足更复杂的应用场景。在PIPELINE 处理模型中, 除了接受端分发以外, 每个节点处理后还会 二次, 三次, N次分发包文, 这下该怎么办 ?

如下图所示, 同一flow 4个包文开始分发, 1,3 进入一个路径, 2,4 进入一个路径, 因为没有任何锁来控制同步(性能考量) 所以在处理结束的时候包文的顺序以及打乱, 原因是在两个完全并行的路径上顺序是无法保证的, 最直接的想法就是引入一个reordering的功能节点, 当然代价是昂贵的, 同时在CPU core之间做包文的分发也是代价昂贵的操作。

通过网卡来分发调度只能在接收端进行一次, 在更加复杂的PIPELINE模型中无法进一步进行调度, 所以非常直接的解决方案就是通过CPU 来对报文进行调度/保序, 一个高效的实现方案并不是显而易见的, 主要的困难在于两个方面：

• 如何高效的分发

• 如何高效的保序

DPDK的 组件 Packet Distributor 在这方面进行了有益的探索。

调度报文, 本质上就是CPU core之间的通信, X86的架构下 , CPU core 之间最高效的通信方式就是通过 L3 cache-line, 一个 cache-line 是64Byte, 也就是说 在一个cache-line中最多可以包含8个64bits指针，恰恰8个指针可以代表8个报文。Distributor Core 和 Worker Core 通过cache-line来通信, Distributor/Worker Core 通过首个报文的最低4位来判断读写的状态 (mbuf 默认都是 64Bytes 对齐, 所以低6位都是空余的可以用来表示状态), 如下图所示：

以下是状态位的定义（可左右滑动）:

其工作流程如下（引自dpdk.org）， 不再赘述：

Distributor 作为纯软件报文分发确实做到了比较极致, 但是却没有完美的解决保序的要求, 依然需要引入 reorder buffer来重建报文顺序。同时如果worker core 是处理异步业务 Distributor core 也需要引入更加复杂的逻辑来应对。大家可以参考源代码: example/distributor/

报文分发/保序的最终形态终于演化至Hardware实现 (i e基于CPU的软件方案在灵活性,性能上都遭遇了瓶颈)。当前的Hardware主要有两家厂商, NXP 和Cavium, 我们今天的讨论主要基于后者, 主要的原因是因为公开的资料比较全面。 Cavium eventdev HW 介绍

对于HW实现来说, 显而易见的是把分发/保序的工作分担给HW,从而节省CPU的计算资源。

核心的HW框架如下(引用自Cavium的资料)：

以下是简化的event定义, 前64位是 meta data, 后64位是mbuf的地址。Meta data中包含各种控制信息可以参考代码，这里不再赘述。（可左右滑动）

报文调度主要有两种类型:

Atomic: 在特定时间点, 每一个flow 只有一个报文被调度到一个CPU进行处理, 从而保证处理过程中相关数据结构的原子性, 达到无锁处理的目标,可以简化应用设计.

Ordered: 在特定时间点, 每一个flow可以有多个报文被调度到多个CPU进行处理, 但是处理结束后报文的顺序没有变化.

下面结合EventDev HW 设计来描述一下一个报文的生命周期。首先来看下图:

影响调度器行为的参数有:

• flow id: event 所属的flow

• queue id: event 入队时指定的队列id

• event type: event的类型

• queue type: 队列的分发属性

• op type: event 是new/forward/release主要是指这个事件是新引入事件(例如RX),还是转发(node节点之间),还是释放(含异常处理)

结合下图可以更好的理解一下队列类型的影响：