如何使用 RTE_FLOW？在 DPDK 中通过循环方式进行负载平衡

发布于 2025-01-16 05:52:25 字数 323 浏览 2 评论 0原文

在我的问题中，RSS 在 CPU 核心之间没有良好的负载平衡，情况下 rx 数据包已通过在 mac 和 ip 之间插入标签进行修改，因此 dpdk 无法识别它。假设我想通过循环、多个的方式进行负载平衡rx 队列已设置。在这个问题中回答：如何禁用 RSS 但仍在 DPDK 中使用多个 RX 队列？它说可以通过使用 RTE_FLOW 以循环方式进行负载平衡。从语法上讲，正确的做法是什么？我想知道用于设置循环方法的 API 或结构这是我的运行时环境信息： 1）dpdk版本：19.11.9 2）NIC PMD：ixgbe 3）防火墙：825999和XXV710 4）操作系统版本：ubuntu 16.04 内核：4.4.0-186

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

臻嫒无言 2025-01-23 05:52:25

根据问题

RSS 在 CPU 内核之间没有良好的负载平衡，rx
数据包已通过在 mac 和 ip 之间插入标签进行修改

有几项需要澄清。因此，让我解释一下

某些物理和虚拟 NIC 通过 DPDK RX 卸载公开 RSS，以获取 IP、协议、TCP|UDP|SCTP 端口号等固定元组。
某些 NIC 允许配置哈希 reta 算法以更好地满足需求（例如，当源目标 IP 地址固定时，我们可以跳过并使用其他算法）。
据我回忆，DPDK 18.11 中引入了 RTE_FLOW 以支持选定 RX 队列上的 RSS（例如 Q1、Q2、Q3 可以用于 TCP 数据包的 RSS，而 Q4、Q5 可用于 UDP）。但这又是基于内部或外部 IP+端口号。
对于 DPDK 版本 19.11 及以上版本，RTE_FLOW 已得到增强以支持 RAW 模式。此功能的目的是支持默认情况下 NIC 无法理解的特殊协议（VXLAN、GENEVE、RTP 和其他协议）。
对于像 Fortville 和 Fortville 这样的 NIC Columbiaville（来自英特尔）允许通过 DDP（动态设备角色）加载特殊固件，以配置特殊的结构标头或 MPLS 之类的标头（在以太网和 IP 之间）进行解析、查找并用作 RSS 的种子（允许更好的分发）。
有些 NIC 确实支持 L2 层，但这些将仅限于 SMAC、DMAC、VLAN1、VLAn2、MPLS，而不是自定义标头。

因此，根据 NIC、供应商、L2 的 RSS 支持和固件，在端口 init 或 RTE_FLOW 特定配置中计算 RSS 的能力会有所不同。例如，

I40E 支持的 RSS ETH 为 I40E_INSET_DMAC | I40E_INSET_SMAC
DPAA2 为 NH_FLD_ETH_TYPE 和 NET_PROT_ETH
CNXK 为 RSS_DMAC_INDEX
OCTEONX2 为 FLOW_KEY_TYPE_VLAN 和 FLOW_KEY_TYPE_CH_LEN_90B

因此对于 NIC ixgbe 和 XXV710代码> 没有准备好支持以太网和 IP 之间的自定义标头。

替代方案：

使用智能 NIC 或 FPGA：编程为将特定标头上的 RSS 解析为多个 RX 队列上的 RSS
使用 XXV710 (Fortville) 与 Intel 合作：创建 DDP，它可以将您的特定标头解析为多个 RX 队列上的 RSS 。
识别 DPDK NIC：可以按照 12.2 的定义解析 RAW 标头。 6.2。一旦供应商添加了支持，您就可以创建一个简单的流量传播工具，它将确保流量以循环方式分布在所需的 RX 队列中。
使用软件来支持缺失的硬件。

它会产生两重问题

注意：我不建议使用基于硬件的静态循环，因为如果它是纯粹的 DPDK BOND Round ROBIN 您将不会有任何流量固定
如果您使用基于哈希的固定，则大象流量有机会推送 1 或一些队列导致 CPU 处理性能下降。
我的建议是使用具有原子模式的 EVENTDEV 模型，这可确保更好的缓存局部性（在给定实例中，相同的流将落入工作线程）和几乎线性的性能。示例应用

对于选项 4（软件模型）：

在 port_init 函数中禁用 RSS
使用单个 RX 队列用于接收自定义 Rx 线程中的所有数据包。
根据所需的标头计算哈希并更新 mbuf 哈希字段。
使用rte_distributor库根据自定义分配流量。
或者使用rte_eventdev和原子模型来将工作负载分散到多个worker上。

[评论澄清]：

我问过相关从业者，他们说修改pmd驱动可以解决我的问题，只有这个办法吗？

[答案] 由于您使用的是自定义标头而不是通用 VLAN|IP|端口，因此此建议不正确。正如您在问题和评论中澄清的那样，您希望像 RSS 一样分发自定义标头。

