From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa0-x234.google.com (mail-oa0-x234.google.com [IPv6:2607:f8b0:4003:c02::234]) (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 CFB6A21F1B0 for ; Thu, 11 Jul 2013 17:06:38 -0700 (PDT) Received: by mail-oa0-f52.google.com with SMTP id g12so11972090oah.25 for ; Thu, 11 Jul 2013 17:06:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:x-mailer:content-transfer-encoding:mime-version; bh=RsleqoYjVgC+OJ6P8lRVnSYHnra1hN6VcFrOkWIMhmM=; b=0pGtvagGG5YiWRpoKWfnueROaFNaztyjMFwgV30XkmFHPBrF0ltrSiYnvhP/7cv+9E 1a6NByztafw1sRV/Ga1WwO76i4yd6EYar22Ogc17XKiBjkl4kXngHpa9eO46+xou7Wiy aDzaEeTgs6io1KciLAD4gJEFC0Hi+PTsTrux3oqd/+D/D+f/HgyLctqYcotjgWazPR4k X6oTvS1WRqXSaKNXbBWPM4fJW+Y8IWvbepQjcybwieXibWsa7f22UQpxtkl3Ru/f9P2G YZt2DRv0/ShFePBYpLxhWd93wD7CuOItVN2de8dPWSdMQOx+udy1es7b86Esdl6ceWDB 1asg== X-Received: by 10.182.242.103 with SMTP id wp7mr33925948obc.67.1373587597527; Thu, 11 Jul 2013 17:06:37 -0700 (PDT) Received: from ?IPv6:2620:0:1000:3304:d49d:873e:bd9b:d524? ([2620:0:1000:3304:d49d:873e:bd9b:d524]) by mx.google.com with ESMTPSA id i9sm52944976oem.7.2013.07.11.17.06.36 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Thu, 11 Jul 2013 17:06:36 -0700 (PDT) Message-ID: <1373587595.4600.114.camel@edumazet-glaptop> From: Eric Dumazet To: Dave Taht Date: Thu, 11 Jul 2013 17:06:35 -0700 In-Reply-To: References: <1373564673.4600.55.camel@edumazet-glaptop> <1373568848.4600.66.camel@edumazet-glaptop> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Cc: codel@lists.bufferbloat.net Subject: Re: [Codel] hardware multiqueue in fq_codel? 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, 12 Jul 2013 00:06:39 -0000 On Thu, 2013-07-11 at 14:18 -0700, Dave Taht wrote: > I have incidentally long thought that you are also tweaking target and > interval for your environment? Google data centers are spread all over the world, and speed of light was not increased by wonderful Google engineers, thats a real pity I can tell you. > > > Whole point of codel is that number of packets in the queue is > > irrelevant. Only sojourn time is. > > Which is a lovely thing in worlds with infinite amounts of memory. The limit is a tunable, not hard-coded in qdisc, like other qdiscs. I chose a packet count limit because pfifo was the target, and pfifo limit is given in packets, not in bytes. There is bfifo variant for a byte limited fifo, so feel free to add bcodel and fq_bcodel. Linux Qdiscs have some existing semantic. If every new qdisc had strange and new behavior, what would happen ? > > > Now if your host has memory concerns, that's a separate issue, and you > > can adjust the qdisc limit, or add a callback from mm to be able to > > shrink queue in case of memory pressure, if you deal with non elastic > > flows. > > So my take on this is that the default limit should be 1k on devices > with less than 256MB of ram overall, and 10k (or more) elsewhere. This > matches current txqueuelen behavior and has the least surprise. What is current 'txqueuelen behavior' ? Current 'txqueuelen behavior' is a limit of 16.000 packets on typical 10G hardware with 16 tx queues, not 1000 as you seem to believe. If txqueuelen was a percentage of available memory, we would be in a bad situation : With txqueuelen being 100 15 years ago, it would be 100.000 today, since ram was increased by 3 order of magnitude. 0.1 % would be too much for my laptop with 4GB of ram, and not enough for your 256MB host. I do not want to bloat codel/fq_codel with some strange concerns about skb truesize resizing. No other qdisc does this, with codel/fq_codel would be different ? This adds a huge performance penalty and latencies. A router should never even touch (read or write) a _single_ byte of the payload. Whole point having a queue is to absorb bursts : You don't want to spend cpu cycles when bursts are coming, or else there wont be bursts anymore, but losses episodes.