Hi , Below I am asking for HTB.
Regards, Selen On Wed, Jul 4, 2012 at 4:24 PM, selen jia <selen...@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 <selen...@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 <jpet...@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 <jpet...@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 <jpet...@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 <jpet...@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 >>> > > > >>> > > > >>> > > > >>> > > >>> > > >>> > >>> > >>> >>> >> >
_______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
