+关注

HQoS 层级限速
点赞

2026-03-18 更新
21 次观看
HQoS 层级限速与 Meter Offload 实现方案

1.方案设计

我们通过Table跳转+Flow 优先级合理组织卸载的流表来实现硬件卸载流量的抓包。在此基础上通过层级Meter限速实现基于IP与端口粒度的硬件卸载限速。主要设计包含如下几个方面

  • IP粒度+端口粒度软件限速

  • IP+端口粒度Meter层级Offload限速

1.1 软件限速

OVS 软件转发路径已支持对虚拟机 Vhu 端口的出入向流量进行基于 BPS（比特率）的限速。由于一个虚拟机可能拥有多个 Vhu 端口，目前的限速能力仅支持以 Vhu 端口为粒度进行控制。为了实现更精细的资源控制，我们计划进一步支持基于 IP 地址粒度的限速策略。

1.1.1 Vhu 出向限速（虚机入向流量）

Vhu 出向流量的限速通过配置 qos 参数实现。数据面采用 DPDK 软件实现的单速率三色标记器（SRTCM）进行流量限速。目前仅启用了基于 BPS（比特率）的限速方式。

[root@openstack00012 zhangweili]# ovs-appctl qos/show vhu81d8dba3-96
QoS: vhu81d8dba3-96 egress-policer
cbs: 51200000
cir: 51200000

[root@openstack00012 zhangweili]# ovs-appctl qos/show-types vhu81d8dba3-96
QoS type: trtcm-policer  #双速率三色标记器
QoS type: egress-policer #单速率三色标记器

1.1.2 Vhu 入向限速（虚机出向流量）

系统通过在 other_config 中配置 Vhu 接口的入向限速策略，实现对虚机出向流量的控制。数据面采用 DPDK 软件实现的单速率三色标记器（SRTCM）进行流量标记和限速。目前仅启用了基于 BPS（比特率）的限速方式。

[root@openstack00012 zhangweili]# ovs-vsctl list int vhu81d8dba3-96
ingress_policing_burst: 409600
ingress_policing_kpkts_burst: 0
ingress_policing_kpkts_rate: 0
ingress_policing_rate: 409600
lacp_current        : []
link_resets         : 0
link_speed          : []
link_state          : up
lldp                : {}
mac                 : []
mac_in_use          : "00:00:00:00:00:00"

1.1.3 基于 IP 粒度的限速

在 Neutron 控制面，可通过下发基于 IP 地址的 OpenFlow 规则，并结合软件 Meter 实现对特定 IP 的流量限速。
为支持硬件卸载限速，在下发和卸载 flow 时，需同步构建并关联对应的 IP 粒度 Meter，实现精细化的 IP 级别 Offload 限速策略。

1、在br-int下发限速1000kbps，burst 100kbps
ovs-ofctl -O OpenFlow13 add-meter br-int "meter=1,kbps,bands=type=drop,rate=10000"

2、dump规则
[root@q2f2ostack01test zhangweili]# ovs-ofctl -O OpenFlow13 dump-meters br-int
OFPST_METER_CONFIG reply (OF1.3) (xid=0x2):
meter=1 kbps burst bands=
type=drop rate=1000 burst_size=100

3、Openflow引用Meter下发入向IP粒度限速规则
ovs-ofctl add-flow br-int "table=0, priority=6, ip,in_port=2,dl_vlan=3,nw_dst=172.16.12.245 actions=meter:1,set_field:fa:16:3e:63:47:12->eth_dst,resubmit(,60)"

4、dump flow，meter限速策略在recircle flow上
recirc_id(0),tunnel(tun_id=0x2dcab6,src=10.220.183.139,dst=10.237.208.26,tos=0x48,flags(-df+csum+key)),in_port(6),ct_state(-trk),packet_type(ns=0,id=0),eth(src=fe:16:4f:00:00:00,dst=fa:16:3e:63:47:12),eth_type(0x0800),ipv4(dst=172.16.12.245,proto=6,frag=no), packets:0, by
tes:0, used:never, actions:meter(0),ct(zone=3),recirc(0x2c)

