From mboxrd@z Thu Jan  1 00:00:00 1970
From: David Miller <davem@davemloft.net>
Subject: Re: [PATCH v2 net-next] pkt_sched: fq: Fair Queue packet scheduler
Date: Thu, 29 Aug 2013 21:47:30 -0400 (EDT)
Message-ID: <20130829.214730.2158572637993114547.davem@davemloft.net>
References: <1377816595.8277.54.camel@edumazet-glaptop>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: netdev@vger.kernel.org, ycheng@google.com, ncardwell@google.com
To: eric.dumazet@gmail.com
Return-path: <netdev-owner@vger.kernel.org>
Received: from shards.monkeyblade.net ([149.20.54.216]:41165 "EHLO
	shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1754227Ab3H3Brf (ORCPT
	<rfc822;netdev@vger.kernel.org>); Thu, 29 Aug 2013 21:47:35 -0400
In-Reply-To: <1377816595.8277.54.camel@edumazet-glaptop>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 29 Aug 2013 15:49:55 -0700

> From: Eric Dumazet <edumazet@google.com>
> 
> - Uses perfect flow match (not stochastic hash like SFQ/FQ_codel)
> - Uses the new_flow/old_flow separation from FQ_codel
> - New flows get an initial credit allowing IW10 without added delay.
> - Special FIFO queue for high prio packets (no need for PRIO + FQ)
> - Uses a hash table of RB trees to locate the flows at enqueue() time
> - Smart on demand gc (at enqueue() time, RB tree lookup evicts old
>   unused flows)
> - Dynamic memory allocations.
> - Designed to allow millions of concurrent flows per Qdisc.
> - Small memory footprint : ~8K per Qdisc, and 104 bytes per flow.
> - Single high resolution timer for throttled flows (if any).
> - One RB tree to link throttled flows.
> - Ability to have a max rate per flow. We might add a socket option
>   to add per socket limitation.
> 
> Attempts have been made to add TCP pacing in TCP stack, but this
> seems to add complex code to an already complex stack.
> 
> TCP pacing is welcomed for flows having idle times, as the cwnd
> permits TCP stack to queue a possibly large number of packets.
> 
> This removes the 'slow start after idle' choice, hitting badly
> large BDP flows, and applications delivering chunks of data
> as video streams.
> 
> Nicely spaced packets :
> Here interface is 10Gbit, but flow bottleneck is ~20Mbit
> 
> cwin is big, yet FQ avoids the typical bursts generated by TCP
> (as in netperf TCP_RR -- -r 100000,100000)
 ...
> Signed-off-by: Eric Dumazet <edumazet@google.com>

Applied, thanks Eric!