Bug 1744924

This may related with the patch: https://www.redhat.com/archives/libvir-list/2019-February/msg01585.html

(In reply to yalzhang from comment #1)
> This may related with the patch:
> https://www.redhat.com/archives/libvir-list/2019-February/msg01585.html

Yes, with this patch merged, the QoS is intentionally supported with forward mode=bridge when a bridge device is listed.

Unfortunately what merged was the wrong patch so it didn't actually work and needs a further fix

https://www.redhat.com/archives/libvir-list/2019-September/msg00565.html

Merged upstream in

commit 0a85aad582322034b758f8aa0199641b42be173e
Author: Daniel P. Berrangé <berrange>
Date:   Fri Sep 13 17:00:40 2019 +0100

    network: apply bandwidth settings for forward mode=bridge
    
    We previously allowed bandwidth settings when attaching NICs
    to networks with forward mode=bridge:
    
      commit 42a92ee93d5432ebd9ebfd409903b5287fc7d7ff
      Author: Daniel P. Berrangé <berrange>
      Date:   Tue Nov 20 11:30:05 2018 +0000
    
        network: add missing bandwidth limits for bridge forward type
    
        In the case of a network with forward=bridge, which has a bridge device
        listed, we are capable of setting bandwidth limits but fail to call the
        function to register them.
    
        Reviewed-by: Cole Robinson <crobinso>
        Signed-off-by: Daniel P. Berrangé <berrange>
    
    Unfortunately the wrong version of this patch was posted and
    reviewed and thus it lacked the code to actually apply the
    bandwidth settings to the bridge itself.
    
    Reviewed-by: Laine Stump <laine>
    Signed-off-by: Daniel P. Berrangé <berrange>

From the patch description below, does it mean Qos setting can be supported for mode=bridge?

In the case of a network with forward=bridge, which has a bridge device
        listed, we are capable of setting bandwidth limits but fail to call the
        function to register them.

Tried with libvirt-6.0.0-1.virtcov.el8.x86_64 &
qemu-kvm-4.2.0-6.module+el8.2.0+5453+31b2b136.x86_64

#virsh net-dumpxml bridge
<network>
  <name>bridge</name>
  <uuid>54e380e0-1914-454b-a335-1025caf2500a</uuid>
  <forward mode='bridge'/>
  <bridge name='br0'/>
  <bandwidth>
    <inbound average='1000' peak='5000' burst='5120'/>
    <outbound average='128' peak='256' burst='256'/>
  </bandwidth>
</network>

# virsh net-start bridge
Network bridge started

# tc class show dev br0
class htb 1:1 root rate 8Mbit ceil 40Mbit burst 1600b cburst 1600b 
class htb 1:2 parent 1:1 leaf 2: prio 0 rate 8Mbit ceil 40Mbit burst 5Mb cburst 1600b 

# tc  qdisc show dev br0
qdisc htb 1: root refcnt 2 r2q 10 default 0x2 direct_packets_stat 0 direct_qlen 1000
qdisc sfq 2: parent 1:2 limit 127p quantum 1514b depth 127 divisor 1024 perturb 10sec 
qdisc ingress ffff: parent ffff:fff1 ---------------- 

Does it mean it's registered from the output of "tc" command ?

Yes, I believe that is correct, as this matches what is created when using a network with mode="forward" previously

One more question - 
If mode='bridge' network is supported to config bandwidth, is the libvirt.org going to be changed about the below description - 

Setting bandwidth for a network is supported only for networks with a <forward> mode of route, nat, or no mode at all (i.e. an "isolated" network). Setting bandwidth is not supported for forward modes of bridge, passthrough, private, or hostdev. Attempts to do this will lead to a failure to define the network or to create a transient network.

Patch to fix the website docs is here: https://www.redhat.com/archives/libvir-list/2020-February/msg01015.html

Hi Daniel, 

For network with ovs bridge as below, the Qos setting in network do not take any effects(I have tested with netperf). It seems that OVS has its own QoS mechanism. It was discussed once: https://bugzilla.redhat.com/show_bug.cgi?id=1510237#c5

<network>
  <name>ovs-net</name>
  <forward mode='bridge'/>
  <bridge name='ovsbr1'/>
  <virtualport type='openvswitch'/>
  <bandwidth>
    <inbound average='1000' peak='5000' burst='5120'/>
    <outbound average='128' peak='256' burst='256'/>
  </bandwidth>
</network>

So I think we may need to forbid to start such type of network with ovs bridge and update the document accordingly, Please help to confirm, Thank you very much!

Yes indeed, I think we need to restrict this for OVS bridges. Can you file a Bug for that so we can track it separately from this one that is already marked VERIFIED.

Hi Daniel, Thank you! 
file Bug 1826168 - bridge type network with ovs bridge can start with Qos setting which do not take any effect

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:2017