QoS Ingress bandwidth limit with OVS backend may not work as expected

Bug #1959567 reported by Slawek Kaplonski
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
neutron
Fix Released
Medium
Slawek Kaplonski

Bug Description

According to the OVS faq https://docs.openvswitch.org/en/latest/faq/qos/

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.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (master)

Fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/neutron/+/827112

Changed in neutron:
status: Confirmed → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote :

Fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/neutron/+/832662

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix merged to neutron (master)

Reviewed: https://review.opendev.org/c/openstack/neutron/+/827112
Committed: https://opendev.org/openstack/neutron/commit/0255f41ad0405eac8b2a4e0870513846e2660f7f
Submitter: "Zuul (22348)"
Branch: master

commit 0255f41ad0405eac8b2a4e0870513846e2660f7f
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/delete_{qos,queue} and
    find/update/delete_{qos,queue}.

    It also moves functional tests for the ingress bandwidth limit rules
    methods to more appropriate module.

    Related-bug: 1959567
    Change-Id: I848af01c8fe3a08b26d05e37d225c944ea080f03

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (master)

Reviewed: https://review.opendev.org/c/openstack/neutron/+/832662
Committed: https://opendev.org/openstack/neutron/commit/f7ab90baad83823cfb94bc8b9450cd915ea49c03
Submitter: "Zuul (22348)"
Branch: master

commit f7ab90baad83823cfb94bc8b9450cd915ea49c03
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://man7.org/linux/man-pages/man7/ovs-fields.7.html

    Closes-Bug: #1959567
    Change-Id: I1e31565475f38c6ad817268699b165759ac05410

Changed in neutron:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to neutron (stable/yoga)

Related fix proposed to branch: stable/yoga
Review: https://review.opendev.org/c/openstack/neutron/+/835863

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (stable/yoga)

Fix proposed to branch: stable/yoga
Review: https://review.opendev.org/c/openstack/neutron/+/835864

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to neutron (stable/xena)

Related fix proposed to branch: stable/xena
Review: https://review.opendev.org/c/openstack/neutron/+/835865

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (stable/xena)

Fix proposed to branch: stable/xena
Review: https://review.opendev.org/c/openstack/neutron/+/835866

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to neutron (stable/wallaby)

Related fix proposed to branch: stable/wallaby
Review: https://review.opendev.org/c/openstack/neutron/+/835943

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (stable/wallaby)

Fix proposed to branch: stable/wallaby
Review: https://review.opendev.org/c/openstack/neutron/+/835944

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to neutron (stable/victoria)

Related fix proposed to branch: stable/victoria
Review: https://review.opendev.org/c/openstack/neutron/+/835867

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (stable/victoria)

Fix proposed to branch: stable/victoria
Review: https://review.opendev.org/c/openstack/neutron/+/835868

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to neutron (stable/ussuri)

Related fix proposed to branch: stable/ussuri
Review: https://review.opendev.org/c/openstack/neutron/+/835946

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (stable/ussuri)

Fix proposed to branch: stable/ussuri
Review: https://review.opendev.org/c/openstack/neutron/+/835947

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to neutron (stable/train)

Related fix proposed to branch: stable/train
Review: https://review.opendev.org/c/openstack/neutron/+/835948

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (stable/train)

Fix proposed to branch: stable/train
Review: https://review.opendev.org/c/openstack/neutron/+/835949

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix merged to neutron (stable/xena)

Reviewed: https://review.opendev.org/c/openstack/neutron/+/835865
Committed: https://opendev.org/openstack/neutron/commit/18e05b5b2aad44cc53ea8b3d1f9c2c1c4bc08571
Submitter: "Zuul (22348)"
Branch: stable/xena

commit 18e05b5b2aad44cc53ea8b3d1f9c2c1c4bc08571
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/delete_{qos,queue} and
    find/update/delete_{qos,queue}.

    It also moves functional tests for the ingress bandwidth limit rules
    methods to more appropriate module.

    Related-bug: 1959567
    Change-Id: I848af01c8fe3a08b26d05e37d225c944ea080f03
    (cherry picked from commit 0255f41ad0405eac8b2a4e0870513846e2660f7f)

