各网卡对于FDIR的支持在DPVS中的应用

目录

• ​​背景​​
• ​​FDIR模式缺陷​​

• ​​FDIR模式​​
• ​​fdir容量限制​​

• ​​82599网卡将包分到队列的优先级以及策略​​

• ​​82599 L3/L4 5-tuple Filters​​
• ​​82599 RSS​​

• ​​网卡是否支持FDIR查看​​
• ​​驱动对FDIR的支持缺陷​​

• ​​DPDK对于i40e驱动的掩码问题​​
• ​​ixgbe 的 mask设置​​
• ​​ixgbe的 ipv6 fdir的问题​​

• ​​DPVS 中各网卡对于FDIR的使用原理​​

• ​​DPVS 中FDIR的设置以及匹配​​
• ​​DPVS中代码级别的处理​​
• ​​i40e 驱动中fdir处理​​
• ​​ixgbe 驱动中fdir处理​​
• ​​DPVS在82599网卡能否支持NAT44 && NAT66?​​

• ​​其他​​

• ​​网卡驱动特性汇总​​

• ​​DPDK支持的硬件​​

• ​​CPU​​
• ​​网卡(nic)​​

• ​​参考​​

背景

在CPU单核时代，数据包经由网卡接收后均被送往唯一的CPU进行处理。随着多核时代到来，出现了负载均衡问题（某些core过载，而另一些core空载的情况）。为解决该问题，RSS（Receive Side Scaling）技术先通过hash操作将数据包发送到不同的core上进行中断处理，然后再经由core间转发将数据包发送到运行目的应用所在的core上。虽然负载看似在多core上均衡了，但由于hash的抗碰撞特性，大量数据包会被送到了不匹配的core上，因而数据包的core间转发成为性能瓶颈。

​​​

RSS通过计算包的五元组（sip、sport、dip、dport、protocol）的hash并取余，得到队列的index，然后将包放入这个队列，实现了数据包在各个队列之间的负载均衡，不过RSS不能保证回包也落在同一个队列上；

对称hash（symmetric hash: sip/sport和dip/dport交换后hash不变）可以部分解决该问题，但是对于一些需要做NAT的设备（比如负载均衡）就失效了，FDIR可以完全解决该问题。

Intel® 以太网Flow Director技术（Intel® Ethernet Flow Director，简称FDIR）将数据包定向发送到对应应用所在core上，从而弥补了RSS的不足，可用来加速数据包到目的应用处理的过程。

FDIR（Flow Director）的优先级高于RSS（Receive Side Scaling）

FDIR模式缺陷

FDIR模式

我的理解：

感觉 perfect mode，就是收到的报文的字段和配置的规则是完全匹配的。
signature mode，就是收到的报文的字段的hash 和 配置字段的 hash 是匹配的。
signature mode的优点是节省空间，不需要存储各个field，但是模糊匹配，不精确。

DPDK中FDIR相关测试：
https://doc.dpdk.org/dts/test_plans/fdir_test_plan.html

fdir容量限制

• intel 82599 datasheet 对于FDIR支持
  
  
  参考：​​​intel 82599 datasheet​​

我的理解：

fdir 规则 和 网卡的收包缓冲区共享内存，共享内存的大小为 512K。
fdir 匹配的字段：sip、dip、ip proto、sport、dport；
fdir 规则，不可作用于 非 ip包，隧道包的内层，分片包；因为没有上诉的某个字段。

• 82599 匹配FDIR的原理

1> 过滤单元从来包中提取 相关元组（基于设置的fdir filter rule来提取元组）
2> 根据提取出的元组进行hash
3> 在hash 桶中查找，直到查找到，或者查找不到。
4> 查找到：
更新 fdir match 统计计数；
执行fdir filter rule动作（比如放入到指定的队列中）
注：fdir的优先级要低于 L2 filter/syn filter/5-tuple filter。
比如：非ip包的filter、tcp syn的filter 等优先于 fdir；
5> 查找不到；
更新 fdir dismatch 统计计数。

• testpmd中FDIR设置

–pkt-filter-size 其实就是 fdir_conf.pballoc ：
设置的是 存放fdir filter的大小，目前看只有三种规格，64K，128K，256K；一般而言，默认是64K。

• DPVS中FDIR应用

对于DPVS而言:
fdir_conf.pballoc 默认 64K，可以支持 2K个 perfect 模式的 filter 规则。
实际上每个接口配置的fdir filter 数目为：lip 个数 * slave线程个数 * 协议个数。
协议个数一般是2：tcp 、udp；
单机支持的conn数目 = lip个数 * 65535（port个数）* N
【N: 一个 lip:lport 对可以被多少个 rs(rip:rport对)共享。默认是16 】
注：
每个slave 对应的 lan 口的接收队列配置的fdir 规则为： lip（mask: 255.255.255.255）+ dstport & (slave 个数2的n次方向上取整，然后-1) == 该slave的index。

