Hi Ben,
Do you have more questions on this topic?
Thank you,
Babu
On Thursday 14 January 2016 06:46 PM, Miguel Angel Ajo wrote:
Hi!,
Russell Bryant wrote:
On 01/13/2016 11:30 AM, Russell Bryant wrote:
On 01/11/2016 08:19 PM, Ben Pfaff wrote:
On Tue, Jan 05, 2016 at 07:33:16PM +0530, bscha...@redhat.com wrote:
This patch series enables QOS support in OVN. Only two parameters
(policing_rate and policing_burst) are enabled through this patch
series.
Babu Shanmugam (3):
ovn: ovn-controller changes for qos settings
ovn: Qos options for VMI updated in ovn-sb.xml
ovn: Qos options for VMI updated in ovn-nb.xml
We found previously that ingress policing works particularly
badly. It
isn't accurate and some kind of traffic get handled in a really bad
way. Have you have a different experience?
I suggested the QoS work item. The background is just that I'm looking
to get parity with what OpenStack Neutron exposes for the current
integration. Hopefully the limitations are adequately reflected in
docs. Would you be OK including this support with appropriate caveats
in the docs?
I also asked the dev of the existing Neutron integration to weigh in
about their implementation and experience.
We're using ingress policing in neutron as a simple way to provide
VM/container - egress bandwidth policing.
It works well with TCP, but of course, UDP and other types of traffic
may need some sort of queuing, we didn't uses queues, because
neutron reference implementation makes a heavy use of NORMAL rules
and port tagging to direct traffic to the right place, that makes it
impossible
to use queues.
Also, I found that to use queues (for VM-egress traffic) we need to
have one
queue per traffic flow/port in the outgoing port, and as I understood
it, we can
only create queues for linux kernel visible ports (that excludes
patch ports,
tunnel ports and OVS internal port bonds, but includes veth based
patch ports,
and physical interfaces). Please correct me if I'm wrong here,
probably there
is some sort of alternative here equivalent to IMQ's, I'm sadly not an
expert in
this area.
So, even if it was a little bit limited seemed like reasonable initial
step to
provide VM-egress bandwidth limits. (we left the limitations documented:
Application or protocol needs to expect packet drops).
VM-ingress/switch-egress are very easily implemented with queues.
Best regards,
Miguel Ángel.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
