On Wed, Mar 25, 2015 at 7:03 PM, Tim Bagr <[email protected]> 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. _______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
