From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Dumazet Subject: Re: [RFC PATCH v2] tcp: TCP Small Queues Date: Thu, 12 Jul 2012 01:38:35 +0200 Message-ID: <1342049915.3265.8184.camel@edumazet-glaptop> References: <1340945457.29822.7.camel@edumazet-glaptop> <1341396687.2583.1757.camel@edumazet-glaptop> <20120709.000834.1182150057463599677.davem@davemloft.net> <1341845722.3265.3065.camel@edumazet-glaptop> <1341933215.3265.5476.camel@edumazet-glaptop> <1342019518.3265.8116.camel@edumazet-glaptop> <4FFDC48D.2030606@hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: nanditad@google.com, netdev@vger.kernel.org, mattmathis@google.com, codel@lists.bufferbloat.net, ncardwell@google.com, David Miller To: Rick Jones Return-path: In-Reply-To: <4FFDC48D.2030606@hp.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: codel-bounces@lists.bufferbloat.net Errors-To: codel-bounces@lists.bufferbloat.net List-Id: netdev.vger.kernel.org On Wed, 2012-07-11 at 11:23 -0700, Rick Jones wrote: > On 07/11/2012 08:11 AM, Eric Dumazet wrote: > > > > > > Tests using a single TCP flow. > > > > Tests on 10Gbit links : > > > > > > echo 16384 >/proc/sys/net/ipv4/tcp_limit_output_bytes > > OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.99.2 (192.168.99.2) port 0 AF_INET > > tcpi_rto 201000 tcpi_ato 0 tcpi_pmtu 1500 tcpi_rcv_ssthresh 14600 > > tcpi_rtt 1875 tcpi_rttvar 750 tcpi_snd_ssthresh 16 tpci_snd_cwnd 79 > > tcpi_reordering 53 tcpi_total_retrans 0 > > I take it you hacked your local copy of netperf to emit those? Or did I > leave some cruft behind in something I committed to the repository? > Yep, its a netperf-2.5.0 with a one line change to output these TCP_INFO bits > What was the ultimate limiter on throughput? I notice it didn't achieve > link-rate on either 10 GbE nor 1 GbE. > My lab has one fast machine (source in this 10Gb test), and one slow machine (Intel Q6600 quad core), both with ixgbe cards. On Gigabit test, the receiver is a laptop. > > Thats the plan : limiting numer of bytes in Qdisc, not number of bytes > > in socket write queue. > > So the SO_SNDBUF can still grow rather larger than necessary? It is > just that TCP will be nice to the other flows by not dumping all of it > into the qdisc at once. Latency seen by the application itself is then > unchanged since there will still be (potentially) as much stuff queued > in the SO_SNDBUF as before right? Of course SO_SNDBUF can grow if autotuning is enabled. I think there is a bit of misunderstanding about this patch and what it does. It only makes sure the amount of packets (from socket write queue) are cloned in qdisc/device queue in a limited way, not "as much as allowed"