[ovs-dev] [PATCH 0/2] ovn: QOS updates with DSCP support

Ben Pfaff blp at ovn.org
Mon May 16 20:07:51 UTC 2016


Hi Bryan, I think that you understand how QoS works in NVP.  We're
currently talking about how to implement QoS in OVN.  Can you help us
understand the issues?

...now back to the conversation already in progress:

On Tue, May 10, 2016 at 05:04:06PM +0530, Babu Shanmugam wrote:
> On Friday 06 May 2016 10:33 PM, Ben Pfaff wrote:
> >But I'm still having trouble understanding the whole design here.
> >Without this patch, OVN applies ingress policing to packets received
> >from (typically) a VM.  This limits the rate at which the VM can
> >introduce packets into the network, and thus acts as a direct (if
> >primitive) way to limit the VM's bandwidth resource usage on the
> >machine's physical interface.
> >
> >With this patch, OVN applies shaping to packets *sent* to (typically) a
> >VM.  This limits the rate at which the VM can consume packets*from*  the
> >network.  This has no direct effect on the VM's consumption of bandwidth
> >resources on the network, because the packets that are discarded have
> >already consumed RX resources on the machine's physical interface and
> >there is in fact no direct way to prevent remote machines from sending
> >packets for the local machine to receive.  It might have an indirect
> >effect on the VM's bandwidth consumption, since remote senders using
> >(e.g.) TCP will notice that their packets were dropped and reduce their
> >sending rate, but it's far less efficient at it than shaping packets
> >going out to the network.
> >
> >The design I expected to see in OVN, eventually, was this:
> >
> >         - Each VM/VIF gets assigned a queue.  Packets received from the
> >           VM are tagged with the queue using an OpenFlow "set_queue"
> >           action (dunno if we have this as an OVN logical action yet but
> >           it's easily added).
> >
> >         - OVN programs the machine's physical interface with a linux-htb
> >           or linux-hfsc qdisc that grants some min-rate to each
> >           queue.
>
> From what I understand, to setup egress shaping for a VIF interface
> - We need a physical interface attached to br-int

It doesn't have to be attached to br-int, because queuing information is
preserved over a hop from bridge to bridge and through encapsulation in
tunnels, but OVN would have to configure queues on the interface
regardless of what bridge it was in.

> - QOS and Queue tables has to be setup for the port entry that corresponds
> to the physical interface
> - Packets received from VIF are put in these queues using set_queue.
> Is my understanding correct?

Yes, I believe so.

> Is there any way that HTB/HFSC queues can work without a physical interface
> attached to br-int? if not are we going to mandate in some way that a
> physical interface has to be attached to br-int?

I don't think it's desirable or necessary to attach the physical
interface to br-int, only to ensure that the queues are configured on
it.

Bryan, what does NVP do?  In particular, does it configure queues on a
physical interface without caring what bridge it is attached to?

Thanks,

Ben.



More information about the dev mailing list