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

[Babu Shanmugam]

Thank you for your answers Ben.
I tried configuring a htb qdisc on a physical interface which is not 
attached to any bridge and found the egress shaping working on a tap 
device attached to br-int.

Babu

On Tuesday 17 May 2016 01:37 AM, Ben Pfaff wrote:
> 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.