From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ns3.lanforge.com (mail.candelatech.com [208.74.158.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 1654521F095 for ; Wed, 11 Jul 2012 09:03:20 -0700 (PDT) Received: from [192.168.100.111] (firewall.candelatech.com [70.89.124.249]) (authenticated bits=0) by ns3.lanforge.com (8.14.2/8.14.2) with ESMTP id q6BG3CIM006377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jul 2012 09:03:13 -0700 Message-ID: <4FFDA3C0.9040909@candelatech.com> Date: Wed, 11 Jul 2012 09:03:12 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0 MIME-Version: 1.0 To: Eric Dumazet 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> <4FFD98EA.1040301@candelatech.com> <1342020306.3265.8129.camel@edumazet-glaptop> <4FFD9F18.6030401@candelatech.com> <1342022043.3265.8179.camel@edumazet-glaptop> In-Reply-To: <1342022043.3265.8179.camel@edumazet-glaptop> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 11 Jul 2012 09:17:48 -0700 Cc: nanditad@google.com, netdev@vger.kernel.org, mattmathis@google.com, codel@lists.bufferbloat.net, ncardwell@google.com, David Miller Subject: Re: [Codel] [RFC PATCH v2] tcp: TCP Small Queues X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 16:03:20 -0000 On 07/11/2012 08:54 AM, Eric Dumazet wrote: > On Wed, 2012-07-11 at 08:43 -0700, Ben Greear wrote: >> On 07/11/2012 08:25 AM, Eric Dumazet wrote: >>> On Wed, 2012-07-11 at 08:16 -0700, Ben Greear wrote: >>> >>>> I haven't read your patch in detail, but I was wondering if this feature >>>> would cause trouble for applications that are servicing many sockets at once >>>> and so might take several ms between handling each individual socket. >>>> >>> >>> Well, this patch has no impact for such applications. In fact their >>> send()/write() will return to userland faster than before (for very >>> large send()) >> >> Maybe I'm just confused. Is your patch just mucking with >> the queues below the tcp xmit queues? From the patch description >> I was thinking you were somehow directly limiting the TCP xmit >> queues... >> > > I dont limit tcp xmit queues. I might avoid excessive autotuning. > > > >> If you are just draining the tcp xmit queues on a new/faster >> trigger, then I see no problem with that, and no need for >> a per-socket control. > > Thats the plan : limiting numer of bytes in Qdisc, not number of bytes > in socket write queue. Thanks for the explanation. Out of curiosity, have you tried running multiple TCP streams with different processes driving each stream, where each is trying to drive, say, 700Mbps bi-directional traffic over a 1Gbps link? Perhaps with 50ms of latency generated by a network emulator. This used to cause some extremely high latency due to excessive TCP xmit queues (from what I could tell), but maybe this new patch will cure that. I'll re-run my tests with your patch eventually..but too bogged down to do so soon. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com