VQs in Gred!

VQs in Gred!

[Zhenyu Wu]

Hello,

We know, VQs are used in Gred to offer different schedulers, in order to make
clear what the 
VQs are, I have read the sch_gred.c in net/sched/. In the function gred_enqueue(),
at first it will 
find the VQ(q) according to the lower four bits of the skb->tc_index, then some
parameters of the
q is modified, such as q->packetsin and q->bytesin. At last the packet was put
into the  physical
Queue using __skb_queue_tail(). When dequeue the packet, only the function
__skb_dequeue()
is called, and the VQ parameters are modified. Then the packets from all VQS will
enter and 
store in the physical queue (sch->q), and be dequeued from there. HOW does the
Gred schedule
packets of differnet priorities?

Thanks,

Re: VQs in Gred!

[Thomas Graf]

* Zhenyu Wu <304306892.28448@njupt.edu.cn> 2004-12-29 15:54
> HOW does the Gred schedule packets of differnet priorities?

The packets are all enqueued onto the same queue. Gred is not
about prioritizing but only about dropping, hence once the packet
is enqueued it doesn't make sense to differ anymore. The difference
to normal red is that one can use separate red calculation
parameters per tcindex flow. tcindex is usually set via dsmark/
tcindex with contents of the dscp field. You might want to use a
more aggressive set of parameters for your bulk flows and treat
your interactive flows with more respect.

Re: VQs in Gred!

[Zhenyu Wu]

> > HOW does the Gred schedule packets of differnet priorities?
> 
> The packets are all enqueued onto the same queue. Gred is not
> about prioritizing but only about dropping, hence once the packet
> is enqueued it doesn't make sense to differ anymore. The difference

Ok. Then, if the average packet(qave) does not exceed the threshhold, that is, the
packet has not been dropped, it will be enqueued into the physical queue, right?
So we can't see the different process of scheduling packets which are from
different kinds of traffic, we just know which packet might be dropped, right?

> to normal red is that one can use separate red calculation
> parameters per tcindex flow. tcindex is usually set via dsmark/
> tcindex with contents of the dscp field. You might want to use a
> more aggressive set of parameters for your bulk flows and treat
> your interactive flows with more respect.

what does "the more aggressive set of parameters" mean? The parameters to Gred?

Thank you very much!
Best,

Re: VQs in Gred!

[Thomas Graf]

> Ok. Then, if the average packet(qave) does not exceed the threshhold, that is, the
> packet has not been dropped, it will be enqueued into the physical queue, right?
> So we can't see the different process of scheduling packets which are from
> different kinds of traffic, we just know which packet might be dropped, right?

Right, all packets, regardless of type, colour, flavour, whatever are enqueued
onto the same skb queue. You can always put a cbq/htb qdisc underneath
and have gred be the leaf qdisc so you can do the prioritizing before gred.
Be warned, heavy dropping in a gred leaf qdisc corrupts any rate estimations
in prio qdiscs.

> what does "the more aggressive set of parameters" mean? The parameters to Gred?

Yes, struct gred_sched_data.