tags: added: in-stable-xena
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix merged to neutron (stable/wallaby)

Reviewed: https://review.opendev.org/c/openstack/neutron/+/835943
Committed: https://opendev.org/openstack/neutron/commit/df5af1347789ff3fe14b8dd07c24e8acd6c0b2ae
Submitter: "Zuul (22348)"
Branch: stable/wallaby

commit df5af1347789ff3fe14b8dd07c24e8acd6c0b2ae
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/delete_{qos,queue} and
    find/update/delete_{qos,queue}.

    It also moves functional tests for the ingress bandwidth limit rules
    methods to more appropriate module.

    Conflicts:
        neutron/tests/functional/agent/common/test_ovs_lib.py

    Related-bug: 1959567
    Change-Id: I848af01c8fe3a08b26d05e37d225c944ea080f03
    (cherry picked from commit 0255f41ad0405eac8b2a4e0870513846e2660f7f)
    (cherry picked from commit 18e05b5b2aad44cc53ea8b3d1f9c2c1c4bc08571)

tags: added: in-stable-wallaby
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix merged to neutron (stable/ussuri)

Reviewed: https://review.opendev.org/c/openstack/neutron/+/835946
Committed: https://opendev.org/openstack/neutron/commit/44a22bb15c7e62e443ae440c0e85c8ef0c620b96
Submitter: "Zuul (22348)"
Branch: stable/ussuri

commit 44a22bb15c7e62e443ae440c0e85c8ef0c620b96
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/delete_{qos,queue} and
    find/update/delete_{qos,queue}.

    It also moves functional tests for the ingress bandwidth limit rules
    methods to more appropriate module.

    Conflicts:
        neutron/agent/common/ovs_lib.py
        neutron/tests/functional/agent/common/test_ovs_lib.py

    Related-bug: 1959567
    Change-Id: I848af01c8fe3a08b26d05e37d225c944ea080f03
    (cherry picked from commit 0255f41ad0405eac8b2a4e0870513846e2660f7f)
    (cherry picked from commit 18e05b5b2aad44cc53ea8b3d1f9c2c1c4bc08571)
    (cherry picked from commit 9e3aa7e3d66f8def5055a8088f4baa5bcbd70328)

tags: added: in-stable-ussuri
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (stable/xena)

Reviewed: https://review.opendev.org/c/openstack/neutron/+/835866
Committed: https://opendev.org/openstack/neutron/commit/5573230d30a7beb242ab54eb85b8e36f33f79403
Submitter: "Zuul (22348)"
Branch: stable/xena

commit 5573230d30a7beb242ab54eb85b8e36f33f79403
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://man7.org/linux/man-pages/man7/ovs-fields.7.html

    Closes-Bug: #1959567
    Change-Id: I1e31565475f38c6ad817268699b165759ac05410
    (cherry picked from commit f7ab90baad83823cfb94bc8b9450cd915ea49c03)

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (stable/wallaby)

Reviewed: https://review.opendev.org/c/openstack/neutron/+/835944
Committed: https://opendev.org/openstack/neutron/commit/6af566a89a1bc03889ff666c73fa7a7dcf131061
Submitter: "Zuul (22348)"
Branch: stable/wallaby

commit 6af566a89a1bc03889ff666c73fa7a7dcf131061
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://man7.org/linux/man-pages/man7/ovs-fields.7.html

    Closes-Bug: #1959567
    Change-Id: I1e31565475f38c6ad817268699b165759ac05410
    (cherry picked from commit f7ab90baad83823cfb94bc8b9450cd915ea49c03)
    (cherry picked from commit 5573230d30a7beb242ab54eb85b8e36f33f79403)

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (stable/ussuri)

