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:[email protected]]
*Sent:* Tuesday, June 21, 2016 10:27 AM
*To:* OpenStack Development Mailing List (not for usage questions)
<[email protected]>
*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:[email protected]?subject:unsubscribe
<mailto:[email protected]?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
