QoS Ingress bandwidth limit with OVS backend may not work as expected
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
neutron |
Fix Released
|
Medium
|
Slawek Kaplonski |
Bug Description
According to the OVS faq https:/
Q: I configured Quality of Service (QoS) in my OpenFlow network by adding
records to the QoS and Queue table, but the results aren’t what I expect.
A: Did you install OpenFlow flows that use your queues? This is the primary
way to tell Open vSwitch which queues you want to use. If you don’t do this,
then the default queue will be used, which will probably not have the effect
you want.
According to info from the OVS developer, Ilya Maximets "OVS doesn't define what the "default queue" is. [...] So, using the set_queue action is a correct way to configure QoS, even if the queue 0 is currently a "default queue". It's not guaranteed that it always will be."
Because of that Neutron OVS agent should configure correct OF rules to send traffic to the required QoS queue always.
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (master) | #1 |
Changed in neutron: | |
status: | Confirmed → In Progress |
OpenStack Infra (hudson-openstack) wrote : | #2 |
Fix proposed to branch: master
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Related fix merged to neutron (master) | #3 |
Reviewed: https:/
Committed: https:/
Submitter: "Zuul (22348)"
Branch: master
commit 0255f41ad0405ea
Author: Slawek Kaplonski <email address hidden>
Date: Mon Jan 31 15:42:04 2022 +0100
Clean duplicated QoS bandwidth related methods in ovs_lib module
This patch also some helper methods used in the
minimum bandwidth qos methods as it seems that we had things almost
duplicated in methods like _find/update/
find/
It also moves functional tests for the ingress bandwidth limit rules
methods to more appropriate module.
Related-bug: 1959567
Change-Id: I848af01c8fe3a0
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (master) | #4 |
Reviewed: https:/
Committed: https:/
Submitter: "Zuul (22348)"
Branch: master
commit f7ab90baad83823
Author: Slawek Kaplonski <email address hidden>
Date: Tue Mar 8 16:44:59 2022 +0100
Fix ingress bandwidth limit in the openvswitch agent
For ingress bandwidth limiting openvswitch agent is using QoS and queues
from the Open vSwitch. There is always queue 0 used for that purpose.
Initially, when this feature was implemented, we assumed that queue 0 is
kind of the "default" queue to which all traffic will be send if there
are no other queues. But that's not true thus ingress bandwidth limiting
wasn't working properly with this agent.
This patch fixes that issue but adding in the table=0 of the br-int
additional OF rule to send all traffic to the queue 0.
In this queue for some ports there can be QoS configured
and then it will be applied for the port. If port don't have any QoS
configured, nothing will happen and all will work like before this
patch.
Biggest problem with that solution was the case when also ports with
minimum bandwidth are on the same node becuase such ports are using
different queues (queue number is the same as ofport number of the tap
interface).
In case when traffic is going from the port with minimum bandwidth QoS
to the port which has ingress bw limit configured, traffic is going only
through br-int and will use queue 0 to apply ingress bw limit properly.
In case when traffic from port with minimum bandwidth set needs to go
out from the host, it will always use physical bridge (minimum bandwidth
is only supported for the provider networks) and proper queue will be
set for such traffic in the physical bridge.
To be able to set proper queue in the physical bridge, this patch adds
additional OF rule to the br-int to set queue_num value in the pkt_mark
field [1] as this seems to be only field which can "survive" passing
bridges.
[1] https:/
Closes-Bug: #1959567
Change-Id: I1e31565475f38c
Changed in neutron: | |
status: | In Progress → Fix Released |
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to neutron (stable/yoga) | #5 |
Related fix proposed to branch: stable/yoga
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (stable/yoga) | #6 |
Fix proposed to branch: stable/yoga
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to neutron (stable/xena) | #7 |
Related fix proposed to branch: stable/xena
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (stable/xena) | #8 |
Fix proposed to branch: stable/xena
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to neutron (stable/wallaby) | #9 |
Related fix proposed to branch: stable/wallaby
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (stable/wallaby) | #10 |
Fix proposed to branch: stable/wallaby
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to neutron (stable/victoria) | #11 |
Related fix proposed to branch: stable/victoria
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (stable/victoria) | #12 |
Fix proposed to branch: stable/victoria
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to neutron (stable/ussuri) | #13 |
Related fix proposed to branch: stable/ussuri
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (stable/ussuri) | #14 |
Fix proposed to branch: stable/ussuri
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to neutron (stable/train) | #15 |
Related fix proposed to branch: stable/train
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (stable/train) | #16 |
Fix proposed to branch: stable/train
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Related fix merged to neutron (stable/xena) | #17 |
Reviewed: https:/
Committed: https:/
Submitter: "Zuul (22348)"
Branch: stable/xena
commit 18e05b5b2aad44c
Author: Slawek Kaplonski <email address hidden>
Date: Mon Jan 31 15:42:04 2022 +0100
Clean duplicated QoS bandwidth related methods in ovs_lib module
This patch also some helper methods used in the
minimum bandwidth qos methods as it seems that we had things almost
duplicated in methods like _find/update/
find/
It also moves functional tests for the ingress bandwidth limit rules
methods to more appropriate module.
Related-bug: 1959567
Change-Id: I848af01c8fe3a0
(cherry picked from commit 0255f41ad0405ea
tags: | added: in-stable-xena |
OpenStack Infra (hudson-openstack) wrote : Related fix merged to neutron (stable/wallaby) | #18 |
Reviewed: https:/
Committed: https:/
Submitter: "Zuul (22348)"
Branch: stable/wallaby
commit df5af1347789ff3
Author: Slawek Kaplonski <email address hidden>
Date: Mon Jan 31 15:42:04 2022 +0100
Clean duplicated QoS bandwidth related methods in ovs_lib module
This patch also some helper methods used in the
minimum bandwidth qos methods as it seems that we had things almost
duplicated in methods like _find/update/
find/
It also moves functional tests for the ingress bandwidth limit rules
methods to more appropriate module.
Conflicts:
Related-bug: 1959567
Change-Id: I848af01c8fe3a0
(cherry picked from commit 0255f41ad0405ea
(cherry picked from commit 18e05b5b2aad44c
tags: | added: in-stable-wallaby |
OpenStack Infra (hudson-openstack) wrote : Related fix merged to neutron (stable/ussuri) | #19 |
Reviewed: https:/
Committed: https:/
Submitter: "Zuul (22348)"
Branch: stable/ussuri
commit 44a22bb15c7e62e
Author: Slawek Kaplonski <email address hidden>
Date: Mon Jan 31 15:42:04 2022 +0100
Clean duplicated QoS bandwidth related methods in ovs_lib module
This patch also some helper methods used in the
minimum bandwidth qos methods as it seems that we had things almost
duplicated in methods like _find/update/
find/
It also moves functional tests for the ingress bandwidth limit rules
methods to more appropriate module.
Conflicts:
Related-bug: 1959567
Change-Id: I848af01c8fe3a0
(cherry picked from commit 0255f41ad0405ea
(cherry picked from commit 18e05b5b2aad44c
(cherry picked from commit 9e3aa7e3d66f8de
tags: | added: in-stable-ussuri |
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (stable/xena) | #20 |
Reviewed: https:/
Committed: https:/
Submitter: "Zuul (22348)"
Branch: stable/xena
commit 5573230d30a7beb
Author: Slawek Kaplonski <email address hidden>
Date: Tue Mar 8 16:44:59 2022 +0100
Fix ingress bandwidth limit in the openvswitch agent
For ingress bandwidth limiting openvswitch agent is using QoS and queues
from the Open vSwitch. There is always queue 0 used for that purpose.
Initially, when this feature was implemented, we assumed that queue 0 is
kind of the "default" queue to which all traffic will be send if there
are no other queues. But that's not true thus ingress bandwidth limiting
wasn't working properly with this agent.
This patch fixes that issue but adding in the table=0 of the br-int
additional OF rule to send all traffic to the queue 0.
In this queue for some ports there can be QoS configured
and then it will be applied for the port. If port don't have any QoS
configured, nothing will happen and all will work like before this
patch.
Biggest problem with that solution was the case when also ports with
minimum bandwidth are on the same node becuase such ports are using
different queues (queue number is the same as ofport number of the tap
interface).
In case when traffic is going from the port with minimum bandwidth QoS
to the port which has ingress bw limit configured, traffic is going only
through br-int and will use queue 0 to apply ingress bw limit properly.
In case when traffic from port with minimum bandwidth set needs to go
out from the host, it will always use physical bridge (minimum bandwidth
is only supported for the provider networks) and proper queue will be
set for such traffic in the physical bridge.
To be able to set proper queue in the physical bridge, this patch adds
additional OF rule to the br-int to set queue_num value in the pkt_mark
field [1] as this seems to be only field which can "survive" passing
bridges.
[1] https:/
Closes-Bug: #1959567
Change-Id: I1e31565475f38c
(cherry picked from commit f7ab90baad83823
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (stable/wallaby) | #21 |
Reviewed: https:/
Committed: https:/
Submitter: "Zuul (22348)"
Branch: stable/wallaby
commit 6af566a89a1bc03
Author: Slawek Kaplonski <email address hidden>
Date: Tue Mar 8 16:44:59 2022 +0100
Fix ingress bandwidth limit in the openvswitch agent
For ingress bandwidth limiting openvswitch agent is using QoS and queues
from the Open vSwitch. There is always queue 0 used for that purpose.
Initially, when this feature was implemented, we assumed that queue 0 is
kind of the "default" queue to which all traffic will be send if there
are no other queues. But that's not true thus ingress bandwidth limiting
wasn't working properly with this agent.
This patch fixes that issue but adding in the table=0 of the br-int
additional OF rule to send all traffic to the queue 0.
In this queue for some ports there can be QoS configured
and then it will be applied for the port. If port don't have any QoS
configured, nothing will happen and all will work like before this
patch.
Biggest problem with that solution was the case when also ports with
minimum bandwidth are on the same node becuase such ports are using
different queues (queue number is the same as ofport number of the tap
interface).
In case when traffic is going from the port with minimum bandwidth QoS
to the port which has ingress bw limit configured, traffic is going only
through br-int and will use queue 0 to apply ingress bw limit properly.
In case when traffic from port with minimum bandwidth set needs to go
out from the host, it will always use physical bridge (minimum bandwidth
is only supported for the provider networks) and proper queue will be
set for such traffic in the physical bridge.
To be able to set proper queue in the physical bridge, this patch adds
additional OF rule to the br-int to set queue_num value in the pkt_mark
field [1] as this seems to be only field which can "survive" passing
bridges.
[1] https:/
Closes-Bug: #1959567
Change-Id: I1e31565475f38c
(cherry picked from commit f7ab90baad83823
(cherry picked from commit 5573230d30a7beb
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (stable/ussuri) | #22 |
Reviewed: https:/
Committed: https:/
Submitter: "Zuul (22348)"
Branch: stable/ussuri
commit e59a7d5c3d4b29b
Author: Slawek Kaplonski <email address hidden>
Date: Tue Mar 8 16:44:59 2022 +0100
Fix ingress bandwidth limit in the openvswitch agent
For ingress bandwidth limiting openvswitch agent is using QoS and queues
from the Open vSwitch. There is always queue 0 used for that purpose.
Initially, when this feature was implemented, we assumed that queue 0 is
kind of the "default" queue to which all traffic will be send if there
are no other queues. But that's not true thus ingress bandwidth limiting
wasn't working properly with this agent.
This patch fixes that issue but adding in the table=0 of the br-int
additional OF rule to send all traffic to the queue 0.
In this queue for some ports there can be QoS configured
and then it will be applied for the port. If port don't have any QoS
configured, nothing will happen and all will work like before this
patch.
Biggest problem with that solution was the case when also ports with
minimum bandwidth are on the same node becuase such ports are using
different queues (queue number is the same as ofport number of the tap
interface).
In case when traffic is going from the port with minimum bandwidth QoS
to the port which has ingress bw limit configured, traffic is going only
through br-int and will use queue 0 to apply ingress bw limit properly.
In case when traffic from port with minimum bandwidth set needs to go
out from the host, it will always use physical bridge (minimum bandwidth
is only supported for the provider networks) and proper queue will be
set for such traffic in the physical bridge.
To be able to set proper queue in the physical bridge, this patch adds
additional OF rule to the br-int to set queue_num value in the pkt_mark
field [1] as this seems to be only field which can "survive" passing
bridges.
[1] https:/
Closes-Bug: #1959567
Change-Id: I1e31565475f38c
(cherry picked from commit f7ab90baad83823
(cherry picked from commit 5573230d30a7beb
(cherry picked from commit 4a0ca56fe57dbab
OpenStack Infra (hudson-openstack) wrote : Related fix merged to neutron (stable/victoria) | #23 |
Reviewed: https:/
Committed: https:/
Submitter: "Zuul (22348)"
Branch: stable/victoria
commit 9e3aa7e3d66f8de
Author: Slawek Kaplonski <email address hidden>
Date: Mon Jan 31 15:42:04 2022 +0100
Clean duplicated QoS bandwidth related methods in ovs_lib module
This patch also some helper methods used in the
minimum bandwidth qos methods as it seems that we had things almost
duplicated in methods like _find/update/
find/
It also moves functional tests for the ingress bandwidth limit rules
methods to more appropriate module.
Conflicts:
Related-bug: 1959567
Change-Id: I848af01c8fe3a0
(cherry picked from commit 0255f41ad0405ea
(cherry picked from commit 18e05b5b2aad44c
tags: | added: in-stable-victoria |
OpenStack Infra (hudson-openstack) wrote : Related fix merged to neutron (stable/yoga) | #24 |
Reviewed: https:/
Committed: https:/
Submitter: "Zuul (22348)"
Branch: stable/yoga
commit 015e82b338b0f09
Author: Slawek Kaplonski <email address hidden>
Date: Mon Jan 31 15:42:04 2022 +0100
Clean duplicated QoS bandwidth related methods in ovs_lib module
This patch also some helper methods used in the
minimum bandwidth qos methods as it seems that we had things almost
duplicated in methods like _find/update/
find/
It also moves functional tests for the ingress bandwidth limit rules
methods to more appropriate module.
Related-bug: 1959567
Change-Id: I848af01c8fe3a0
(cherry picked from commit 0255f41ad0405ea
tags: | added: in-stable-yoga |
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (stable/yoga) | #25 |
Reviewed: https:/
Committed: https:/
Submitter: "Zuul (22348)"
Branch: stable/yoga
commit 8c8066067b57641
Author: Slawek Kaplonski <email address hidden>
Date: Tue Mar 8 16:44:59 2022 +0100
Fix ingress bandwidth limit in the openvswitch agent
For ingress bandwidth limiting openvswitch agent is using QoS and queues
from the Open vSwitch. There is always queue 0 used for that purpose.
Initially, when this feature was implemented, we assumed that queue 0 is
kind of the "default" queue to which all traffic will be send if there
are no other queues. But that's not true thus ingress bandwidth limiting
wasn't working properly with this agent.
This patch fixes that issue but adding in the table=0 of the br-int
additional OF rule to send all traffic to the queue 0.
In this queue for some ports there can be QoS configured
and then it will be applied for the port. If port don't have any QoS
configured, nothing will happen and all will work like before this
patch.
Biggest problem with that solution was the case when also ports with
minimum bandwidth are on the same node becuase such ports are using
different queues (queue number is the same as ofport number of the tap
interface).
In case when traffic is going from the port with minimum bandwidth QoS
to the port which has ingress bw limit configured, traffic is going only
through br-int and will use queue 0 to apply ingress bw limit properly.
In case when traffic from port with minimum bandwidth set needs to go
out from the host, it will always use physical bridge (minimum bandwidth
is only supported for the provider networks) and proper queue will be
set for such traffic in the physical bridge.
To be able to set proper queue in the physical bridge, this patch adds
additional OF rule to the br-int to set queue_num value in the pkt_mark
field [1] as this seems to be only field which can "survive" passing
bridges.
[1] https:/
Closes-Bug: #1959567
Change-Id: I1e31565475f38c
(cherry picked from commit f7ab90baad83823
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (stable/victoria) | #26 |
Reviewed: https:/
Committed: https:/
Submitter: "Zuul (22348)"
Branch: stable/victoria
commit 4a0ca56fe57dbab
Author: Slawek Kaplonski <email address hidden>
Date: Tue Mar 8 16:44:59 2022 +0100
Fix ingress bandwidth limit in the openvswitch agent
For ingress bandwidth limiting openvswitch agent is using QoS and queues
from the Open vSwitch. There is always queue 0 used for that purpose.
Initially, when this feature was implemented, we assumed that queue 0 is
kind of the "default" queue to which all traffic will be send if there
are no other queues. But that's not true thus ingress bandwidth limiting
wasn't working properly with this agent.
This patch fixes that issue but adding in the table=0 of the br-int
additional OF rule to send all traffic to the queue 0.
In this queue for some ports there can be QoS configured
and then it will be applied for the port. If port don't have any QoS
configured, nothing will happen and all will work like before this
patch.
Biggest problem with that solution was the case when also ports with
minimum bandwidth are on the same node becuase such ports are using
different queues (queue number is the same as ofport number of the tap
interface).
In case when traffic is going from the port with minimum bandwidth QoS
to the port which has ingress bw limit configured, traffic is going only
through br-int and will use queue 0 to apply ingress bw limit properly.
In case when traffic from port with minimum bandwidth set needs to go
out from the host, it will always use physical bridge (minimum bandwidth
is only supported for the provider networks) and proper queue will be
set for such traffic in the physical bridge.
To be able to set proper queue in the physical bridge, this patch adds
additional OF rule to the br-int to set queue_num value in the pkt_mark
field [1] as this seems to be only field which can "survive" passing
bridges.
[1] https:/
Closes-Bug: #1959567
Change-Id: I1e31565475f38c
(cherry picked from commit f7ab90baad83823
(cherry picked from commit 5573230d30a7beb
OpenStack Infra (hudson-openstack) wrote : Related fix merged to neutron (stable/train) | #27 |
Reviewed: https:/
Committed: https:/
Submitter: "Zuul (22348)"
Branch: stable/train
commit ec08253f81367fe
Author: Slawek Kaplonski <email address hidden>
Date: Mon Jan 31 15:42:04 2022 +0100
Clean duplicated QoS bandwidth related methods in ovs_lib module
This patch also some helper methods used in the
minimum bandwidth qos methods as it seems that we had things almost
duplicated in methods like _find/update/
find/
It also moves functional tests for the ingress bandwidth limit rules
methods to more appropriate module.
Conflicts:
Related-bug: 1959567
Change-Id: I848af01c8fe3a0
(cherry picked from commit 0255f41ad0405ea
(cherry picked from commit 18e05b5b2aad44c
(cherry picked from commit 9e3aa7e3d66f8de
(cherry picked from commit 44a22bb15c7e62e
tags: | added: in-stable-train |
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (stable/train) | #28 |
Reviewed: https:/
Committed: https:/
Submitter: "Zuul (22348)"
Branch: stable/train
commit 196ab6bea12f948
Author: Slawek Kaplonski <email address hidden>
Date: Tue Mar 8 16:44:59 2022 +0100
Fix ingress bandwidth limit in the openvswitch agent
For ingress bandwidth limiting openvswitch agent is using QoS and queues
from the Open vSwitch. There is always queue 0 used for that purpose.
Initially, when this feature was implemented, we assumed that queue 0 is
kind of the "default" queue to which all traffic will be send if there
are no other queues. But that's not true thus ingress bandwidth limiting
wasn't working properly with this agent.
This patch fixes that issue but adding in the table=0 of the br-int
additional OF rule to send all traffic to the queue 0.
In this queue for some ports there can be QoS configured
and then it will be applied for the port. If port don't have any QoS
configured, nothing will happen and all will work like before this
patch.
Biggest problem with that solution was the case when also ports with
minimum bandwidth are on the same node becuase such ports are using
different queues (queue number is the same as ofport number of the tap
interface).
In case when traffic is going from the port with minimum bandwidth QoS
to the port which has ingress bw limit configured, traffic is going only
through br-int and will use queue 0 to apply ingress bw limit properly.
In case when traffic from port with minimum bandwidth set needs to go
out from the host, it will always use physical bridge (minimum bandwidth
is only supported for the provider networks) and proper queue will be
set for such traffic in the physical bridge.
To be able to set proper queue in the physical bridge, this patch adds
additional OF rule to the br-int to set queue_num value in the pkt_mark
field [1] as this seems to be only field which can "survive" passing
bridges.
[1] https:/
Conflicts:
Closes-Bug: #1959567
Change-Id: I1e31565475f38c
(cherry picked from commit f7ab90baad83823
(cherry picked from commit 5573230d30a7beb
(cherry picked from commit 4a0ca56fe57dbab
(cherry picked from commit e59a7d5c3d4b29b
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/neutron 17.4.0 | #29 |
This issue was fixed in the openstack/neutron 17.4.0 release.
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/neutron 18.3.0 | #30 |
This issue was fixed in the openstack/neutron 18.3.0 release.
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/neutron 19.2.0 | #31 |
This issue was fixed in the openstack/neutron 19.2.0 release.
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to neutron-lib (master) | #32 |
Related fix proposed to branch: master
Review: https:/
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/neutron 20.1.0 | #33 |
This issue was fixed in the openstack/neutron 20.1.0 release.
OpenStack Infra (hudson-openstack) wrote : Related fix merged to neutron-lib (master) | #34 |
Reviewed: https:/
Committed: https:/
Submitter: "Zuul (22348)"
Branch: master
commit 231067cabadb91e
Author: Slawek Kaplonski <email address hidden>
Date: Wed Apr 27 16:49:26 2022 +0200
Rehome ovsfw constants and utils modules
Constants module contains definition of the OF registry numbers used
by ovs firewall driver.
After [1] some other registries are also used to store information
related to QoS bw limit and min bw rules.
So it would be good to have list of all used registers in one place and
reuse them where it's needed. That's why this patch moves those
constants to the neutron_lib.
Additionally it also adds utils module with some helper functions which
are using those constants and are actually used not only in neutron but
also in neutron-fwaas.
[1] https:/
Related-Bug: #1959567
Change-Id: I89cc83699770e9
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/neutron 21.0.0.0rc1 | #35 |
This issue was fixed in the openstack/neutron 21.0.0.0rc1 release candidate.
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/neutron train-eol | #36 |
This issue was fixed in the openstack/neutron train-eol release.
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/neutron ussuri-eol | #37 |
This issue was fixed in the openstack/neutron ussuri-eol release.
Fix proposed to branch: master /review. opendev. org/c/openstack /neutron/ +/827112
Review: https:/