[ovs-discuss] QoS Bandwidth Rate Limiting in Multi-compute nodes OpenStack

[Ahmed Medhat]

Thanks Ben,

I already read that.

The problem I have is not in the measurement, it is in establishing the
session of Iperf itself (no reply from the server side), Knowing that I do
the same configuration for 2 VMs in one compute node and it works as
expected.

Best regards,
Ahmed

On Wed, Aug 10, 2016 at 6:38 PM, Ben Pfaff <blp at ovn.org> wrote:

> On Wed, Aug 10, 2016 at 12:35:51PM +0200, Ahmed Medhat wrote:
> > Hi Folks,
> >
> >
> > I have a problem with QoS enforcement in multi-compute nodes Openstack
> > architecture.
> > I test using Iperf udp traffic and tcp traffic. It limits the bandwidth
> > rate successfully if the client and server VMs are in the same compute
> > node, otherwise it failed.
> >
> > I did tcpdump and found the traffic is received by the Server but no Ack
> > reply is sent back. However there is an ARP reply is sent from the
> server.
> >
> > To summarize the case:
> >
> > 1- Iperf works fine between 2 vms in different compute nodes WITHOUT QoS
> > enforcement.
> > 2- Iperf and Bandwidth limitation work fine between 2 vms in the same
> > compute node With QoS enforcement.
> > 3-The problem is Iperf not works at all between 2 vms in different
> compute
> > nodes With QoS enforcement.
> >
> > The flows which are used  for 2 vms in different compute nodes are here:
> >
> > *First Compute/Control Node:*
> > ovs-ofctl add-flow br-int priority=2,udp,nw_src=192.168.
> > 254.109,nw_dst=192.168.254.110,actions=enqueue:31:4
> >
> > *2nd Compute Node:*
> >
> > ovs-ofctl add-flow br-int priority=2,udp,nw_src=192.168.
> > 254.110,nw_dst=192.168.254.109,actions=enqueue:33:4
>
> The FAQ says:
>
> ### Q: I configured QoS, correctly, but my measurements show that it isn't
>    working as well as I expect.
>
> A: With the Linux kernel, the Open vSwitch implementation of QoS has
>    two aspects:
>
>    - Open vSwitch configures a subset of Linux kernel QoS
>      features, according to what is in OVSDB.  It is possible that
>      this code has bugs.  If you believe that this is so, then you
>      can configure the Linux traffic control (QoS) stack directly
>      with the "tc" program.  If you get better results that way,
>      you can send a detailed bug report to bugs at openvswitch.org.
>
>      It is certain that Open vSwitch cannot configure every Linux
>      kernel QoS feature.  If you need some feature that OVS cannot
>      configure, then you can also use "tc" directly (or add that
>      feature to OVS).
>
>    - The Open vSwitch implementation of OpenFlow allows flows to
>      be directed to particular queues.  This is pretty simple and
>      unlikely to have serious bugs at this point.
>
>    However, most problems with QoS on Linux are not bugs in Open
>    vSwitch at all.  They tend to be either configuration errors
>    (please see the earlier questions in this section) or issues with
>    the traffic control (QoS) stack in Linux.  The Open vSwitch
>    developers are not experts on Linux traffic control.  We suggest
>    that, if you believe you are encountering a problem with Linux
>    traffic control, that you consult the tc manpages (e.g. tc(8),
>    tc-htb(8), tc-hfsc(8)), web resources (e.g. http://lartc.org/), or
>    mailing lists (e.g. http://vger.kernel.org/vger-lists.html#netdev).
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20160810/d6fbef12/attachment-0002.html>