关于 DPDK 的 一些零散的杂言杂语的念头/看法
回顾了之前 DPDK 的一些学习。有一些零散的杂言杂语的念头/看法，原本分散在各处，之前没有记录下来。这里简单记录补充一下。
===============================================================================================================
@@@ #1. DPDK 的各种 API subset 的定义，肯定是从 通用性的角度 来定义，目标是 “期望尽量generic，定义一些common framework，期望所有 NIC / PMD 都尽量遵循 这些common framework的定义”。但是，这种 “期望”，有时可能会造成一些理解和使用上的混乱。
---------------------------------------------------------------------------------------------------------------
--- 例子 #1. Generic flow API (rte_flow)
这个 API subset 的 common framework 所定义的模型是:
期望 NIC 内部有一个 硬件上的 HW component "flow engine"（__逻辑上的定义，名字随意），可以对其配置 flow rules。
一条 flow rule = matching items + actions。 其中，matching items 是定义了 packet metadata（__比如说，5-tuple，VLAN, 等等 ）。
#
# --- 注意 flow rule 在 DPDK framework 中的结构体定义，是 generic 的，但具体配置到 NIC flow engine 时，会被 NIC/PMD “翻译”为 NIC-specific 的格式。
#
对 ingress / egress packets， "flow engine" 在硬件上的处理是，根据 flow rules table，对 packets 判断其是属于哪一条 flow rule，并执行 rule 中的 actions。
问题在于:
并不是所有 NIC 都会有一个 HW component "flow engine"。 # 或者，没有明显的 "flow engine"。
并不是所有 有"flow engine"，都支持 common framework 所定义的 全部 matching items types 和 actions types。
------------------------------------------------------
比如说:
Marvell PPv2 (Packet Processor v2) 1/10 Gbps adapter # 见: << Network Interface Controller Drivers---nics >> / Chapter 36. MVPP2 POLL MODE DRIVER
我手头上并没有 MVPP2 的 datasheet。但是之前做过 基于 Marvell xCat switch chip 的交换机项目，知道 Marvell 的网卡，一般会有 "Policy Engine", "Tunnel-Termination", "Tunnel-Start"（__这些都是 Marvell datasheet 中本身的名字，可以认为它们共同算作 Marvell NIC 的 "flow engine" ）。
从 Marvell NIC 所支持的硬件能力来看，其是可以:
对 匹配 matching items 的 tunnel packet，进行 DECAP，得到 inner packet。
或者，对匹配 matching items 的 non-tunnel packet，进行 ENCAP，得到 tunnel packet .
Marvell NIC 所支持的 tunnel protocol，又并不是 DPDK 所定义的。
DPDK rte_flow framework，定义了这些 tunnel 相关的 flow action:
RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP
RTE_FLOW_ACTION_TYPE_VXLAN_DECAP
RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP # 字面缩写好像是 "Next Version GRE"
RTE_FLOW_ACTION_TYPE_NVGRE_DECAP # --- 但实际上是 Network Virtualization using Generic Routing Encapsulation (NVGRE)
... 等等。
而 Marvell NIC （__我只提我看到过的 ） 只支持 GRE tunnel 和 MPLS tunnel。
所以，在 DPDK 中的 MVPP2 PMD，就不支持 DPDK rte_flow framework 的 这些 tunnel 相关的 flow actions。
--- <tip>: 可能目前看到的，就只有 /drivers/net/mlx5/ 对 tunnel flow actions 支持得比较好。
------------------------------------------------------
又比如说:
Intel e1000 或者 ixgbe 或者 i40e。
它们 datasheet 中，并没有明确提到 "flow engine" 这么一个 HW component。
但是有 "flow redirector" (FDIR) 和其他各种 filter tables。
注意，它们的 "flow redirector" (FDIR) 和 "filter tables" 的大致功能是: 对匹配的 packets，进行 drop 或者 multi-rxq-assignment （__即，enqueue 到不同的 rx_ring 中 ）。
所以，它们的 PMD 中对 DPDK rte_flow framework 的支持， # igb_flow.c, ixgbe_flow.c, i40e_flow.c
基本上只支持这些 action types:
RTE_FLOW_ACTION_TYPE_DROP
RTE_FLOW_ACTION_TYPE_QUEUE # enqueue 到不同的 rx_ring 中
rte_flow framework 所定义的大部分其他 action types，都不支持。
------------------------------------------------------
从 DPDK programming 使用 Generic flow API (rte_flow) 的角度来看，
#a. 需要 熟悉 underlying NIC / PMD，它们 对 rte_flow 的支持如何，支持哪些内容，不支持哪些内容。
需要看一看 underlying PMD 的 xxx_flow.c 和 datasheet。
#b. 依赖 rte_flow API，判断 underlying NIC / PMD 是否支持一条 flow rule
/* Check whether a flow rule can be created on a given port. */
int
rte_flow_validate(uint16_t port_id,
const struct rte_flow_attr *attr,
const struct rte_flow_item pattern[],
const struct rte_flow_action actions[],
struct rte_flow_error *error)
其内部会调用不同 PMD 的 xxx_flow.c 的 xxx_flow_validate()，进行判断和检查，比如说:
igb_flow_validate()
ixgbe_flow_validate()
i40e_flow_validate()
检查支持的话，再去实际地配置 flow rule。
/* Create a flow rule on a given port. */
struct rte_flow *
rte_flow_create(uint16_t port_id,
const struct rte_flow_attr *attr,
const struct rte_flow_item pattern[],
const struct rte_flow_action actions[],
struct rte_flow_error *error)
------------------------------------------------------
---------------------------------------------------------------------------------------------------------------
===============================================================================================================
@@@ #2. DPDK API中，有一些 API subset 在其 文档 上并没有描述得很清楚，比如说，没有说明白 这些 API subset 是和NIC硬件上相关 或者是 纯粹的软件上实现的逻辑，可能会造成一些理解和使用上的混乱。 --- 需要自己理清楚，来判断在实际工作中，是否适合使用。
---------------------------------------------------------------------------------------------------------------
--- 例子 #1. QoS 相关的内容。 # 是相当混乱的一部分内容。
在 DPDK 中，QoS 大概有这些内容（__以他们相关的头文件）: # 见文档: << Programmer's Guide---prog_guide >>
ingress: # 主要是 metering 和 policing
<rte_mtr.h>
<rte_meter.h>, <rte_policer.h> # 见 文档 / 14. Traffic Metering and Policing API
egress: # 主要是 scheduling
<rte_tm.h> # 见 文档 / 15. Traffic Management API
<rte_sched.h> # 见 文档 / 44. Quality of Service (QoS) Framework
这4者之间的关联关系是: ....... 没有任何关联关系。
--- 所以，很容易在理解和使用上造成混乱。
------------------------------------------------------
ingress <rte_mtr.h>
是 通过 Generic flow API (rte_flow) （__上面提到过的）来使用。配置 flow rule 的 action type:
RTE_FLOW_ACTION_TYPE_METER
让 NIC 硬件中的 "flow engine"，对 匹配的 packets 进行 metering / policing。
--- 即，metering / policing 逻辑，是由 NIC 硬件上来做的。
但注意，并不是所有 NIC/PMD，都支持 这个 RTE_FLOW_ACTION_TYPE_METER。 # 只有少数才支持。
------------------------------------------------------
ingress <rte_meter.h>, <rte_policer.h>
和 NIC 硬件没有关系。完全是一个 软件上的 API subset。
--- 在 软件上，由 CPU 来执行 执行 metering/policing 的逻辑。
------------------------------------------------------
ingress <rte_mtr.h> 和 <rte_meter.h>, <rte_policer.h> 之间的关联关系是: 没有关系。
------------------------------------------------------
egress <rte_tm.h>
大致功能是，配置 NIC 硬件上的 multi-tx-queue 的 weight, RED policy, shaper rate limiting 等。
其定义了 node hierarchy 的模型。
这个模型是多层次的，其中 leaf node 对应一条 HW tx-queue。
不同的 NIC/PMD 所支持的层次数量，和 具体的层次定义，并不相同。
比如说:
ixgbe: port / tc / queue # 三层 # ixgbe_tm.c
mvpp: root / queue # 二层 # mrvl_tm.c
octecon: root / sch1 / sch2 / sch3 / sch4 / queue # 好多层，搞不明白 # otx_tm.c
node hierarchy模拟的通用定义是: （__我猜想的），指定不同层次 的 weight, RED policy, shaper rate limiting。
但 NIC / PMD 的实际支持，可能 就只是: 对 HW tx-queue 设置 rate limiting，而已。
比如说:
ixgbe: ixgbe_hierarchy_commit() # 其并不对 port / tc 进行什么设置，只是设置 queue 的 rate limit。
------------------------------------------------------
egress <rte_sched.h>
纯软件的 SW-level 的 API subset，和 NIC 硬件上的 hw_tx_ring scheduling 没有任何关系。
其所定义的 5-level tree hierarchy，和 上面 <rte_tm.h> 定义的 node hierarchy，没有任何关系。
<rte_sched.h> 和 Linux tc ( Qdisc ) 相似:
在 packet TX 时，将 egress packets 给 enqueue 到 hierarchy 中 进行排队什么的，然后从 hierarchy 中 dequeue 一些 packets 进行 actual TX。
------------------------------------------------------
egress <rte_tm.h> 和 <rte_sched.h> 之间的关联关系是: 没有关系。
------------------------------------------------------
---------------------------------------------------------------------------------------------------------------
--- 例子 #2. Bond
见: << Programmer's Guide---prog_guide >> / 22. Link Bonding Poll Mode Driver Library
大部分 switch chip，都支持 将多个 ports 组成一个 bond ports 的，这是硬件上的功能。
而 DPDK 的 bonding PMD，完全是软件上的功能。 # 和 Linux bonding framework 一样。
不过，DPDK 文档上一开始就说明白了，是 "pure-software library":
DPDK also includes a pure-software library that allows physical PMDs to be bonded together to create a single logical PMD.
---------------------------------------------------------------------------------------------------------------
--- 例子 #3. <rte_flow_classifier.h> # 见 << Programmer's Guide---prog_guide >> / 29. Flow Classification Library
<< Programmer's Guide---prog_guide >>
/ 12. Generic flow API (rte_flow) # <rte_flow.h>
/ 29. Flow Classification Library # <rte_flow_classifier.h>
这两者的关系是: ..... 基本没有关系。
<rte_flow.h> （__前面提到过的），是去配置 NIC 硬件中的 "flow engine" 的 flow rules。
<rte_flow_classifier.h>，则是:
完全是在 SW-level 实现的 library。和 low-level PMD 和 NIC 都无关。
之所以 在名字上叫做 "flow"，是因为它“借用”了 <rte_flow.h> 定义的 data structure:
const struct rte_flow_attr *attr,
const struct rte_flow_item pattern[],
const struct rte_flow_action actions[],
其 classify 逻辑的执行，也完全是由 DPDK app 显式地调用 API:
rte_flow_classifier_query()
来进行的。 --- 在 SW-level 执行。
它 到底是做什么用的呢？
The initial implementation supports counting of IPv4 5-tuple packets which match a particular Flow rule only.
--- 也就是说，当前的功能，只是: 在 SW-level，对 匹配 flow match patterns 的 packets，进行 counting。 --- 统计计数而已。
---------------------------------------------------------------------------------------------------------------
===============================================================================================================
@@@ #3. 对于 DPDK 的 spinlock / rwlock 和 RCU
---------------------------------------------------------------------------------------------------------------
spinlock / rwlock
Linux kernel 的 API 是:
spin_lock() / spin_unlock()
spin_lock_bh() / spin_unlock_bh()
spin_lock_irqsave() / spin_unlock_irqrestore()
而 DPDK API 只是:
rte_spinlock_lock() / rte_spinlock_unlock()
他们内部都是 使用 CPU 的 atomic_compare_exchange （ CAS ) instructions 来实现的。
不过，Linux 会 关闭 preemption / bh / irq。
但 DPDK locking 为什么不在意 preemption / bh / irq ？
#1. 因为 DPDK 是 user-level programming，没有 bh。
至于 irq .... DPDK 也关闭了 NIC 的 rx-tx irq，只是进行 polling。
#2. 至于 preemption ..... 和 DPDK 的 lcore （__或者说 multi-thread model ）定义有关。
一个 DPDK application，只允许，一个 CPU core 运行一个 thread。
不会有 2 个 DPDK thread 运行在同一个 CPU 上的情况。
--- 以上限制，是由 DPDK EAL layer，在代码上施加的（__通过 pthread_set_affinity() ）。
---------------------------------------------------------------------------------------------------------------
RCU
Linux kernel RCU 的 quiescent state 的条件是: # 不精确，但大致是这样理解。
所有 CPU 都返回 user-level 一次。 # 这样，所有CPU 原本的 kernel-level stack 都被“清空”了。
#
# 再进入 kernel-level 的 代码，是无法从 kernel-level stack 中
# 或者 kernel list/hlist 等datastructure 中，再获得
# 需要RCU defered free 的 数据的 “指针引用”。
#
然后，RCU 的 defered free，会自动由 RCU layer 来进行。
所以，并不需要 kernel code，自己来检查和“报告” RCU quiescent state。
而 DPDK RCU，需要 application 本身来调用 DPDK RCU API，来 检查和“报告” RCU quiescent state。
所以，会比 Linux kernel RCU 的用法，麻烦和绕一些（__很多）。
---------------------------------------------------------------------------------------------------------------
===============================================================================================================
关于 DPDK 的 一些零散的杂言杂语的念头/看法相关推荐
- 身为程序员，你接过最奇葩的需求是什么？丨Q言Q语
- Q 言 Q 语 第 二十一 期 - 本期话题: 身为程序员,你接过最奇葩的需求是什么? 身为执行部门,程序员们总是要去实现各种各样的需求,有的需求来自甲方,有的需求来自产品经理,还有的需求来自产品 ...
- 2018年，你想从InfoQ获取什么内容？丨Q言Q语
- Q 言 Q 语 第 三 期 - Q言Q语是 InfoQ 推出的最新板块, 旨在给所有 InfoQer 一个展示观点的平台. 每期一个主题, 不扣帽子,不论对错,不看输赢, 只愿跟有趣的灵魂相遇. ...
- 【R言R语】算法工程师入职一年半的总结与感悟
公众号:WeThinkIn 公众号原文:[R言R语]算法工程师入职一年半的总结与感悟 写在前面 [R言R语]栏目专注于分享Rocky的一些思考.关于AI行业的思考,将是本栏目的核心,除此之外,其他有价 ...
- 我为方舟CPU李德磊代言 对中兴事件的看法
[编者Peter Ye按] 作者黄巍,吉林省 长春吉湾微电子有限公司创始人. 我和黄总神交已久,几周前,刚好趁着有一次去吉林长春出差的时候,专程去拜访他.当时带着敬佩和好奇的心情.敬佩是因为,在不那么 ...
- 【蜂言蜂语】何以解忧？唯有暴富~
跟朋友吐槽 今天又是不想干活的一天 朋友直接来一句 一年里没有一天想干活吧 emmm 那当然是不可能的 . . . 这么说吧 如果你问我的星座 我会回答你 ∇∇∇ 如果不做现在的职业 你想做什么呢? ...
- 猫的计算机相关的网络语言,辟谣：猫咪的语言是喵？教你读懂“猫言猫语”，让你明白猫的内心...
"我们一起学猫叫,一起喵喵喵~"歌词里唱的很动听,可是养过猫的主子们应该会很难引起共鸣,毕竟在家也没真的听主子们喵过多少次,兽医小明在这里辟个谣哦,猫咪的叫声可不只是喵喵叫. 猫咪 ...
- 【R言R语】系列之算法工程师入职半年的总结与感悟
0 导读 这是我入职半年后写在公众号里的一篇文章,在此分享到CSDN上,希望能和CSDN上的朋友们一起交流学习CV算法以及相应的知识.也欢迎大家关注我的公众号WeThinkIn. [R言R语]系列之算 ...
- 以能说会道为荣，以木言纳语为耻！
以能说会道为荣,以木言纳语为耻! 以能说会道为荣,以木言纳语为耻! 以能说会道为荣,以木言纳语为耻!
- 【活动总结】0723-COC深圳社区职言职语第1季活动总结之第1视角
0723-COC深圳社区职言职语第1季活动总结 地球有自转,活动不能断,话题不能停.一场愉快的户外+职场的畅谈交流会,就这样落下了帷幕-请大家跟随我的第一视角,一起看看我们的活动现场吧. 文章目录 1 ...
最新文章
- R语言基于自定义函数构建xgboost模型并使用LIME解释器进行模型预测结果解释：基于训练数据以及模型构建LIME解释器解释多个iris数据样本的预测结果、使用LIME解释器进行模型预测结果解释
- 一些关键字表明变量属性值
- Javascript作用域问题的构造函数的变量
- 土耳其电影公司选择Infortrend建立PB级数据存储基础设施
- xfce中仿gnome的多桌面的xfdashboard的用法
- html5文件阅读器api,html 5 读取本地文件API
- 小程序点击地图气泡获取气泡_气泡上的气泡
- [FZYZOJ 1038] 隧道
- 科大奥锐实验报告霍尔效应_中科大929半导体物理专业课高分学长考研经验
- mvd没什么每次参数双都多一个逗号_必看！PostgreSQL参数优化
- 如何在 Python 数据中灵活运用 Pandas 索引？
- 算法测试例子特殊输入形式
- 触发器 索引视图 游标 事务
- 聚合四方支付系统架构及所需配置
- maven报错The JAVA_HOME environment variable is not defined correctly
- 混乱之子第一季/全集Sons Of Anarchy迅雷下载
- 计算机里没有四款小游戏,90后最爱玩的4款“4399”小游戏，一个都没玩过的太可怜！...
- 近红外PbSAg2S量子点（齐岳生物）
- 运动控制卡讲解及实例应用
- c#创建word 表格垂直居中