5、修改rcu异步生效
[root@openstack00144 zhangweili]# ovs-ofctl -O OpenFlow13 dump-meter br-int
OFPST_METER_CONFIG reply (OF1.3) (xid=0x2):
meter=1 kbps bands=
type=drop rate=1000
[root@openstack00144 zhangweili]#
[root@openstack00144 zhangweili]# ovs-ofctl -O OpenFlow13 mod-meter br-int "meter=1,kbps,bands=type=drop,rate=2000"
[root@openstack00144 zhangweili]# ovs-ofctl -O OpenFlow13 dump-meter br-int
OFPST_METER_CONFIG reply (OF1.3) (xid=0x2):
meter=1 kbps bands=
type=drop rate=2000

6、出向openflow meter
ovs-ofctl -O OpenFlow13 add-meter br-int "meter=2,kbps,burst,bands=type=drop,rate=200000,burst_size=200000"

#出向IP粒度的Port
ovs-ofctl -O OpenFlow13 add-flow br-int "table=71,priority=65,ip,reg5=0x4,in_port=4,dl_src=fa:16:3e:c2:c0:fa,nw_src=172.16.13.105 actions=meter:2,ct(table=72,zone=NXM_NX_REG6[0..15])"

[root@openstack00144 zhangweili]# ovs-ofctl -Oopenflow13 dump-meter br-int
OFPST_METER_CONFIG reply (OF1.3) (xid=0x2):
meter=2 kbps burst bands=
type=drop rate=200000 burst_size=200000

7、出向recrcle flow
recirc_id(0),in_port(8),ct_state(trk),packet_type(ns=0,id=0),eth(src=fa:16:3e:c2:c0:fa),eth_type(0x0800),ipv4(src=172.16.13.105,dst=10.236.81.105/128.0.0.0,proto=1,frag=no), packets:36149, bytes:3542602, used:0.992s, actions:meter(1),ct(zone=1),recirc(0x1c)

8、出向封vxlan
recirc_id(0x1c),in_port(8),ct_state(-new+est-rel+rpl-inv+trk),ct_zone(0x1),ct_mark(0),packet_type(ns=0,id=0),eth(src=fa:16:3e:c2:c0:fa,dst=fa:16:3e:45:35:aa),eth_type(0x0800),ipv4(src=172.16.13.105,dst=10.236.81.105/255.255.224.0,
tos=0/0x3,frag=no), packets:36149, bytes:3542602, used:0.992s, actions:ct(offload),set(eth(dst=fa:16:3f:ed:6f:22)),tnl_push(tnl_port(3),header(size=50,type=4,eth(dst=00:00:5e:00:01:01,src=94:6d:ae:30:ef:b8,dl_type=0x0800),ipv4(src=10.236.81.105,dst=10.220.183.139,proto=17,tos=0,ttl=64,frag=0x4000),udp(src=0,dst=4789,csum=0x0),vxlan(flags=0x8000000,vni=0x2dcab6)),out_port(5)),6

为什么入向选择table0出向选择table 71?

  • table 0 是入流流量的起点，做简单的初筛，比如 VLAN 匹配，初步修改目的 MAC 等，然后跳转到后续的分类表（60）。这里流量量级较大。

  • table 71 主要负责连接跟踪前的流量分类（ct前阶段），为连接跟踪准备匹配条件（例如 IP、ARP、ICMP 等）。这里的规则匹配条件较细，priority 也相对高，能匹配到对应源 IP 或 ARP 信息。


Dpcls Meter Action

如果Recircle flow中Meter ID存在则优先使用Recircle Flow中的Meter ID做卸载，否则用Output Flow中的Meter ID做卸载，按照目前我们Openflow下发Meter Action的逻辑，出入向均在Recircle Flow中。

1.2 IP+端口粒度的 Meter 层级 Offload 限速

在实际部署中，虚拟机可能对应多个 VHU 接口，而虚拟机内部的单个网卡（如 eth0）又可能配置多个 IP 地址。因此，我们需要实现基于 IP 地址粒度的流量限速，以便对不同 IP 的流量进行精细化控制。同时，为了确保整体带宽策略一致性，这些 IP 粒度的限速策略应共享所属端口（VHU 口）上的端口粒度限速策略，实现 IP → 端口的 Meter 层级化限速。

1.2.1 Hqos

