netdev - Re: [NET_SCHED 00/04]: External SFQ classifiers/flow classifier

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: <47F37E04.4010001@trash.net>
Date:	Wed, 02 Apr 2008 14:37:24 +0200
From:	Patrick McHardy <kaber@...sh.net>
To:	lists@...yfurniss.entadsl.com
CC:	Corey Hickey <bugfood-ml@...ooh.org>,
	Linux Netdev List <netdev@...r.kernel.org>
Subject: Re: [NET_SCHED 00/04]: External SFQ classifiers/flow classifier

Andy Furniss wrote:
> Andy Furniss wrote:
> 
>> It's cool being able to see the sfq flows.
> 
> It's also interesting to notice that allot varies so much.
> 
> I have seen +/- 10 * my quantum which I didn't expect, I wonder if it 
> needs to be cleared when a flow empties or something.
> 
> The source for sfq is a bit hard to follow so I don't really know what's 
> happening. I was dropping with limit of 40 (about a second at my rate) 
> and had quite a few connections active, hashing on dst.
> 
> tcpdump also shows that single flows are getting 3/4/5 packets dequeued 
> in a row when there are other flows active.
> 
> I guess it's hard to tell the state at any one instant when dropping and 
> making flows dis/reappear but it does seem to behave in a way that 
> amplifies burstyness.
> 
> My quantum = mtu + 14 and there are no giants.


I'm not really sure myself. SFQ and CBQ DRR differ slightly from
the original DRR algorithm by allowing the quantum to go negative
and carrying it over in the next round, where it has to be made
up for. CBQ DRR differs from SFQ in that it keeps an inactive
flow (==empty queue) active until it reaches a positive quantum
again, which is necessary for this implementation if you want
to reset the quantum to avoid having a bursty flow send out its
last packet by overusing its quantum, then going passive and
immediately active again with a full new quantum. This would
cause unfairness against constantly active flows. CBQ does
not reset the quantum when activating a class though, which
also looks like a bug.

I haven't fully understood the differences between the SFQ/CBQ
DRR implementations and the original DRR algorithm, but I'm
looking into it for other reasons anyways (my DRR scheduler
uses a similar implementation because it avoids the need to
requeue and I want to properly understand this before pushing
it upstream), so I can hopefully soon tell you more :)


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