DPDK 报文调度/保序终极解决方案 Event Dev 简介

最新推荐文章于 2024-06-02 15:41:57 发布

weixin_37097605

最新推荐文章于 2024-06-02 15:41:57 发布

阅读量1.7k

点赞数 1

本文链接：https://blog.csdn.net/weixin_37097605/article/details/101514310

版权

本文介绍了DPDK在报文调度和保序方面的挑战，探讨了从RSS/Flow Director到CPU软件调度，最终转向硬件实现的Event Dev。Event Dev通过硬件队列和调度器确保报文按顺序处理，分为Atomic和Ordered两种类型，提供了高效且灵活的解决方案。

摘要由CSDN通过智能技术生成

背景介绍

网络报文的分发以及保序一直以来是让人头痛的问题, 为了完整的解释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之间做包文的分发也是代价昂贵的操作。

0?wx_fmt=jpeg