From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ee0-f43.google.com (mail-ee0-f43.google.com [74.125.83.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 BF60921F091 for ; Thu, 28 Jun 2012 21:51:03 -0700 (PDT) Received: by eeke50 with SMTP id e50so1942564eek.16 for ; Thu, 28 Jun 2012 21:51:01 -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=KumuC1ZuGdzjo7wWam5ajOBp8gHX8l8uBM+8Fd8uvUw=; b=gLHuvRWj3Obx87MGYLGPNy1F8Id5aqNWX21Z5YSpOpb5TjHMsMDjAGR6AYDZHddyjT YeVK1l16O5nwweVdrcR3rNtqwG6CsdCMq4oUgbRZzubNW6rtX7VB3r/Ur5f/dZe+FBOV +xEWJOqu/5clXP05bz0lOi9aArAlb0OI5ZUQGyoJmeKwn7pXVKCRRTymx/VId0Yai0O3 nBRIAMQst9h2HOpTjBcZlze6qjfZQBjkITp/Zh2JSGAcYxxT0g8YMqvyIMS9i9tBiYSD iQnhT9suBzv40xTyli48o3kgCvgu9EdK01qYaeRmC8hhDFV8Fcs5+mdIiZdc3r/B+rdZ Wo5Q== Received: by 10.216.203.80 with SMTP id e58mr63884weo.41.1340945461067; Thu, 28 Jun 2012 21:51:01 -0700 (PDT) Received: from [172.28.88.52] ([74.125.122.49]) by mx.google.com with ESMTPS id m4sm3871691wie.1.2012.06.28.21.50.58 (version=SSLv3 cipher=OTHER); Thu, 28 Jun 2012 21:51:00 -0700 (PDT) From: Eric Dumazet To: Dave Taht In-Reply-To: References: <1340903237.13187.151.camel@edumazet-glaptop> <1340907151.13187.169.camel@edumazet-glaptop> Content-Type: text/plain; charset="UTF-8" Date: Fri, 29 Jun 2012 06:50:57 +0200 Message-ID: <1340945457.29822.7.camel@edumazet-glaptop> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: Nandita Dukkipati , netdev , Yuchung Cheng , codel@lists.bufferbloat.net, Matt Mathis , Neal Cardwell , David Miller Subject: Re: [Codel] [PATCH net-next] fq_codel: report congestion notification at enqueue time 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: Fri, 29 Jun 2012 04:51:04 -0000 On Thu, 2012-06-28 at 19:47 -0400, Dave Taht wrote: > On Thu, Jun 28, 2012 at 6:56 PM, Yuchung Cheng wrote: > > On Thu, Jun 28, 2012 at 11:12 AM, Eric Dumazet wrote: > >> On Thu, 2012-06-28 at 10:51 -0700, Dave Taht wrote: > >> > >>> clever idea. A problem is there are other forms of network traffic on > >>> a link, and this is punishing a single tcp > > Dave: it won't just punish a single TCP, all protocols that react to > > XMIT_CN will share similar fate. > > What protocols in the kernel do and don't? was the crux of this question. > AFAIK that only tcp cares a bit, or seems to. But not that much, since it continues to send packets. Thats because tcp_transmit_skb() changes the NET_XMIT_CN status to plain NET_XMIT_SUCCESS. My long term plan is to reduce number of skbs queued in Qdisc for TCP stack, to reduce RTT (removing the artificial RTT bias because of local queues) > I'm not objecting to the idea, it's clever, as I said. I'm thinking I'll > apply it to cerowrt's next build and see what happens, if this > will apply against 3.3. Or maybe the ns3 model. Or both. A router will have no use of this feature, not sure you need to spend time trying this ;)