neutron qos bindlimit by ovs is not accurate

[Zachary Ma]

1. openstack version: pike
2. neutron --version 6.5.0
3. ovs-vsctl (Open vSwitch) 2.7.2
4. iperf3-3.1.3-1.fc24.x86_64.rpm

egress bw-limiter is never accurate

ingress bw-limiter is also not accurte,
but using ovs 2.5, ingress is accurate !

[Slawek Kaplonski (slaweq)]

Can You provide more details?
What is difference between real and expected bandwidth, what burst You have configured and so on.
Please also paste config of interfaces in ovs and config of tc from Your interfaces (qdisc, queue and so on).

[Zachary Ma (mazengxie)]

the bw-limiter detail infomatuion：

| project_id | 927a1a06ab2548c2a9adf0a415b57862 |
| rules | [{u'max_kbps': 3000, u'direction': u'egress', u'qos_policy_id': u'f0349150-a0d4-4cb8-9624-3b83d538de63', u'type': u'bandwidth_limit', u'id': u'5f362524-5eeb-4dd5-b3af-326f9fd0e90e', u'max_burst_kbps': 300}, {u'max_kbps': 3000, u'direction': u'ingress', u'qos_policy_id': u'f0349150-a0d4-4cb8-9624-3b83d538de63', u'type': u'bandwidth_limit', u'id': u'fdd5bf18-7c5d-48cd-9b99-0c2668f1ba47', u'max_burst_kbps': 300}] |
| shared | False |
---------------------------------------------------------+

use iperf3 test ：

[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-60.00 sec 23.7 MBytes 3.31 Mbits/sec 8 sender
[ 4] 0.00-60.00 sec 22.3 MBytes 3.12 Mbits/sec receiver

[Zachary Ma (mazengxie)]

today, I test again, the bw-limiter detail infomatuion：
| rules | [{u'max_kbps': 100000, u'direction': u'egress', u'qos_policy_id': u'0b3bf328-ed42-4184-a1a9-4b622dbae21c', u'type': u'bandwidth_limit', u'id': u'd22d568c-8a74-45a0-8c70-446938099de6', u'max_burst_kbps': 10000}, {u'max_kbps': 50000, u'direction': u'ingress', u'qos_policy_id': u'0b3bf328-ed42-4184-a1a9-4b622dbae21c', u'type': u'bandwidth_limit', u'id': u'a091d176-c7c2-42b4-a13f-4d6a7e9759e3', u'max_burst_kbps': 5000}] |
| shared | False

These two vms are on the same compute node， use iperf3 test ：
[ ID] Interval Transfer Bandwidth Retr

[ 4] 0.00-60.00 sec 67.9 MBytes 9.38 Mbits/sec receiver

When I raise the parameters, the bandwidth is limited bandwidth changes.
I think that the error maybe occur at ovs.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/519573

[Slawek Kaplonski (slaweq)]

Thx for working on fix for that.
But next time when You are working on fixing some bug, please assign yourself to it. This will help other users to not digging into it. Thx in advance

[Miguel Angel Ajo (mangelajo)]

The problem is that old OVS had the burst calculation done incorrectly.

The right burst for 3000 kbps should be 3000kbps burst too (or somewhere around there).

Why are the changes in the review doing anything?

[Zachary Ma (mazengxie)]

both ovs interface ingress_burst and queue's burst should use same number? can solve the ingress and egress direction at the same time?

[Zachary Ma (mazengxie)]

thanks for Ajo,
I test
openstack network qos rule set --max-kbps 60000 --max-burst-kbits 60000 --egress bw-limiter d22d568c-8a74-45a0-8c70-446938099de6
for egress dirction， It is accurate. I think we should mofify config qos to present the correct configuration command.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/519573
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=c43317e380d90a9b1eab4f3c5058b770b43dcf96
Submitter: Zuul
Branch: master

commit c43317e380d90a9b1eab4f3c5058b770b43dcf96
Author: Zachary <[e-mail]>
Date: Tue Nov 14 15:48:54 2017 +0800

    [Qos] ingress bandwidth limit by ovs is not accurate

    According to Open vSwitch FAQ [1], max-rate value which is set for
    all queues in qos is set as link speed in case when it is not specified.
    This can lead to inaccurate ingress bandwidth limits in case when QoS is
    applied e.g. directly on tapXXX port (which is "tun" interface type) and
    configured bandwidth limit is higher than interface's link_speed.
    This patch set max-rate parameter in qos's other_config table to not use
    default value determined by Open vSwitch and to make rate limits more
    accurate.

    The modification is covered by functional tests in
    https://github.com/openstack/neutron/blob/master/neutron/tests/
    functional/agent/test_ovs_lib.py.

    [1] http://docs.openvswitch.org/en/latest/faq/qos/

    Change-Id: Id937216a724fbf776298efd11f74ac71056cfe06
    Closes-Bug: #1730605

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/pike
Review: https://review.openstack.org/527942

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/527942
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=adc344c065c4c6bb2e29e9a6c9a6618163ddfbe7
Submitter: Zuul
Branch: stable/pike

commit adc344c065c4c6bb2e29e9a6c9a6618163ddfbe7
Author: Zachary <[e-mail]>
Date: Tue Nov 14 15:48:54 2017 +0800

    [Qos] ingress bandwidth limit by ovs is not accurate

    According to Open vSwitch FAQ [1], max-rate value which is set for
    all queues in qos is set as link speed in case when it is not specified.
    This can lead to inaccurate ingress bandwidth limits in case when QoS is
    applied e.g. directly on tapXXX port (which is "tun" interface type) and
    configured bandwidth limit is higher than interface's link_speed.
    This patch set max-rate parameter in qos's other_config table to not use
    default value determined by Open vSwitch and to make rate limits more
    accurate.

    The modification is covered by functional tests in
    https://github.com/openstack/neutron/blob/master/neutron/tests/
    functional/agent/test_ovs_lib.py.

    [1] http://docs.openvswitch.org/en/latest/faq/qos/

    Change-Id: Id937216a724fbf776298efd11f74ac71056cfe06
    Closes-Bug: #1730605
    (cherry picked from commit c43317e380d90a9b1eab4f3c5058b770b43dcf96)

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron 12.0.0.0b3 development milestone.

[OpenStack Infra (hudson-openstack)]

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