[ovs-discuss] Is it possible to limit bandwidth for particular OVS port?

Gurucharan Shetty shettyg at nicira.com
Thu Mar 26 15:44:07 UTC 2015


On Wed, Mar 25, 2015 at 7:03 PM, Tim Bagr <timbgr at gmail.com> wrote:
> Hello Gurucharan,
>
> Thanks for the reply.
>
> I have no physical ports attached to that OVS bridge. My intention was
> exactly to limit bandwidth for br3 port (i.e. openflow keyword LOCAL), and
> another try was to limit bandwidth for internal patch-port, which connects
> br3 bridge with br2 bridge. In both bridges there are VMs attached and they
> may communicate with each other through the patch-port.
>
> # ovs-vsctl show
> b11e83cb-d741-4a59-90f7-ea9693d508cf
>     Bridge "br2"
>         Port "b3p"
>             Interface "b3p"
>                 type: patch
>                 options: {peer="b2p"}
>         Port "vnet1"
>             Interface "vnet1"
>         Port "br2"
>             Interface "br2"
>                 type: internal
>     Bridge "br3"
>         Port "br3"
>             Interface "br3"
>                 type: internal
>         Port "vnet0"
>             Interface "vnet0"
>         Port "b2p"
>             Interface "b2p"
>                 type: patch
>                 options: {peer="b3p"}
>
> Here vnet1 is port of 1st VM and vnet0 is port of 2nd VM. Now I just want to
> limit bandwidth from VM2 to VM1.
> So I run:
> # ovs-vsctl set Port b2p qos=@newq -- --id=@newq create qos type=linux-htb
> other-config:max-rate=100000000 queues=111=@q1 -- --id=@q1 create queue
> other-config:min-rate=0 other-config:max-rate=10
> 65c5488d-2066-4d97-b21f-ba369a8b2920
> 1e3726b4-12e2-4184-b8e4-13f9c692095f
I _think_(not 100% sure) that you cannot apply QoS on a patch port.
Patch port has no netdevice backing it. OVS uses Linux tc to apply
QoS. Since tc cannot see the OVS patch port, I don't think anything
will come out of it.

The way to verify that QoS is really working is to look at tc stats
for that queue. e.g: If you had applied QoS on eth1 with 3 queues: 1,
2, 3, you will get:

sudo tc class show dev eth1
class htb 1:fffe root rate 900000Kbit ceil 900000Kbit burst 1462b cburst 1462b
class htb 1:1 parent 1:fffe prio 0 rate 720000Kbit ceil 900000Kbit
burst 1530b cburst 1462b
class htb 1:2 parent 1:fffe prio 0 rate 12000bit ceil 90000Kbit burst
1563b cburst 1563b
class htb 1:3 parent 1:fffe prio 0 rate 12000bit ceil 90000Kbit burst
1563b cburst 1563b

For statistics: (to see how many packets went through etc)
tc -s class show dev eth1



>
> # ovs-ofctl show br3
> OFPT_FEATURES_REPLY (xid=0x2): dpid:00007a42d1ca7e05
> n_tables:254, n_buffers:256
> capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
> actions: OUTPUT SET_VLAN_VID SET_VLAN_PCP STRIP_VLAN SET_DL_SRC SET_DL_DST
> SET_NW_SRC SET_NW_DST SET_NW_TOS SET_TP_SRC SET_TP_DST ENQUEUE
>  3(b2p): addr:ae:a4:9d:8b:9f:a9
>      config:     0
>      state:      0
>      speed: 0 Mbps now, 0 Mbps max
>  6(vnet0): addr:fe:54:00:ac:e1:a6
>      config:     0
>      state:      0
>      current:    10MB-FD COPPER
>      speed: 10 Mbps now, 0 Mbps max
>  LOCAL(br3): addr:7a:42:d1:ca:7e:05
>      config:     0
>      state:      0
>      speed: 0 Mbps now, 0 Mbps max
> OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0
>
> # ovs-ofctl add-flow br3 priority=5,in_port=6,actions=enqueue:3:111
> # ovs-ofctl dump-flows br3
> NXST_FLOW reply (xid=0x4):
>  cookie=0x0, duration=3.285s, table=0, n_packets=0, n_bytes=0, idle_age=3,
> priority=5,in_port=6 actions=enqueue:3:111
>  cookie=0x0, duration=79191.532s, table=0, n_packets=744, n_bytes=431875,
> idle_age=7, hard_age=65534, priority=0 actions=NORMAL
>
> Then I start to ping6 from VM2 to VM1 and pings will go through that
> patch-ports b3p and b2p. As I expected, the QoS queue will be in effect. And
> limit the bandwidth to very small amount of max-rate=10
How do you know that QOS is in effect above? I guess based on the
n_packets of openflow flow? That only tells that OVS marked the packet
to go to a QoS queue. But if QoS queue has not been created in Linux
kernel, there is really nothing that will happen.

I imagine that OVS should show some error in the logs, but I did not
see any (during my small test). That is the reason I am not 100% sure
what will actually  happen.



More information about the discuss mailing list