82599网卡将包分到队列的优先级以及策略

参考：​​TestPMD使用中的 ixgbe filter 设置​​ 由上可知：

对于 intel 82599/x520/x540 等使用 ixgbe 驱动的网卡而言：

• fdir的优先级高于rss， 会先匹配fdir，匹配不到，再匹配RSS
• RSS也无法匹配，则使用 0 号接收队列。

82599 L3/L4 5-tuple Filters

我的理解：

82599 5-tuple filter 不支持 ipv6。

82599 RSS

• 原理

RSS 就是收到包之后进行hash，将包分流到多个接收队列中。

流程：

• 配置 RSS规则。
  比如基于sip/dip, sport, dport, proto 进行hash。
• 如果收包匹配到配置的规则，提取信息进行hash，路由到指定的收包队列。
• 如果收包匹配不到指定的RSS规则，则路由到0号队列。

• 限制

82599 的 rss hash 的output 为 4-bit; 所以最多支持16个接收队列。
因为：DPDK程序的收包线程个数不可以超过16个。

• RSS的扩展

• 背景：
  由于RSS是微软提出的，存在一定的标准，所有的卡应该都是按照这个标准进行的。
• 问题：
  对于 原始包 和 icmp容错包「内层为原始包的回包，四元组和原始包刚好反过来」通过网卡的RSS hash可能路由到两个不同的队列中，被DPDK程序的2个不同线程接收处理。
• 解决：
  如果知道RSS的算法实现，DPDK程序可以通过soft RSS 来模拟硬件RSS。这样可以在软件层面将 icmp容错包路由到指定的队列「DPDK线程和队列存在对应关系」，进而得到指定的线程。

网卡是否支持FDIR查看

# ethtool --show-features <interface name> | grep ntuple

说明：
如果ntuple-filters功能旁显示了off或者on，就表示你的网卡支持FDIR技术。
如果ntuple-filters旁边显示的 [fixed]，表示你的网卡设备不支持FDIR。

驱动对FDIR的支持缺陷

DPDK对于i40e驱动的掩码问题

理解：

• ixgbe驱动
  ixgbe支持多种型号的网卡，例如82599、x540、x550和x552等；

• i40e驱动：
  Intel x710/x722 中的 fdir 应该是支持的。
  但是DPDK对于使用i40e驱动的网卡的FDIR的Mask的set/get存在问题；也可能是使用 i40e驱动的网卡硬件本身设置FDIR的 mask 就有问题，不是dpdk的问题
  注：应该和 i40e 的驱动没啥关系，因为使用dpdk后，网卡被 igb_uio接管，和i40e驱动没关系了。

ixgbe 的 mask设置

另外，ixgbe 驱动对于 fdir 的 某个item的 mask 设置是全局的，好像不支持基于具体的某个rule 的item进行设置mask。

ixgbe的 ipv6 fdir的问题

82599 DPDK ixgbe驱动不支持IPv6报文flow director的perfect mode，所以只能用signature mode。

但是 signature mode 是通过计算 hash，有可能存在2个fdir filter 规则 hash value冲突的问题，此时无法知道采用哪个fdir filter的action。

如上所示：perfect 模式下，并没有设置ipv6 srcip/dstip 的寄存器；
所以：82599 不支持 ipv6 的 fdir perfect 模式，这个是网卡的限制，不是DPDK。

• fdir signature 模式 fiter 的设置



• signature 模式filter 冲突时可能的解决办法

我的理解：

1> fdir perfect mode, 不可能冲突。
2> fdir signature mode, 可能冲突。如果冲突：
2.1> 不进行任何处理:

则只保留了一个，action会选择前面的 fdir的action。

2.2> 进行处理：

冲突的 flow 不设置为 fdir filter，而是设置为 5-tuples filters. 这样 fdir filter 中有一个规则，5-tuples fitler中也有一个 规则。
注：5-tuples filters 的优先级高于 fdir filter。

• 参见文档

dpvs 手册： 
https://github.com/iqiyi/dpvs/blob/master/doc/tutorial.md

82599网卡手册 datasheet：
https://interfacemasters.com/pdf/82599_datasheet.pdf

82599 网卡的fdir限制：
https://decodezp.github.io/2020/12/14/test26-82599-fdir-limit/

