netdev - Re: [PATCH][NET_SCHED] sch_sfq: prevent unnecessary reordering

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]

Date:	Mon, 28 Apr 2008 12:37:14 +0100
From:	Andy Furniss <lists@...yfurniss.entadsl.com>
To:	Jarek Poplawski <jarkao2@...il.com>
CC:	David Miller <davem@...emloft.net>,
	Patrick McHardy <kaber@...sh.net>, netdev@...r.kernel.org
Subject: Re: [PATCH][NET_SCHED] sch_sfq: prevent unnecessary reordering

Jarek Poplawski wrote:
> On 27-04-2008 16:22, Jarek Poplawski wrote:
>> [NET_SCHED] sch_sfq: fix queue limiting while enqueuing
>>
> 
> David, as Patrick noticed this patch was wrong and I withdraw it.
> 
> I still can't see why sfq should have such a low limit,

It's a useful param which I use - on slow egress I can't see the point 
of queuing many seconds worth of traffic. It may also help keep stronger 
connections in check.

When shaping ingress it's essential to drop early to get out of 
slowstart before the far buffer gets too full.

> 
> [NET_SCHED] sch_sfq: prevent unnecessary reordering
> 
> Current check of queue limit in sfq_enqueue() isn't optimal: there
> is really not much more needed to prevent unnecessary dropping and
> possible reordering.

Maybe it makes no difference in the long run, but if you drop and then 
enqueue a later packet the sender will get to know sooner so congestion 
control can do it's stuff.

Andy.
--
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