From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) (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 E8D4221F1D6 for ; Wed, 10 Jul 2013 15:44:48 -0700 (PDT) Received: by mail-vc0-f175.google.com with SMTP id hr11so6116189vcb.20 for ; Wed, 10 Jul 2013 15:44:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=FzCQi/mkSWye0Y/r24pEdBcBAmH5LcX3zM9SFZB2kjk=; b=Vk1hZNZJa0qK1zeAuDbQbBPzwmnhqB+Q94lFPnpvmgvn4etgiGSeJ0w35ZawR5l1G+ YTHotXM19aEUVpXZKDnHhkpJ4DzDWgI4osm6tC8WeSW5nNl7QjBeJSOpwm2jpHc39F9B ttSE9LjrHgEIF1JAWbdpQYChMzIU8Xknpy52BpB11TYVC4isf3AmyTnjeOE0XyoU6jVI 0YcHZ4k1QwIhKxbaNjqZycUCdIAvKNa+OQcwvKF6+WhadGTN65khnpinH447pMbjC1tV RbGqRQ2bLQY+NbHGKHVprc7TkiWx4JluISvb5IsVUh4sWJAdUmJD71d3jpm95KP+8cuJ GdKw== MIME-Version: 1.0 X-Received: by 10.220.197.72 with SMTP id ej8mr20381727vcb.66.1373496287557; Wed, 10 Jul 2013 15:44:47 -0700 (PDT) Received: by 10.58.123.102 with HTTP; Wed, 10 Jul 2013 15:44:47 -0700 (PDT) In-Reply-To: References: Date: Wed, 10 Jul 2013 15:44:47 -0700 Message-ID: From: Dave Taht To: Kathleen Nichols Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Keith Winstein , "codel@lists.bufferbloat.net" Subject: Re: [Codel] sprout 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, 10 Jul 2013 22:44:49 -0000 On Wed, Jul 10, 2013 at 3:10 PM, Kathleen Nichols wro= te: > Is that indeed what I think? Heh. On another topic, at my stanford talk, you pointed at maxpacket being a thing you were a bit dubious about. After fiddling with the concept in presence of offloads (which bloat up maxpacket to the size of a tso packet (20k or more)) I'm more than a bit dubious about it and in my next build of ns2_codel and nfq_codel in linux I just capped it at a mtu in the codel_should_drop function: if (unlikely(qdisc_pkt_len(skb) > stats->maxpacket && qdisc_pkt_len(skb) < 1514 )) stats->maxpacket =3D qdisc_pkt_len(skb); Perhaps in fq_codel the entire maxpacket idea can be junked? The problem that I see is that codel switches out of a potential drop state here and at almost any workload maxpacket hits a TSO-like size, and at higher worklo= ads it's too high. I think eric is working on something that will let overlarge packets just work and begin to break them down into smaller packets at higher workloads? Also I'd made a suggestion elsewhere that TSQ migrate down in size from 128k to lower as the number of active flows increased. Something like tcp_limit_output_size =3D max((2*BQL's limit)/(number of flows),mtu) but I realize now that tcp has no idea what interface it's going out at any given time... still I'm on a quest to minimize latency and let offloads still wor= k.. --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html