Hello: Ichihara, thank you for your answer. It was just a test to find out how to setup correctly the egress traffic shaping. I was facing this situation and I found the problem: I was using bridges with datapath_type = netdev, instead of system. That was the main problem. Now I can correctly apply a QoS and a queue, and assign a traffic to this queue.
To avoid using veth between bridges, I’m implementing the following solution: - Create a new queue for each min-qos rule applied to a port (the same min-qos rule could be applied to several ports, of course). - Because ovs only shapes traffic in the egress direction (ovs point of view): o Create a qos policy for each port in br-int in the same network of the port to apply the qos; then assign the created queue to this qos policy. o Create a qos policy for the external port in br-tun, and then assign the queue o Create a qos policy for the external port for the br-phy in the same network, and assign the queue - In br-int, table 0, enqueue all traffic going into ovs from the port with qos policy assigned to the queue created. With this implementation, you don’t need to use veth and all traffic going from the port with the qos policy assigned to other VM or external port (physical bridge, tunnel) will be shaped. Of course, this implementation is a bit tangled, so please be gentle in the code-review. Regards. From: Hirofumi Ichihara [mailto:ichihara.hirof...@lab.ntt.co.jp] Sent: Tuesday, June 21, 2016 10:27 AM To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [neutron][qos] Egress minimum bandwidth assurance On 2016/06/15 18:54, Alonso Hernandez, Rodolfo wrote: Hello: Context: try to develop a driver for this feature in OVS. During the last week I’ve been testing several scenarios to make a POC of this feature. Scenario 1: 3 VM connected to br-int, sending traffic through br-physical to other host (an external physical machine). The first VM will have a min BW of 15 Mb. The physical port will be limited to 20 Mb, so for VM2 and VM3 should be only 5 Mb of available BW. Those three VM are using iperf to inject traffic against the external host. A) One qos policy and queue is created at VM1 port (with other_config:{min-rate=15000000}). The traffic is not shapped. B) Another qos policy and queue with this minimum BW is created at int-phy-patchport. The traffic is not shapped. C) Another qos policy and queue with this minimum BW is created at phy-int-phy-patchport. The traffic is not shapped. D) Another qos policy and queue with this minimum BW is created at physical port. The traffic is still not shapped. In OVS all traffic from VM1 is filtered to match the correct qos and queues at the ports. It seems that this scenario doesn't expect some scenarios like DVR and multiple NIC. I thought that the queue should be set in br-int with veth(instead of patch port) between br-int and bt-tun. However, I guess that this may occur a issue that traffic cannot turn back in br-int. That may happen in Scenario2 case. Therefore, I think that we should set the queue to physical port but we have a problem how do we specify the NIC in some cases(vlan, vxlan, DVR mode router and DVR FloatingIP). Scenario 2: Similar to scenario 1, but using a fourth VM to act as server. In this case, traffic only goes through br-int. A) One qos policy and queue is created at VM1 port (with other_config:{min-rate=15000000}). The traffic is not shapped. B) Another qos policy and queue with this minimum BW is created at output port (VM4 server port). The traffic is still not shapped. I think we cannot manage this case because we doesn't know MAX bandwidth of traffic in br-int and the bandwidth is usually enough. We should focus our attention on a case that the traffic goes out to other nodes. Thanks, Hirofumi I need some help with this implementation, because I’m running out of time an ideas! Thank you in advance. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
