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] [day] [month] [year] [list]

Date:	Mon, 07 Apr 2008 16:14:14 +0100
From:	Andy Furniss <lists@...yfurniss.entadsl.com>
To:	Patrick McHardy <kaber@...sh.net>
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

Patrick McHardy wrote:
> Andy Furniss wrote:

>> --- sch_sfq.c.orig      2008-04-07 11:42:36.000000000 +0100
>> +++ sch_sfq.c   2008-04-07 11:46:41.000000000 +0100
>> @@ -317,6 +317,7 @@
>>                         q->next[x] = q->next[q->tail];
>>                         q->next[q->tail] = x;
>>                         q->tail = x;
>> +                       q->allot[x] = 0;
> 
> 
> That might fix the symptom, but I don't think its correct.
> As I said, you can't simply reset to zero since it might cause
> unfairness of bursty flows against non-bursty flows.

I guess it would be nice in some ways to make a drr that has memory but 
I think this is a bug.

It was the same pre jhash when perturb was needed so the slots would 
change anyway.

If it were intended to be a memory of allot it fails because allot 
should never be as wide as +/- 32k (maybe that could be fixed - but only 
recently became practical with jhash/no perturb).

Currently a new flow (but not the fist) gets dealt a seemingly random 
allot of +/- 32k which means it either gets to monopolise the link until 
it has wound down to <=0 or if allot is -ve it gets disadvantaged in the 
case that it's packet size is < than the others until its allot has 
crept up to 0. If it's packets are MTU size it just gets 1 packet per 
round and allot stays -ve.

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