CX6 及以上的 Mellanox 网卡（如 ConnectX-6, ConnectX-6 Dx, ConnectX-7）支持硬件加速的 HQoS（Hierarchical QoS）功能，其中包括 Meter Hierarchy（限速层级）。下面来详细解释其含义及作用：

什么是 HQoS？

HQoS（Hierarchical Quality of Service） 是一种支持 多层次限速与调度 的 QoS 实现方式。相比简单的 flat QoS（单层限速），HQoS 可以精细控不同粒度的限速策略，例如Port->Port Group->VM->Network 粒度限速。每一层都可以独立配置带宽、突发等参数，实现更灵活的资源分配与隔离。

参考文档 Meter Hierarchy

如何使用HQoS实现IP+Port粒度限速

首先，下发端口粒度的 Meter 作为父 Meter，该 Meter 必须是终结（Termination）类型。对不同颜色的流量执行相应动作：绿色（Green）和黄色（Yellow）流量执行输出（Output）到端口或跳转（Jump）到指定流表，红色（Red）流量则丢弃（Drop）。

随后，下发 IP 粒度的 Meter，作为子 Meter。该 Meter 的绿色和黄色动作指向端口粒度的父 Meter，实现层级调用，红色动作同样丢弃（Drop）。

最后，下发匹配 IP 粒度的流表，将该流关联到 IP 粒度的 Meter，作为流的最后一个动作，从而实现 IP 到端口的层级限速策略。 参考文档 DPDK文档

2. 设计实现

2.1 HQoS 实现 IP + Port 粒度的硬件卸载限速

为实现更精细化的限速控制，我们基于 Mellanox 网卡 HQoS（Hierarchical QoS）能力，设计并实现了 IP + 端口粒度的限速策略。该方案通过构建 Meter 层级，并结合流表规则的硬件卸载，实现了限速策略的高性能下发与执行。

2.2 实现细节

2.2.1 Meter 层级设计

根据 HQoS 要求，层级 Meter 需要作为流表（flow）的最后一个 Action 下发。而 OVS 中流表的末尾 Action为：

  • 对于虚机出向流量（即从 Vhu 出发）：最后一个 Action 是 jump 到 TABLE_OUTPUT

  • 对于虚机入向流量（即流入 Vhu）：最后一个 Action 是 output 到目标 Vhu 端口

因此，设计中将 Port 粒度的 Meter 设置为 Termination 类型，其动作为：

  • 绿色（Green）/黄色（Yellow）：

    • 虚机入向流量：output 到 Vhu 端口

    • 虚机出向流量：jump 到 Table Output

  • 红色（Red）：统一 drop

2.2.2 Flow 与 Meter 的关联方式

在流表规则中：

  • 原本用于跳转（jump）或转发（output）的 Action，统一移动至对应的 端口粒度 Meter 动作中实现。

  • Flow 自身的最后一个 Action 改为 Meter，用于触发对应 IP 粒度限速策略。

每条带有 IP 粒度限速需求的流规则，在卸载（offload）前会自动创建对应的 IP 粒度 Meter，实现 IP ➝ Port 的限速层级结构。

IP 与 Port 粒度 Meter 的引用关系

每条 flow 下发时会对对应的 IP 粒度 HQoS（flow_qos）执行一次 ref，Flow 被删除时执行一次 unref。 IP 粒度 HQoS 创建时会将其所属的 Port 粒度 HQoS（vf_qos）作为父级，执行一次 ref 建立父子关系； 仅当 IP 粒度 HQoS 的引用计数降至初始值 1（即仅剩控制面引用）时，才会触发 RCU 延迟回收，最终释放对应的 HQoS 结构和硬件 Meter。

2.2.3 Meter策略添加

  • 端口粒度出入向Meter策略添加

    添加如下策略，ingress_policing 为虚机出向限速策略，qos为虚机入向限速策略。对于入向限速，当前软件实现采用单速率三色标记器（SRTCM）进行流量标记与控制。为统一软硬件限速行为，出入向限速卸载将统一采用双速率三色标记器（TRTCM） 实现，其中 eir 和 ebs 均设为 0，使其等价于单速率逻辑，方便后续拓展。

    ovs-vsctl set interface vhuc0375f25-ce \
  ingress_policing_rate=1000000 \
  ingress_policing_burst=1000000 \
  ingress_policing_kpkts_rate=0 \
  ingress_policing_kpkts_burst=0

