All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jarek Poplawski <jarkao2@gmail.com>
To: lists@andyfurniss.entadsl.com
Cc: David Miller <davem@davemloft.net>,
	Patrick McHardy <kaber@trash.net>,
	netdev@vger.kernel.org
Subject: Re: [PATCH][NET_SCHED] sch_sfq: prevent unnecessary reordering
Date: Mon, 28 Apr 2008 17:41:46 +0200	[thread overview]
Message-ID: <20080428154146.GC2870@ami.dom.local> (raw)
In-Reply-To: <4815B6EA.5070201@andyfurniss.entadsl.com>

Andy Furniss wrote, On 04/28/2008 01:37 PM:

> Jarek Poplawski wrote:
>> On 27-04-2008 16:22, Jarek Poplawski wrote:
>>> [NET_SCHED] sch_sfq: fix queue limiting while enqueuing
>>>
>> David, as Patrick noticed this patch was wrong and I withdraw it.
>>
>> I still can't see why sfq should have such a low limit,
> 
> It's a useful param which I use - on slow egress I can't see the point 
> of queuing many seconds worth of traffic. It may also help keep stronger 
> connections in check.

I agree the param is useful, but I can't see any technical reason why
sfq can't do a bit more queuing sometimes - especially when we expect
more flows/users per qdisc (probably another param would be necessary
for this).

> When shaping ingress it's essential to drop early to get out of 
> slowstart before the far buffer gets too full.
> 
> 
>> [NET_SCHED] sch_sfq: prevent unnecessary reordering
>>
>> Current check of queue limit in sfq_enqueue() isn't optimal: there
>> is really not much more needed to prevent unnecessary dropping and
>> possible reordering.
> 
> Maybe it makes no difference in the long run, but if you drop and then 
> enqueue a later packet the sender will get to know sooner so congestion 
> control can do it's stuff.

Happilly(?) it looks like my patch will not change here a lot...

Thanks for comments,
Jarek P.

      reply	other threads:[~2008-04-28 15:43 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-27 14:22 [PATCH][NET_SCHED] sch_sfq: fix queue limiting while enqueuing Jarek Poplawski
2008-04-27 18:29 ` Patrick McHardy
2008-04-27 20:36   ` Jarek Poplawski
2008-04-28 14:02     ` Patrick McHardy
2008-04-28 14:58       ` Jarek Poplawski
2008-04-29 20:53         ` Jarek Poplawski
2008-04-30  7:04           ` Jarek Poplawski
2008-04-30  7:12             ` Patrick McHardy
2008-04-28  9:04 ` [PATCH][NET_SCHED] sch_sfq: prevent unnecessary reordering Jarek Poplawski
2008-04-28  9:03   ` David Miller
2008-04-28 14:39     ` Jarek Poplawski
2008-04-28 11:37   ` Andy Furniss
2008-04-28 15:41     ` Jarek Poplawski [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080428154146.GC2870@ami.dom.local \
    --to=jarkao2@gmail.com \
    --cc=davem@davemloft.net \
    --cc=kaber@trash.net \
    --cc=lists@andyfurniss.entadsl.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.