netdev - Re: [PATCH v2] pkt_sched: sch_drr: Fix drr

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: <20081124134516.GD16755@ff.dom.local>
Date:	Mon, 24 Nov 2008 13:45:16 +0000
From:	Jarek Poplawski <jarkao2@...il.com>
To:	Patrick McHardy <kaber@...sh.net>
Cc:	"David S. Miller" <davem@...emloft.net>,
	Linux Netdev List <netdev@...r.kernel.org>
Subject: Re: [PATCH v2] pkt_sched: sch_drr: Fix drr_dequeue() loop

On Mon, Nov 24, 2008 at 02:17:32PM +0100, Patrick McHardy wrote:
> Jarek Poplawski wrote:
>> On Mon, Nov 24, 2008 at 01:38:48PM +0100, Patrick McHardy wrote:
>> ...
>>> TBF with an inner DRR is fine. The other way around is broken
>>> in the sense that the behaviour is undefined.
>>
>> IMHO, this other way (e.g. a class with TBF per user), should work too.
>
> The behaviour undefined, so what does "work too" mean in this context?
>
> The main question is: what should be done with the class when it
> throttles?
>
> You suggest moving it to the end of the active list. Should its deficit
> be recharged in that case? Possible no because it didn't send packets -
> but then again it might have handed out *some* packets (less than the
> deficit) before it started throttling. Both ways would introduce
> unfairness.
>
> What could be done without harming the algorithm is to treat throttled
> classes as inactive until they become unthrottled again, meaning they
> would be added to the end of the active list with a full deficit. But
> we have no indication for specific classes, unthrottling simply triggers
> another dequeue of the root, so the implementation would get quite
> complicated, leaving alone the fact that each TBF would potentially
> start its own watchdog, causing excessive wakeups.
>
> And I don't see much use for this, what is the advantage over using
> HTB or HFSC?

Probably no advantage, if you now these things... or for testing. But
I like to give users a choice, at least if it's not obviously wrong.
Of course, if you think this harms the proper configs with too much
overhead, then there is no question we should forget about this.

Jarek P.
--
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