ovs-vsctl set port vhue8e32d21-a6 qos=@newqos \
  -- --id=@newqos create qos type=egress-policer \
  other-config:cir=1000000 other-config:cbs=1000000

  • IP粒度Meter策略添加

    通过 OpenFlow 在 br-int 上下发限速策略时，首先下发包含 meter 动作的 flow，并将该限速策略作为 Action 引用。系统在下发包含 meter 动作的 DP flow 时，解析并记录 meter_id 至对应的 flow 数据结构中。由于 DP flow 中的 Meter 动作通常位于 recirculation flow 上，我们在卸载 flow 时也同时关联 recircle flow 与 output flow。在卸载阶段，如果 recircle flow 中存在 meter 动作，则优先卸载对应的 meter_id。

    1、在br-int下发限速1000kbps，burst 100kbps
ovs-ofctl -O OpenFlow13 add-meter br-int "meter=1,kbps,bands=type=drop,rate=10000"
2、Openflow引用Meter下发IP粒度限速规则
ovs-ofctl add-flow br-int "table=0, priority=6, ip,in_port=2,dl_vlan=3,nw_dst=172.16.12.245 actions=meter:1,set_field:fa:16:3e:63:47:12->eth_dst,resubmit(,60)"

3.Meter Action在recircle flow
recirc_id(0),tunnel(tun_id=0x2dcab6,src=10.220.183.139,dst=10.237.208.26,tos=0x48,flags(-df+csum+key)),in_port(6),ct_state(-trk),packet_type(ns=0,id=0),eth(src=fe:16:4f:00:00:00,dst=fa:16:3e:63:47:12),eth_type(0x0800),ipv4(dst=172.16.12.245,proto=6,frag=no), packets:0, by
tes:0, used:never, actions:meter(0),ct(zone=3),recirc(0x2c)

2.2.4 Meter删除

2.2.4.1 端口出入向 Meter 删除

  • 当用户将端口带宽限速配置设置为 0，或从数据库删除对应的限速策略时，系统不会立即删除硬件 Meter，而是将限速速率设置为最大带宽（例如 50G）以替代删除操作。

    原因如下：

    综上，采用将速率设置为最大带宽替代删除的方案，既简化了删除逻辑，避免异步复杂性，又确保了限速策略的软件层即时更新和系统稳定性。此外，端口粒度 Meter 资源占用较少，影响有限。

    ovs-vsctl set interface vhuc0375f25-ce \
  ingress_policing_rate=0 \
  ingress_policing_burst=0 \
  ingress_policing_kpkts_rate=0 \
  ingress_policing_kpkts_burst=0

ovs-vsctl set port vhue8e32d21-a6 qos=@newqos \
  -- --id=@newqos create qos type=egress-policer \
  other-config:cir=0 other-config:cbs=0

    • 软件与硬件状态异步
      端口粒度的硬件 Meter 删除需等待所有相关流粒度 Meter 删除完成（refcount 为初始值1，unref减到0）后才能执行，该过程存在异步延迟，端口Meter删除操作硬件状态与软件配置无法实时同步。

    • 删除操作不可中断且异步执行
      端口粒度硬件 Meter 删除进入延迟回收阶段后，无法中断或撤销，主线程无法阻塞等待删除完成。

    • 删除后立即新建无法生效
      如果用户在硬件 Meter 尚未完成删除期间重新添加限速配置，由于HQoS资源尚未释放，新配置的 HQoS 添加操作可能失败。而主线程通过 iface_reconfigure 下发限速策略的过程是一次性的，不会自动重试，HQoS资源继续执行已触发的释放操作，可能造成新配置下发丢失。

2.2.4.2 IP 粒度 Meter 卸载与删除流程

系统通过引用计数（refcount）与 RCU（Read-Copy-Update）机制协同控制 Flow 级别（即 IP 粒度）Meter 的卸载与删除过程，确保硬件 HQoS 生命周期安全可控，避免并发冲突与状态不一致问题。

