Open Stack

I think that the implementation is complex for me and maybe reviewer.
Could you propose devref like vlan-aware-vms[1]?

[1]: https://review.openstack.org/#/c/318317/

Thanks,
Hirofumi

On 2016/06/24 18:10, Alonso Hernandez, Rodolfo wrote:
>
> 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):
>
> oCreate 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.
>
> oCreate a qos policy for the external port in br-tun, and then assign 
> the queue
>
> oCreate 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.hirofumi at lab.ntt.co.jp]
> *Sent:* Tuesday, June 21, 2016 10:27 AM
> *To:* OpenStack Development Mailing List (not for usage questions) 
> <openstack-dev at 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-request at lists.openstack.org?subject:unsubscribe
>     <mailto:OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160628/c8d146d7/attachment.html>