From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com [209.85.214.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 0ED2721F095 for ; Wed, 11 Jul 2012 08:54:07 -0700 (PDT) Received: by bkty15 with SMTP id y15so2028757bkt.16 for ; Wed, 11 Jul 2012 08:54:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; bh=r2mjVgv53T4S0GyGNbhSku8ZQbxyRKOiI6zh1ueVzRA=; b=LeZudvG6wlzSQnqSxP/BwJVc/L+zcP4GNSfs6bOJWCWODnhmGwwnCQyo6LGS6Ad83/ gZNCeWuN34HiVKFPF9j8wMvYGnxh8Lstftf4ewrZ7fw7lr+XbZ1YQfmIAVh8ImlnQKuh XAPKSwflycEgwETD/SstPY34zCME7Lunn1c+hNRJlBP56uLoluAIA7wrPcBnuFcB66zE Z9O7S4mSy0aK3oAb8evh7htf0jg4W+4UQKmsH0AYcz6Kwc3FiEEl6dXRo31JEcO63PaU VKe81g5EGCGY19mfLXqyYpYx94SHPNGGYJO2lW1N7BiMF4PdD6okhlT9c/xFj4dRNsZP paWw== Received: by 10.205.127.131 with SMTP id ha3mr20138216bkc.123.1342022045946; Wed, 11 Jul 2012 08:54:05 -0700 (PDT) Received: from [172.28.88.151] ([74.125.122.49]) by mx.google.com with ESMTPS id o4sm1487096bkv.15.2012.07.11.08.54.04 (version=SSLv3 cipher=OTHER); Wed, 11 Jul 2012 08:54:05 -0700 (PDT) From: Eric Dumazet To: Ben Greear In-Reply-To: <4FFD9F18.6030401@candelatech.com> 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> Content-Type: text/plain; charset="UTF-8" Date: Wed, 11 Jul 2012 17:54:03 +0200 Message-ID: <1342022043.3265.8179.camel@edumazet-glaptop> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit 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 15:54:08 -0000 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.