From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 0E95D3B25E; Fri, 6 May 2016 12:30:24 -0400 (EDT) Received: from hms-beagle.railnet.train ([88.128.81.70]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MKqOW-1ayids3aAS-00019k; Fri, 06 May 2016 18:30:17 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: moeller0 In-Reply-To: <1462550314.13075.51.camel@edumazet-glaptop3.roam.corp.google.com> Date: Fri, 6 May 2016 18:30:13 +0200 Cc: Jesper Dangaard Brouer , =?utf-8?Q?Dave_T=C3=A4ht?= , make-wifi-fast@lists.bufferbloat.net, ath10k , "codel@lists.bufferbloat.net" , Jonathan Morton , Roman Yeryomin Content-Transfer-Encoding: quoted-printable Message-Id: <98D677A4-8310-455B-9F7A-65C0B168E961@gmx.de> References: <865DA393-262D-40B6-A9D3-1B978CD5F6C6@gmail.com> <1462128385.5535.200.camel@edumazet-glaptop3.roam.corp.google.com> <1462136140.5535.219.camel@edumazet-glaptop3.roam.corp.google.com> <1462201620.5535.250.camel@edumazet-glaptop3.roam.corp.google.com> <1462205669.5535.254.camel@edumazet-glaptop3.roam.corp.google.com> <1462464776.13075.18.camel@edumazet-glaptop3.roam.corp.google.com> <1462476207.13075.20.camel@edumazet-glaptop3.roam.corp.google.com> <542135C7-D7CC-4E33-B35B-C2AD259FA5AB@gmx.de> <20160506133323.0b190f47@redhat.com> <1462541156.13075.34.camel@edumazet-glaptop3.roam.corp.google.com> <2BFC725A-F007-4D63-89BD-E1845F7E89BE@gmx.de> <1462550314.13075.51.camel@edumazet-glaptop3.roam.corp.google.com> To: Eric Dumazet X-Mailer: Apple Mail (2.2104) X-Provags-ID: V03:K0:p4IZAtYkINyC3sVtQNgtpVFefkiw54RTgUdFjCRugRVB4y2g5Cj h96BeNIYU5Od0LLJKfk3f0yZECfH0aZXQeMpSXHsniV74M2Xkj3Ewgy50BrtSxC4YaSaLMV JOEzZ7rdFqDJIT3lTAAG8ehMGz3PmQEgeTcqa6pl5h8paSePTukoNjmdzWd6qi9bfym1bvn i3rM6iXbKFIhkIKrnvyPQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:4tZ2dFVTH7A=:s965uy3Lf7nPiFBR3PX5at sRTtum3jxDJMfDeu57e6xEXXBC0bRc0JjOTyVpQTI1yAUMUfSEa5LI4Tfy4OAKW7w6I9d8r/7 HPTDXw28MMV4Ml60gJFRr/QVeToL/5sGF8l1IJrrPhPQdVOjFf/LtLvcI5h8KH5j55fqxaX9K XNnZ44nVb35F9OnptDzARsUXHrnJvzPo43f54kpC2N8zIOrqjvVjOm7F47OMabJOHyoGG0mXi Q0wbpCQvFRkjxofJ2wKCn0N6G1UrlrFxy8S6QMaNvuAPDJBUwjJLIMQF62sy2pGiHIrfpNGHO mV5WFpZX8zV4wAhmsOhk/adfRKHuhXo2wt/c4XNWiALVnywCyp2v69vhULPI21QSdfC8JeRfM UfN/hgxq4BSu+hKJBj6eATJPz7C3MMWBw/eGpMJyRCGRyVUpVIxw5rzadVsQWahcVmmrtzcE6 irfB8ICFsXpZaDpcS6Jyr1qY+UFjQ7+Xh91Hwk7NsN1UtaUtw4DyNS5qtvwtR1/YRVd9SREbb 5dJMwzPkm+HzeQHPgdX3HWucRgqgHV9qBlKu089pD+qNdH49Y2hgSeV28Wb2Y3qLzf1eKwilr YZXH3YIHtlp7Y51WR65oOGFvfC0H96usoQvjw8pKJbDN2EGagiBPnABYz7tTAmIi43TuIwPnh OOjgVr1IAsyVQYc2l1BXQD/+CgIjO4DgxrR0VgvD1wCgPLEwJHK+qbwDU5U7gWPPQNGnId3ST +TZz2UVt8g8iZoKfLINvsXTpUoAsl7it2XfGBYndt+RRBqsMTVyZR1EyzrwPW1xdUuLfWXwvT 46Kp+/GOKXl+gb8t+twb/HxD9IjCw== Subject: Re: [Make-wifi-fast] [Codel] fq_codel_drop vs a udp flood X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 16:30:25 -0000 Hi Eric, > On May 6, 2016, at 17:58 , Eric Dumazet = wrote: >=20 > On Fri, 2016-05-06 at 17:25 +0200, moeller0 wrote: >> Hi Eric, >>=20 >>> On May 6, 2016, at 15:25 , Eric Dumazet = wrote: >=20 >>> Angles of attack : >>>=20 >>> 1) I will provide a per device /sys/class/net/eth0/gro_max_frags so = that >>> we can more easily control amount of segs per GRO packets. It makes >>> sense to have GRO, but not so much allowing it to cook big packets = that >>> might hurt FQ. >>=20 >> This sounds great, so we can teach, say sqm to set this to a >> reasonable value given the (shaped) bandwidth of a given interface. >> Would something like this also make sense/is possible on the send = side >> for GSO/TSO? >=20 > Problem of doing this on the send side, is that too big GRO packets > would need to be segmented _before_ reaching qdisc, and we do not have > such support. (The segmentation happens after qdisc before hitting > device) Ah, so not really possible then. >=20 > In any case, that would be more cpu cycles. It is probably better to > control GRO sizes to optimal values. I guess we can always limit the GRO segments on the internal = ingress interfaces, so that the external egress interface never sees too = =E2=80=9Clong=E2=80=9D (as in required transmission time) = aggregates/super-packets. >=20 > I posted the fq_codel patch to netdev : >=20 > https://patchwork.ozlabs.org/patch/619344/ Saw this, to quote Stimpy =E2=80=9Chappy happy joy joy=E2=80=9D Best Regards Sebastian >=20 >=20