RCU 删除保障机制

  • 当 Meter 的引用计数降至 0 时，进入等待RCU 静默周期；

  • 在该阶段，主线程与 PMD 线程无法再次对该 Meter 执行 ref 操作，避免并发访问冲突；

  • RCU 静默周期结束后，Meter 被彻底释放，包括内存资源及绑定的 HQoS Profile；

  • 若后续有新连接命中相关策略，将重新创建新的 Flow 和 HQoS 配置，确保功能恢复。

正常卸载与删除流程

典型卸载与删除流程如下：

  • Neutron 通过 ovs-ofctl 修改 OpenFlow 规则，移除 Flow 上的 Meter Action；

  • Revalidator 线程异步刷新 dpcls flow，清除 Meter Action，并触发 Offload Sync 检查；

  • Offload Sync 线程识别该 Flow 已过期，通知主线程执行卸载流程；

  • 主线程卸载 Flow 并对其绑定的 Meter 执行一次 unref 操作；

  • 所有关联 Flow 删除后，Meter 引用计数降为 1，此时仅保留 Neutron 软件层配置的引用；

  • Neutron 后续调用 del-meter 删除软件 Meter，引用计数降至 0；

  • Meter 进入 RCU 延迟删除阶段，静默周期结束后彻底释放资源。

异常时序与卸载失败场景

某些异常时序可能导致 Flow 卸载与 Meter 删除存在短暂不同步的情况。此时系统依赖 RCU 与引用计数机制保证最终一致性。典型异常流程如下：

  • Neutron 已从 OpenFlow 中移除 Flow 的 Meter Action；

  • Revalidator 未及时刷新，dpcls flow 中仍保留旧 Meter Action；

  • 新建连接命中该旧 Flow，触发卸载流程并尝试 ref Meter；

  • 根据 Meter 当前状态，可能发生以下三种情况：

场景 A：Meter 已进入 RCU 删除阶段（引用计数为 0）

  • ref 操作失败，Flow 卸载失败，流量走软转；

  • RCU 静默周期结束后，Meter 被彻底释放；

  • 如果RCU周期后，Flow仍携带Meter Action；

  • 若该时刻未建立新 Meter，Flow 卸载成功()并触发新 HQoS 创建，后续Revalidator刷新后再执行一次RCU删除流程(场景B)；

  • 整体 HQoS 生命周期安全，数据面不受影响。

场景 B：Meter 尚未进入 RCU 删除阶段（引用计数刚降至 1）

  • ref 操作成功，Flow 卸载流程继续；

  • 直到dpcls flow 刷新，卸载flow被删除，Meter 引用计数减为 0；

  • HQoS Meter 随后进入 RCU 删除阶段，静默周期结束后资源释放；

  • 卸载流程闭环，资源状态正常回收。

场景 C：RCU 删除尚未开始，软件层重新添加了同名 Meter

  • 即使引用计数曾降至 1，新的配置建立了有效引用；

  • 此时旧 Flow 的卸载流程中 ref 操作成功；

  • Flow 卸载成功，HQoS Meter 被引用，不再进入删除流程；

  • 此机制支持动态恢复配置，避免 Meter 被误删。

总结，Flow 与 Meter 引用关系的删除闭环控制

Flow 对 Meter 的引用关系在 RCU 删除阶段前仍可通过重新引用（ref）中断 HQoS 的删除流程；
一旦进入 RCU 删除阶段，所有线程将无法对该 Meter 执行 ref 操作，HQoS 删除不可中断，需等待 RCU 周期结束。

该机制核心在于实现对 Meter 与引用它的 OpenFlow 规则之间的删除闭环控制：

  • OVS 层虽为异步处理，存在刷新延迟（如 Revalidator 未及时清理 dpcls flow或触发了旧Flow的卸载未及时处理），但配合引用计数和 RCU 延迟删除机制，能够保障流程最终一致；

  • HQoS 生命周期的控制权依附于Meter引用计数变化，系统确保 Meter 资源仅在确认无 Flow 使用时释放；

ovs-ofctl -O OpenFlow13 del-meter br-int \
"meter=1,kbps,burst,bands=type=drop,rate=20,burst_size=20"

2.2.5 Vhu 端口删除

