netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: Jarek Poplawski <jarkao2@gmail.com>
Cc: David Miller <davem@davemloft.net>, netdev@vger.kernel.org
Subject: Re: [PATCH 00/14]: Killing qdisc->ops->requeue().
Date: Wed, 15 Oct 2008 11:45:51 +0200	[thread overview]
Message-ID: <48F5BBCF.3060002@trash.net> (raw)
In-Reply-To: <20081015082726.GA5140@ff.dom.local>

Jarek Poplawski wrote:
> On Tue, Oct 14, 2008 at 10:44:13PM +0200, Patrick McHardy wrote:
> ...
>> I think we really need a peek operation since most qdiscs do have
>> some internal priorization. The question is whether all qdiscs need
>> it; I tend to think no.
> 
> Looking at qdisc_peek_len() seems to confirm a peek would be useful.
> But since this all started from the question if ->requeue() could be
> killed or simplified, I wonder if adding this peek could really help
> with this problem without too much reworking. It looks like at least
> sch_netem would still need more.

Indeed. netem is really a special case, it would be good if we could
treat it as such without requiring this kind of support from all qdiscs.
An idea would be to use a second queue for reordering that is always
tried to dequeue first. That should behave identical to what it does
now, except when the inner qdisc does reordering or rate limiting
itself.

> But if it's rather about adding something new and useful I'm OK with
> this. Anyway, I need some time to rethink this one and your previous
> description.

The main idea was to get rid of ->requeue, but it would also simplify
things slightly for HFSC, TBF and DRR (unsubmitted patch of mine).

  reply	other threads:[~2008-10-15  9:45 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-14  9:52 [PATCH 00/14]: Killing qdisc->ops->requeue() Jarek Poplawski
2008-10-14 11:39 ` Patrick McHardy
2008-10-14 12:26   ` Jarek Poplawski
2008-10-14 12:32     ` Patrick McHardy
2008-10-14 17:56       ` Jarek Poplawski
2008-10-14 20:18         ` David Miller
2008-10-14 20:44         ` Patrick McHardy
2008-10-15  8:27           ` Jarek Poplawski
2008-10-15  9:45             ` Patrick McHardy [this message]
2008-10-14 16:41 ` Alexander Duyck
2008-10-14 18:37   ` Jarek Poplawski
2008-10-14 18:41     ` Jarek Poplawski
2008-10-14 19:15   ` Jarek Poplawski
2008-10-14 20:37     ` Alexander Duyck
2008-10-15  6:45       ` Jarek Poplawski
2008-10-15  7:19         ` Jarek Poplawski

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=48F5BBCF.3060002@trash.net \
    --to=kaber@trash.net \
    --cc=davem@davemloft.net \
    --cc=jarkao2@gmail.com \
    --cc=netdev@vger.kernel.org \
    /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).