netdev - Re: [PATCH] sch_sfq: revert dont put new flow at the end of flows

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: <CAA93jw7mpV0pVN=7e2JNKBw7_Piax07P3sjC81Wbj36aPP42UA@mail.gmail.com>
Date:	Wed, 14 Mar 2012 06:07:57 +0000
From:	Dave Taht <dave.taht@...il.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	jdb@...x.dk, David Miller <davem@...emloft.net>,
	netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH] sch_sfq: revert dont put new flow at the end of flows

On Wed, Mar 14, 2012 at 5:02 AM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> Le mercredi 14 mars 2012 à 04:52 +0000, Dave Taht a écrit :
>
>> I had some hope for a semi-random alternating queue
>>
>
> I spent some time implementing two queues, one for new flows, one for
> old flows. As soon as a new flow uses its initial quantum, its moved at
> the tail of 'old flows queue'.
>
> But I always could find a way to starve some flows, even adding some
> kind of persistence. Right now, as soon as we empty one flow, we forget
> its history.
>
> Next packet coming will create a "new flow" with a full quantum credit,
> even if we nearly consume all flow quantum in the last micro second.
>
> Thats definitely not a trivial problem.

I've expended brain cells on this too (nobody has any experience with head drop,
aqm managed queues!), and was unable to come up with a way of dealing with
the corner case of too many new streams inside of sfq's current architecture.

But I gotta say that the overall effect of this on optimizing sparse streams
(dns,dhcp,tcp syn,ra,other routing packets,gaming packets,etc) was pretty
freaking amazing, and it nearly eliminated any need for classification and
prioritization, BE, and BK were enough.

Ah, well. The other stuff in 3.3 is really good, too.

Sometimes you win, sometimes you lose, sometimes... it rains.

>
>
>

-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
--
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