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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <48FF4E38.9010806@trash.net>
Date:	Wed, 22 Oct 2008 18:00:56 +0200
From:	Patrick McHardy <kaber@...sh.net>
To:	Jarek Poplawski <jarkao2@...il.com>
CC:	Stephen Hemminger <shemminger@...tta.com>,
	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	herbert@...dor.apana.org.au
Subject: Re: [PATCH] pkt_sched: sch_netem: Limit packet re-ordering	functionality
 to tfifo qdisc.

Jarek Poplawski wrote:
> On Tue, Oct 21, 2008 at 04:51:29PM -0700, Stephen Hemminger wrote:
>> On Tue, 21 Oct 2008 16:36:05 -0700 (PDT)
>> David Miller <davem@...emloft.net> wrote:
>>
>>> 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.
> 
> 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.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html