当虚拟机发生热迁移或被删除时，Vhu 端口将被移除。此时需彻底清理该端口相关的 IP 粒度和 Port 粒度限速策略，并释放其对应的 HQoS 资源。

整体流程如下：

  • 接口销毁触发 HQoS 的 unref 操作
    在 iface_destroy__ 阶段，会依次处理 Vhu-xxx-ingress 和 Vhu-xxx-egress 接口，并执行如下两类 HQoS 的 unref：

    • Port 粒度 HQoS（Port HQoS）

    • 子层级 IP 粒度 HQoS（Flow HQoS）

  • 端口删除时主动触发 Port HQoS 的 unref
    在 Vhu 端口正常存在期间，即便没有 flow 卸载，为避免Port粒度Meter频繁增删，其 Port HQoS 对象也不会被销毁（参考 2.2.4.1 “端口出入向 Meter 删除”）。因此，在 Vhu 端口删除时，需显式调用一次 Port HQoS 的 unref，避免出现资源泄露。

  • Flow 删除未触发 Flow HQoS 销毁的补充逻辑

    Flow 所引用的 IP 粒度 HQoS（Flow HQoS）对象，在 flow 卸载后并不会立即销毁，因为其绑定的软件 Meter 可能尚未通过 ovs-ofctl del-meter 显式删除。为保持软件与硬件状态一致（参考 2.2.4.2 “IP 粒度 Meter 卸载与删除流程”），此类 HQoS 对象仍将被保留。然而，删除 Vhu 端口时并不会触发 del-meter 操作，因此需在 iface_destroy__ 中显式执行一次 Flow HQoS 的 unref，以确保其引用计数正确归零，最终完成资源释放。

    例外情况：

    当 OVS 重启或 bridge 被删除时，系统会同时触发以下两个操作：

    在这种情况下，可能会出现如下问题：

    为避免此类引用计数失衡，需在 Flow HQoS 的 unref 逻辑中增加健壮性判断：当检测到引用计数已为 0 或小于 0 时，跳过该 unref 操作，确保销毁流程安全可控。

    • del-meter 被重复调用，导致 meter 删除操作先于 flow 卸载操作执行，进而出现尝试删除仍被引用的 meter 导致失败的情况。

    • 对同一 HQoS 对象多次执行 unref，由于对象可能已被销毁，可能引发引用计数异常或程序崩溃。

    • 网桥删除会执行 del-meter 操作，删除该 bridge 上所有已配置的 Meter；

    • 网桥删除会销毁 bridge 端口，进入 iface_destroy__ 流程，也会执行 del-meter 操作。

  • HQoS 的异步释放机制
    IP/Port 粒度的 HQoS 均采用 RCU 延迟释放机制，释放过程如下：

    • 当某个 Flow HQoS 的引用计数降为 0（说明所有 flow 已被删除），不会再被ref成功，会触发其 destroy 操作；

    • 在销毁 Flow HQoS 时，会对其依赖的 Port HQoS 执行一次 unref；

    • 若此时 Port HQoS 的引用计数也为 0，则也将被 RCU 延迟销毁；

    • 最终实现对该 Vhu 接口下所有 HQoS（IP + Port 粒度）资源的完整清理与释放。

2.2.6 DPDK0 端口删除

正常情况下DPDK0端口不会删除，如果br-int 删除或者OVS重启导致DPDK0删除，会同时删除Vhu端口，正常走Vhu端口删除逻辑去释放出入向的HQOS(参考2.2.5 Vhu 端口删除)。如果异常操作需要单独删除DPDK0端口，那么需要删除所有下发在DPDK0端口上的Meter。

2.2.7 Meter带宽修改

  • 端口出入向Meter带宽修改

    在端口粒度限速配置发生变更时，会触发对应接口（iface）的 reconfigure 操作。该流程会直接更新并生效已卸载到硬件的 Meter Profile 的限速参数（如带宽），无需删除并重下 Meter，变更可以即时生效。Port粒度Hqos Meter不会真正删除，所以这里是并发安全的。

    ovs-vsctl set interface vhuc0375f25-ce \
  ingress_policing_rate=1000000 \
  ingress_policing_burst=1000000 \
  ingress_policing_kpkts_rate=0 \
  ingress_policing_kpkts_burst=0

