From: Patrick McHardy <kaber@trash.net>
To: Jarek Poplawski <jarkao2@gmail.com>
Cc: Stephen Hemminger <shemminger@vyatta.com>,
David Miller <davem@davemloft.net>,
netdev@vger.kernel.org, herbert@gondor.apana.org.au
Subject: Re: [PATCH] pkt_sched: sch_netem: Limit packet re-ordering functionality to tfifo qdisc.
Date: Wed, 22 Oct 2008 19:32:02 +0200 [thread overview]
Message-ID: <48FF6392.5000305@trash.net> (raw)
In-Reply-To: <20081022164925.GB2556@ami.dom.local>
Jarek Poplawski wrote:
> On Wed, Oct 22, 2008 at 06:00:56PM +0200, Patrick McHardy wrote:
>> Jarek Poplawski wrote:
>>> If it's only this kind of usage we could export tfifo and let use this
>>> as a TBF's (etc.) leaf. Of course, this would require changes in those
>>> people scripts.
>> In that case we might as well teach them to use TBF as *parent*
>> of netem (and I'd vote to do that and kill requeue).
>>
>> But we can argue about this forever without any progress. The
>> question is simple - should we enforce a reasonable qdisc structure
>> and kill ->requeue or keep it around forever. Keep in mind that there
>> is no loss of functionality by using TBF as parent and that we
>> can do this gradually so users have a chance to fix their scripts,
>> should anyone really use TBF as inner qdisc.
>>
>
> I'm not sure we think about the same: this tfifo idea doesn't need
> ->requeue() at all. This would go through TBF's or prio's (etc.)
> ->enqueue(), and only tfifo's ->enqueue(), if it's used as a leaf,
> checks the qdisc flag and can reorder.
I see. So both ways would work fine to get rid of requeue. The
flag doesn't seem to be necessary though since tfifo already
does reordering based on time_to_send.
> But if it's useless, no problem. I can redo this patch without this
> qdisc flag.
Well, you're doing the work, so you decide. I'm undecided myself,
the main issues I see are:
- we might have to reeducate users twice if we decide to enforce
more structure later on
- a lot of other qdiscs still don't work as inner qdiscs of netem:
- any reordering qdisc can cause stalls since netem_dequeue
expects to get packets ordered by time_to_send. This means we
can't use cbq, hfsc, htb, prio, sfq, leaving atm, dsmark, netem,
red, gred, tbf and the fifos. I guess we can strike atm as
"makes no sense" and dsmark as "obsolete since 10(?) years".
- netem can't be used as inner qdisc since it would corrupt the
skb's cb
So the usable inner qdiscs are: tbf, red, gred, *fifo. The fact
that over 50% of the qdiscs you could use can cause misbehaviour
and TBF, red and gred can be used as upper qdiscs without any loss
of functionality makes me think netem simply shouldn't be classful.
So actually I am decided :) I think netem shouldn't be classful.
next prev parent reply other threads:[~2008-10-22 17:32 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-16 9:46 [PATCH 0/6] Add qdisc->ops->peek() support Jarek Poplawski
2008-10-16 12:38 ` Patrick McHardy
2008-10-16 13:08 ` Jarek Poplawski
2008-10-16 22:09 ` Jarek Poplawski
2008-10-17 12:33 ` Patrick McHardy
2008-10-17 13:03 ` Jarek Poplawski
2008-10-17 14:12 ` Patrick McHardy
2008-10-17 20:12 ` [PATCH] pkt_sched: sch_netem: Limit packet re-ordering functionality to tfifo qdisc Jarek Poplawski
2008-10-21 23:36 ` David Miller
2008-10-21 23:51 ` Stephen Hemminger
2008-10-22 5:37 ` Jarek Poplawski
2008-10-22 16:00 ` Patrick McHardy
2008-10-22 16:49 ` Jarek Poplawski
2008-10-22 17:32 ` Patrick McHardy [this message]
2008-10-22 17:53 ` [RFC] " Jarek Poplawski
2008-10-22 15:57 ` [PATCH] " Patrick McHardy
2008-10-22 16:00 ` Patrick McHardy
2008-10-17 20:45 ` [PATCH 0/6] Add qdisc->ops->peek() support Jarek Poplawski
2008-10-21 23:43 ` David Miller
2008-10-22 16:01 ` Patrick McHardy
2008-10-22 16:04 ` Patrick McHardy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48FF6392.5000305@trash.net \
--to=kaber@trash.net \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=jarkao2@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=shemminger@vyatta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).