[ovs-discuss] queueing discipline

[selen jia]

Below I am asking for HTB

On Wed, Jul 4, 2012 at 4:24 PM, selen jia <selen764 at gmail.com> wrote:

> Hi Justin,
>
> Please correct me if I am wrong,I am trying to map "vsctl" parameters with
> "tc" parameters :-
>
> *Mode* of class is artifical value which can be computed from *R (actual
> rate)*,*AR(assured rate)*,*CR(ceil rate)*. Possible modes are
>
>    - *Red*: *R* > *CR*
>    - *Yellow*: *R* <= *CR* and *R* > *AR*
>    - *Green* otherwise
>
>
>
> through OVS above we can achieve from following:-
>
>    - *Red*: *R* > *max-rate*
>    - *Yellow*: *R* <= *max-rate* and *R* > *min-rate*
>    - *Green* otherwise
>
> here yellow means , if bandwidth available then it would be use by yellow
> packets when there is no green packet for that queue?
>
> if all above is right then where parameter "burst" is involving?
>
> Regards,
> Selen
>
>
> On Wed, Jul 4, 2012 at 1:10 PM, selen jia <selen764 at gmail.com> wrote:
>
>> Thanks Justin!
>>
>> just one more query -
>> in configuartion cookbook of OVS, you are taking measuring host as
>> separate machine ,can't I take my bridge (OVS) as measuring
>> machine, because traffic of VM coming on bridge only and we can verify
>> throttle on bridge itself through netperf
>>
>> Regards
>> Selen
>>
>>  On Wed, Jul 4, 2012 at 12:53 PM, Justin Pettit <jpettit at nicira.com>wrote:
>>
>>> If you configure it through ovs-vsctl, an appropriate configuration
>>> should be pushed down to the kernel.  We don't expose as many knobs as the
>>> tc command, so the configuration is much simpler.  You should be able to
>>> verify the configuration pushed down by using the tc command to dump
>>> classes, qdisc, etc.
>>>
>>> --Justin
>>>
>>>
>>> On Jul 4, 2012, at 12:11 AM, selen jia wrote:
>>>
>>> > Hi Justin,
>>> >
>>> > Sorry to bother you.
>>> > I am confused because tc manual is having many paarmeters to
>>> configure, class , handle id etc.. but in OVS we have just rate or burst.
>>> > so how we will configure parent -child through OVS vsctl?
>>> >
>>> > regards,
>>> > Selen
>>> >
>>> >
>>> >
>>> > On Wed, Jul 4, 2012 at 12:32 PM, Justin Pettit <jpettit at nicira.com>
>>> wrote:
>>> > That's what you're configuring, so OVS is taking care of the tc
>>> configuration.
>>> >
>>> > --Justin
>>> >
>>> >
>>> > On Jul 3, 2012, at 11:54 PM, selen jia wrote:
>>> >
>>> > > Hi,
>>> > >
>>> > > To verify HTB and HFSC on OVS ,if I am creating queue and setting
>>> rate through vsctl command then do I need to do some configuration from
>>> "tc" also?
>>> > >
>>> > > Regards,
>>> > > Selen
>>> > > On Tue, Jul 3, 2012 at 12:10 PM, Justin Pettit <jpettit at nicira.com>
>>> wrote:
>>> > > The former.  If you want to control the rate going into the switch
>>> from the VM, you'd need to use a policer.
>>> > >
>>> > > --Justin
>>> > >
>>> > >
>>> > > On Jul 2, 2012, at 11:35 PM, selen jia wrote:
>>> > >
>>> > > > Hi Justin,
>>> > > >
>>> > > > Is that mean to verify HTB and HFSC on VM interfaces , I have to
>>> create queues on VM interface with particular bandwidth/rate and have to
>>> send traffic from switch to VM and then check rate .
>>> > > > this is ingress to VM, right?
>>> > > >
>>> > > > OR
>>> > > > after creating queue on VM , I will send traffic from VM and will
>>> verify the rate of traffic coming out of VM interface on switch?
>>> > > >
>>> > > > Regards,
>>> > > > Selen
>>> > > >
>>> > > > On Tue, Jul 3, 2012 at 11:43 AM, Justin Pettit <jpettit at nicira.com>
>>> wrote:
>>> > > > On Jul 2, 2012, at 10:30 PM, selen jia wrote:
>>> > > >
>>> > > > > It means HTB, HFSC and policing all would work on VM interfaces ?
>>> > > >
>>> > > > Yes, they should.  We just leverage the tc's mechanisms in the
>>> kernel.
>>> > > >
>>> > > > > Is this implementation opposite to policing because policing act
>>> as ingress for switch perspective and egress for VM interface?
>>> > > >
>>> > > > That sounds correct.  Policing is applied on traffic coming into
>>> OVS, and shaping (queueing) is applied on traffic going out of OVS.  So,
>>> you just have to think about it from the switch's perspective.
>>> > > >
>>> > > > --Justin
>>> > > >
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20120704/fd8a0dbc/attachment.html>