我还没有编写任何有关 rte_flow 分发的代码，我阅读了 rte_flow 示例，没有看到配置循环的代码

[ANSWER]，如上所述，并非所有网卡都支持 RSS 和 RAW。由于您当前的网卡是 ixgbe 和 i40e，解析和执行自定义标头的 RSS 的功能不太可能。您可以尝试选项 2（与 intel 创建新的 ddp 一起使用）为 i40e 实现相同的效果或按照选项 4 中的建议在软件中实现。

我不要求解决方案，我只是想知道如何通过“RTE_FLOW”设置循环法您能给我一些 API

[ANSWER]，通常是使用代码片段或用于重现错误的步骤进行更新。但目前的问题更像是澄清。请参考上文。

As per the question

RSS did not have a good load balance between CPU cores case the rx
packets has been modified by insert tags between mac and ip

There are couple of items which needs to be clarified. so let me explain

Certain Physical and virtual NIC exposes RSS via DPDK RX offload for fixed tuples like IP, Protocol, TCP|UDP|SCTP port number.
Certain NIC allows to configure the hash reta algorithm to better suit to needs (example when the source destination IP address is fixed we can skip and use others).
As I recollect from DPDK 18.11, RTE_FLOW is been introduced to support RSS on selected RX queues (example Q1,Q2,Q3 can be RSS for TCP packets while Q4,Q5 can be used for UDP). But again this is based on the either Inner or Outer IP+PORT number
For DPDK version 19.11 onwards RTE_FLOW is been enhanced to support RAW Pattern. The intend of this feature is support Special protocol which by default the NIC does not understand like (VXLAN, GENEVE, RTP and other protocols).
For NIC like Fortville & Columbiaville (from Intel) allows loading of special firmware via DDP (Dynamic Device Personation) to configure special fabric headers or MPLS like headers (between ethernet and ip) to be parsed, lookup and used as seed for RSS (allowing better distribution).
There are NIC which do support L2 layer but these would be limited SMAC, DMAC, VLAN1,VLAn2, MPLS only and not custom header.

Hence depending upon NIC, vendor, RSS support for L2 and firmware the ability calculating RSS on fields between varies in port init or RTE_FLOW specific configuration. For example RSS ETH supported on

I40E is I40E_INSET_DMAC | I40E_INSET_SMAC
DPAA2 is NH_FLD_ETH_TYPE and NET_PROT_ETH
CNXK is RSS_DMAC_INDEX
OCTEONX2 is FLOW_KEY_TYPE_VLAN and FLOW_KEY_TYPE_CH_LEN_90B

Hence for NIC ixgbe and XXV710 there is no ready support for the custom header between ethernet and IP.

Alternatives:

Use a smart NIC or FPGA: that is programmed to parse and RSS on your specific headers to RSS on multiple RX queue
Work with Intel using XXV710 (Fortville): to create DDP which can parse your specific headers as RSS on multiple RX queue.
Identify DPDK NIC: which can parse RAW header as defined 12.2.6.2. Once the support is added by the vendor you can create a simple traffic spread tool which will ensure traffic distribution across the desired RX queues in round robin fashion.
Use SW to support the missing hardware.

note: I am not recommending use of HW based static Round Robin as it will create 2 fold problem

if it is pure DPDK BOND Round ROBIN you will not have any flow pinning
If you use hash based pinning, there are chances elephant flow can pushed 1 or a few queues causing performance drops in cpu processing.
My recommendation is to use EVENTDEV model with atomic mode, which ensure better cache locality (at a given instance same flows will fall onto worker thread) and almost linear performance performance. sample app

For option 4 (Software Model):

Disable RSS in port_init function
Use single RX queue to receive all the packet either custom rx thread.
calculate the hash based on the desired header and update mbuf hash field.
Use rte_distributor library to spread traffic based on the custom.
or use rte_eventdev with atomic model to spread the work load on multiple worker.

[Clarification from Comments]:

I have asked relevant practitioners， they said modifying the pmd driver can solves my problem, its the only way?

[ANSWER] Since you are using custom header and not generic VLAN|IP|Port this suggestion is not correct. As you have clarified in question and comments you want to distribute like RSS for custom header.

I haven't written any code about rte_flow distribution yet, i read the rte_flow example, don't see the code to configure round-robin

[ANSWER] as explained above not all nic support RSS and RAW. Since your current NIC is ixgbe and i40e the function of parsing and executing RSS for custom header is unlikely. you can try option 2 (work with intel create new ddp) for i40e to achieve the same or implement in SW as suggested in option 4.

im not ask for solution, I just want to know how to set up round robin by 'RTE_FLOW' Can you give me a few API

[ANSWER] normally one updates with code snippets or steps used for reproducing the error. But the current question is more like clarification. Please refer above.

回复收藏 0 原文

~没有更多了~