ovs-vsctl set port vhue8e32d21-a6 qos=@newqos \
  -- --id=@newqos create qos type=egress-policer \
  other-config:cir=0 other-config:cbs=0

  • IP粒度的限速带宽修改

    IP 粒度限速配置修改行为分析

    在进行 IP 粒度的限速配置修改时，系统会通过查询对应的 DP Meter，直接更新已卸载 Flow 的 Meter Profile 中的限速参数（如带宽、突发值），无需删除并重新下发 Meter。更新操作是即时生效的。

    ovs-ofctl del 与 set 操作并发行为分析

    总结

    ovs-ofctl -O OpenFlow13 mod-meter br-int \
"meter=1,kbps,burst,bands=type=drop,rate=20,burst_size=20"

    • 删除后立即下发新配置时，若仍处于 RCU 等待阶段，可以成功更新速率，不触发新建；

    • 若 RCU 回收完成后再尝试更新，由于 HQoS 已被释放，将查不到对象，set 操作不会生效，也不会触发新建逻辑；

    • 系统整体行为具有明确边界，确保不会因删除与添加操作并发而引起状态不一致。

    • 当用户通过 ovs-ofctl del 删除软件层 Meter 后，即便对应的 HQoS 正在进入 RCU 延迟释放阶段，仍可以查找到该 HQoS 对象，并进行速率更新操作，此时更新会成功生效。RCU 延迟释放机制下，HQoS 对象在主线程与 PMD 线程各自“静默”一轮前，不会被真正销毁，因此不会影响在此期间的更新行为。

    • 若在删除后立即使用 ovs-ofctl set 添加同名 Meter，系统此时若能查到 HQoS，会进行速率更新；若已经完成 RCU 释放，HQoS 查不到，set 操作将直接返回，不会触发新建 HQoS。

3.同机流量限速Meter如何处理

同机跨机流量转发图

3.1 流量限速分析

3.1.1 同机流量与跨机流量共用Meter

由于Meter Action是下发在rte flow对应具体的input端口，同机流量限速需要先过源虚机出向流量限速规则、再过目的虚机入向流量限速规则，把原目虚机原有的限速规则串联，具体示意图如下：

跨机流量Meter Action串联

  • VM Ingress Meter Action：IP Egress Meter → VF Egress Meter → Output (vhu)

  • VM Egress Meter Action：IP Ingress Meter → VF Ingress Meter → Jump to Output Table → Output Table → Output (dpdk0)

同机流量Meter Action串联

  • VM1 Egress Meter Action ：IP1 Ingress Meter → VF1 Ingress Meter (拼接) → IP2 Egress Meter → VF2 Egress Meter → Output (vhu2)

  • VM2 Egress Meter Action ：IP2 Ingress Meter → VF2 Ingress Meter (拼接) → IP1 Egress Meter → VF1 Egress Meter → Output (vhu1)

Meter Action串联差异分析

层级结构变化

  • 原逻辑（跨机流量）：VF Ingress Meter 的子 Action 为 Jump to Output Table

  • 同机优化后：子 Action 修改为 IP Egress Meter，实现更细粒度限速控制

Meter 安装位置变化

  • 原逻辑（跨机流量）：VM Ingress 流量的 Meter 安装在 dpdk0 接口上

  • 同机流量共存：Meter 需同时安装在访问目标 VM 的源 vhu 接口上

冲突问题

  • 虚机入流量Meter 无法同时部署在 dpdk0 和多个源 vhu 接口上，导致无法同时限制这两类流量的带宽。

3.1.2 同机流量走软转

由于同机流量卸载HQoS限速无法实现，我们决定让Vhu到Vhu的同机流量走软转处理，通过软件来限速。在流表下发解析action时判断原目端口为Vhu为同机虚机转发Flow，卸载时跳过。

4.总结

我们基于 OpenFlow 与 OVS 原生的 Port 级 Ingress/Egress 限速策略，结合 Meter Action 的层级串联能力，实现了虚拟机出入向流量在 IP->Port 粒度的 HQoS 限速控制。


Copyright©2005-2026 360.cn  版权所有  360互联网安全中心   北京举报中心

京ICP证080047号[京ICP备08010314号-6]   工商营业执照