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

[Andy Furniss <lists@andyfurniss.entadsl.com>]

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.