Reviewed: https://review.opendev.org/c/openstack/neutron/+/835947
Committed: https://opendev.org/openstack/neutron/commit/e59a7d5c3d4b29b73973ba8ceb8faf6751ef4d37
Submitter: "Zuul (22348)"
Branch: stable/ussuri

commit e59a7d5c3d4b29b73973ba8ceb8faf6751ef4d37
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://man7.org/linux/man-pages/man7/ovs-fields.7.html

    Closes-Bug: #1959567
    Change-Id: I1e31565475f38c6ad817268699b165759ac05410
    (cherry picked from commit f7ab90baad83823cfb94bc8b9450cd915ea49c03)
    (cherry picked from commit 5573230d30a7beb242ab54eb85b8e36f33f79403)
    (cherry picked from commit 4a0ca56fe57dbab08face37a22b9c3273141667d)

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix merged to neutron (stable/victoria)

Reviewed: https://review.opendev.org/c/openstack/neutron/+/835867
Committed: https://opendev.org/openstack/neutron/commit/9e3aa7e3d66f8def5055a8088f4baa5bcbd70328
Submitter: "Zuul (22348)"
Branch: stable/victoria

commit 9e3aa7e3d66f8def5055a8088f4baa5bcbd70328
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/delete_{qos,queue} and
    find/update/delete_{qos,queue}.

    It also moves functional tests for the ingress bandwidth limit rules
    methods to more appropriate module.

    Conflicts:
        neutron/tests/functional/agent/common/test_ovs_lib.py

    Related-bug: 1959567
    Change-Id: I848af01c8fe3a08b26d05e37d225c944ea080f03
    (cherry picked from commit 0255f41ad0405eac8b2a4e0870513846e2660f7f)
    (cherry picked from commit 18e05b5b2aad44cc53ea8b3d1f9c2c1c4bc08571)

tags: added: in-stable-victoria
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix merged to neutron (stable/yoga)

Reviewed: https://review.opendev.org/c/openstack/neutron/+/835863
Committed: https://opendev.org/openstack/neutron/commit/015e82b338b0f09ee26dcb13954b03ca584f43b2
Submitter: "Zuul (22348)"
Branch: stable/yoga

commit 015e82b338b0f09ee26dcb13954b03ca584f43b2
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/delete_{qos,queue} and
    find/update/delete_{qos,queue}.

    It also moves functional tests for the ingress bandwidth limit rules
    methods to more appropriate module.

    Related-bug: 1959567
    Change-Id: I848af01c8fe3a08b26d05e37d225c944ea080f03
    (cherry picked from commit 0255f41ad0405eac8b2a4e0870513846e2660f7f)

tags: added: in-stable-yoga
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (stable/yoga)

Reviewed: https://review.opendev.org/c/openstack/neutron/+/835864
Committed: https://opendev.org/openstack/neutron/commit/8c8066067b57641e64ac18424213e6897779c1d8
Submitter: "Zuul (22348)"
Branch: stable/yoga

commit 8c8066067b57641e64ac18424213e6897779c1d8
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://man7.org/linux/man-pages/man7/ovs-fields.7.html

    Closes-Bug: #1959567
    Change-Id: I1e31565475f38c6ad817268699b165759ac05410
    (cherry picked from commit f7ab90baad83823cfb94bc8b9450cd915ea49c03)

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (stable/victoria)

Reviewed: https://review.opendev.org/c/openstack/neutron/+/835868
Committed: https://opendev.org/openstack/neutron/commit/4a0ca56fe57dbab08face37a22b9c3273141667d
Submitter: "Zuul (22348)"
Branch: stable/victoria

commit 4a0ca56fe57dbab08face37a22b9c3273141667d
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://man7.org/linux/man-pages/man7/ovs-fields.7.html

    Closes-Bug: #1959567
    Change-Id: I1e31565475f38c6ad817268699b165759ac05410
    (cherry picked from commit f7ab90baad83823cfb94bc8b9450cd915ea49c03)
    (cherry picked from commit 5573230d30a7beb242ab54eb85b8e36f33f79403)

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix merged to neutron (stable/train)