DPVS 中各网卡对于FDIR的使用原理

DPVS 中FDIR的设置以及匹配

• 设置

DPVS中可配置多个local ip，每个local ip对应的port-range为 1025~65535；
每个Lcore中分配的 Lip:lport对不同；
每个 core的 fdir 设置：
dstip == LIP
dstip.mask == 255.255.255.255
dstport == 当前core 的 coreIndex;
dstport.mask == 转发core个数向上取整2的N次方，然后 -1；

• 匹配FDIR

RS回包的 dip & IP_MASK(0xfffffff, 即 32 位匹配) == 下发的 lip
RS回包的 dport & PORT_MASK (一般是转发core个数向上的2的N次方-1) == 下发的 port (实际上就相当于是转发core的 index )

比如：转发core有8个，master core 一个。
那么 PORT & 7 == coreIndex 的port 就会分配给某个 Lcore;

DPVS中代码级别的处理

• fdir 的初始配置

说明：

起始配置时，dip的mask为/32的，为了RS的回包完全匹配Local ip；

dst_port_mask后续会更改；

• 基于转发core的个数，设置fdir的 dst_port_mask

说明：

fdir 的 dst_port_mask 设置为 转发core的个数向上取 2的N次方-1；

• 打印 fdir 的配置

配置好 fdir 之后，打印 fdir的配置，可以根据这个进行检查。

• 下发 fdir filter 规则

如上所示:

下发 fdir filter 前，获取 fdir的mask，将 filter & mask 下发下去。

此中 ip 为 Local ip， port 其实是每个 转发core的 core_index.

ip_mask = 0xffffffff. dst_port_mask = 转发core的个数向上取2的N次方-1；

i40e 驱动中fdir处理

如上所示:

并没有对mask 进行获取。查看 DPDK 21.05 依然如此，么有获取 fdir mask。

网上针对 dpdk 对于使用 i40e驱动网卡的 fdir mask的设置失败问题的 patch；
​ https://github.com/iqiyi/dpvs/issues/433​​​ https://github.com/iqiyi/dpvs/pull/440/files​​

ixgbe 驱动中fdir处理

DPVS在82599网卡能否支持NAT44 && NAT66?

• 需求

NAT44, NAT66 正常工作。

• 已知问题

• 82599 不支持 ipv6 fdir perfect
• 82599 支持的 5-tuple 最多为 128.
• 82599 5-tuple filter 不支持 ipv6.
• Ipv4 Lip:Lport 的 fdir 规则数 = LIP个数 * Slave线程个数 * 协议个数（一般为2：tcp、udp）。

• 方案一：

下面条件是否可以同时满足：

• ipv4 lIp:lport 对的 fdir 规则都是 fdir perfect 模式；
• ipv6 lip:lport 对的 fdir 规则使用 fdir signature 模式，冲突的 fiter 不再添加 到网卡，只保留一个；冲突的fdir fiter 通过 soft fdir 来转发到指定的 core。

问题：
82599 的 fdir mode 配置好像是一个全局配置，好像不可以基于 flow。

• 方案二：

• ipv4 lIp:lport 对的 fdir 规则都是 fdir perfect 模式；
• Ipv6 Lip:Lport 不下发规则，通过RSS分发，然后再软件层面执行 FDIR 分到对应的核心上。

• 方案三：

• ipv4 lip:port 以及 ipv6 lip:lport 规则都设置为 fdir signature 规则；
• fdir 冲突的filter 规则，不再下发，保留前者。通过soft fdir 导流到对应的 core中。

分析：
冲突的概率是多大呢？
如果都是用 signature 模式。正常情况下，存在20个 ipv4_lip, 20个 ipv6_lip, 16个转发线程，2种协议（tcp、udp），则下发的 fdir 规则的个数为：
N = ipv4_lip_num * slave_num * 2 + ipv6_lip_num * slave_num * 2 = 1280。
可以通过 dpip -x link show |grep flow_director_ 查看 fdir 的统计情况；

其他

网卡驱动特性汇总

参考：​​DPDK各个类型的网卡驱动支持的特性​​

DPDK支持的硬件

CPU

网卡(nic)

参考

https://github.com/iqiyi/dpvs/issues/433
【dpvs i40e 驱动网卡 fdir 不生效问题】

【intel E800 系列网卡FDIR功能及原理介绍】

https://www.mouser.cn/datasheet/2/612/710_series_datasheet_v_3_6_5_08_28_2019_final-1140607.pdf
【x710/xxv710/xl710 网卡的 datasheet】

https://www.mouser.fr/pdfdocs/82599datasheet.pdf
【82599网卡的 datasheet】