[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4D08F025.5030603@trash.net>
Date: Wed, 15 Dec 2010 17:43:17 +0100
From: Patrick McHardy <kaber@...sh.net>
To: Eric Dumazet <eric.dumazet@...il.com>
CC: David Miller <davem@...emloft.net>,
netdev <netdev@...r.kernel.org>,
Jarek Poplawski <jarkao2@...il.com>
Subject: Re: [PATCH v2] net_sched: sch_sfq: fix allot handling
On 15.12.2010 17:40, Eric Dumazet wrote:
> Le mercredi 15 décembre 2010 à 17:27 +0100, Eric Dumazet a écrit :
>
>> Hmm, you may be right, thanks a lot for reviewing !
>>
>> I noticed that with normal quantum (1514), my SFQ setup was sending two
>> full frames per flow after my patch, so was about to prepare a new
>> version ;)
>>
>> I'll post a v2 shortly.
>
> Indeed, the missing init in sfq_enqueue() is enough to solve the
> problem :
>
> [PATCH v2] net_sched: sch_sfq: fix allot handling
>
> When deploying SFQ/IFB here at work, I found the allot management was
> pretty wrong in sfq, even changing allot from short to int...
>
> We should init allot for each new flow, not using a previous value found
> in slot.
>
> Before patch, I saw bursts of several packets per flow, apparently
> denying the default "quantum 1514" limit I had on my SFQ class.
>
> diff --git a/net/sched/sch_sfq.c b/net/sched/sch_sfq.c
> index 3cf478d..065a2a5 100644
> --- a/net/sched/sch_sfq.c
> +++ b/net/sched/sch_sfq.c
> @@ -321,14 +321,13 @@ sfq_enqueue(struct sk_buff *skb, struct Qdisc *sch)
> sfq_inc(q, x);
> if (q->qs[x].qlen == 1) { /* The flow is new */
> if (q->tail == SFQ_DEPTH) { /* It is the first flow */
> - q->tail = x;
> q->next[x] = x;
> - q->allot[x] = q->quantum;
> } else {
> q->next[x] = q->next[q->tail];
> q->next[q->tail] = x;
> - q->tail = x;
> }
> + q->tail = x;
> + q->allot[x] = q->quantum;
> }
Now we could remove the allot increase in sfq_dequeue for
the case that the flow becomes inactive. It is incorrect
anyways.
--
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
Powered by blists - more mailing lists