Reviewed: https://review.opendev.org/c/openstack/neutron/+/835948
Committed: https://opendev.org/openstack/neutron/commit/ec08253f81367fe4602e5cf4b64fafd4dde55b24
Submitter: "Zuul (22348)"
Branch: stable/train

commit ec08253f81367fe4602e5cf4b64fafd4dde55b24
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/delete_{qos,queue} and
    find/update/delete_{qos,queue}.

    It also moves functional tests for the ingress bandwidth limit rules
    methods to more appropriate module.

    Conflicts:
        neutron/agent/common/ovs_lib.py
        neutron/tests/functional/agent/common/test_ovs_lib.py
        neutron/tests/unit/plugins/ml2/drivers/openvswitch/agent/extension_drivers/test_qos_driver.py

    Related-bug: 1959567
    Change-Id: I848af01c8fe3a08b26d05e37d225c944ea080f03
    (cherry picked from commit 0255f41ad0405eac8b2a4e0870513846e2660f7f)
    (cherry picked from commit 18e05b5b2aad44cc53ea8b3d1f9c2c1c4bc08571)
    (cherry picked from commit 9e3aa7e3d66f8def5055a8088f4baa5bcbd70328)
    (cherry picked from commit 44a22bb15c7e62e443ae440c0e85c8ef0c620b96)

tags: added: in-stable-train
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (stable/train)

Reviewed: https://review.opendev.org/c/openstack/neutron/+/835949
Committed: https://opendev.org/openstack/neutron/commit/196ab6bea12f9486efc110a8b37ccc8b495ef12d
Submitter: "Zuul (22348)"
Branch: stable/train

commit 196ab6bea12f9486efc110a8b37ccc8b495ef12d
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://man7.org/linux/man-pages/man7/ovs-fields.7.html

    Conflicts:
        neutron/plugins/ml2/drivers/openvswitch/agent/extension_drivers/qos_driver.py

    Closes-Bug: #1959567
    Change-Id: I1e31565475f38c6ad817268699b165759ac05410
    (cherry picked from commit f7ab90baad83823cfb94bc8b9450cd915ea49c03)
    (cherry picked from commit 5573230d30a7beb242ab54eb85b8e36f33f79403)
    (cherry picked from commit 4a0ca56fe57dbab08face37a22b9c3273141667d)
    (cherry picked from commit e59a7d5c3d4b29b73973ba8ceb8faf6751ef4d37)

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/neutron 17.4.0

This issue was fixed in the openstack/neutron 17.4.0 release.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/neutron 18.3.0

This issue was fixed in the openstack/neutron 18.3.0 release.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/neutron 19.2.0

This issue was fixed in the openstack/neutron 19.2.0 release.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to neutron-lib (master)

Related fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/neutron-lib/+/839564

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/neutron 20.1.0

This issue was fixed in the openstack/neutron 20.1.0 release.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix merged to neutron-lib (master)

Reviewed: https://review.opendev.org/c/openstack/neutron-lib/+/839564
Committed: https://opendev.org/openstack/neutron-lib/commit/231067cabadb91eb40e44202b4f55785d5c7afe1
Submitter: "Zuul (22348)"
Branch: master

commit 231067cabadb91eb40e44202b4f55785d5c7afe1
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://review.opendev.org/c/openstack/neutron/+/832662

    Related-Bug: #1959567
    Change-Id: I89cc83699770e97bba369f50dd4d9e0ed6563aa4

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/neutron 21.0.0.0rc1

This issue was fixed in the openstack/neutron 21.0.0.0rc1 release candidate.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/neutron train-eol

This issue was fixed in the openstack/neutron train-eol release.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/neutron ussuri-eol

This issue was fixed in the openstack/neutron ussuri-eol release.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.