Thread (21 messages) 21 messages, 4 authors, 2008-10-22

Re: [PATCH] pkt_sched: sch_netem: Limit packet re-ordering functionality to tfifo qdisc.

From: Stephen Hemminger <hidden>
Date: 2008-10-21 23:51:32

On Tue, 21 Oct 2008 16:36:05 -0700 (PDT)
David Miller [off-list ref] wrote:
From: Jarek Poplawski <redacted>
Date: Fri, 17 Oct 2008 22:12:10 +0200
quoted
pkt_sched: sch_netem: Limit packet re-ordering functionality to tfifo qdisc.

After introducing qdisc->ops->peek() method the only remaining user of
qdisc->ops->requeue() is netem_enqueue() using this for packet
re-ordering. According to Patrick McHardy: "a lot of the functionality
of netem requires the inner tfifo anyways and rate-limiting is usually
done on top of netem. So I would suggest so either hard-wire the tfifo
qdisc or at least make the assumption that inner qdiscs are work-
conserving." This patch tries the former.

Signed-off-by: Jarek Poplawski <redacted>
This is an interesting patch.

But the thing that strikes me is this: Why don't we just let sch_netem do
the reordering inside of itself entirely and just get rid of all of this
->requeue() business?

sch_netem is just a black box, like any other packet scheduler node in
the tree, and so it can internally do the reordering with a self managed
packet list or similar.  All of this can be hidden inside of it's ->dequeue()
with some pkt_sch watchdog timer that fires to prevent stale packets sitting
in the reorder queue forever.

Anyways, just and idea and RFC, just like this patch ;-)
The problem is that jamal talked me into having netem as a classful qdisc,
instead of doing its own rate control.  People like to do use TBF as inner qdisc,
and do reordering.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help