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 671D921F095 for ; Wed, 11 Jul 2012 08:25:12 -0700 (PDT) Received: by bkty15 with SMTP id y15so1957754bkt.16 for ; Wed, 11 Jul 2012 08:25:10 -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=Gb6FmkRle8VV7HEA6cOlZFEXK9TLtHMx9EhiO+mQWHQ=; b=sDuSaO2xkJDV1zcM9LBKfZdyjA+EfHQZt/SRcydfQTU9ayHkKI26inaYv4Pg7Fyxfr cT1ksEaYysBE5L+d/R+Rj/ljRXNhfmxcrQK8ygp8jEhzqtH7hpMhmxBslEdUNh5Y8iNV Y/uKc+DJUTsEWIDdDTPZR9fF0DA9iGbWJLakw+HR3jqgKnDfNpe9Sos5VTk/F8Z6kxbO zjmKNeOPSOBlExQUCrZmcrY4Q1SaduKbMIX7E1P/CY4Lz7xqhW5tSb3DsP/kdIUcOtpS uT2ZWY+UxYkBDg62ea8T6Oo1gFMp2G2L/n3nyvKrMa42+Nnh7E3ieuTh+VQTq00nUMYl jqVg== Received: by 10.205.126.13 with SMTP id gu13mr15668978bkc.79.1342020310092; Wed, 11 Jul 2012 08:25:10 -0700 (PDT) Received: from [172.28.88.151] ([74.125.122.49]) by mx.google.com with ESMTPS id n17sm1439679bks.6.2012.07.11.08.25.08 (version=SSLv3 cipher=OTHER); Wed, 11 Jul 2012 08:25:09 -0700 (PDT) From: Eric Dumazet To: Ben Greear In-Reply-To: <4FFD98EA.1040301@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> Content-Type: text/plain; charset="UTF-8" Date: Wed, 11 Jul 2012 17:25:06 +0200 Message-ID: <1342020306.3265.8129.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:25:12 -0000 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()) > Or, applications that for other reasons cannot service sockets quite > as fast. Without this feature, they could poke more data into the > xmit queues to be handled by the kernel while the app goes about it's > other user-space work? > There is no impact for the applications. They queue their data in socket write queue, and tcp stack do the work to actually transmit data and handle ACKS. Before this patch, this work was triggered by : - Timers - Incoming ACKS We now add a third trigger : TX completion > Maybe this feature could be enabled/tuned on a per-socket basis? Well, why not, but I want first to see why it would be needed. I mean, if a single application _needs_ to send MBytes of tcp data in Qdisc at once, everything else on the machine is stuck (as today) So just increase global param.