From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 2333621F345 for ; Tue, 24 Nov 2015 02:52:50 -0800 (PST) Received: from hms-beagle.am28.uni-tuebingen.de ([134.2.92.113]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MCcvy-1aAZ8J078M-009OJR; Tue, 24 Nov 2015 11:52:45 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: <56542A13.3010307@darbyshire-bryant.me.uk> Date: Tue, 24 Nov 2015 11:52:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56542A13.3010307@darbyshire-bryant.me.uk> To: Kevin Darbyshire-Bryant X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:77be7mJPCBWi0IRx6wyPCKyblzu6ybikPSwoV0rR9HL26CMGN+/ 9i2M4EvndMVhUY228Up6IX2U3Yy0wE9xme4crIlYM9/NJ4iPzg1aAFbyXiqSB49fHACX0CD kCxKUStavLwX/qr21RaR+Vsm0FQSX7pongeDqWbQHXNGSrc4hT1+tHdZtm7qH8zhvNGE/fV 9DwkSf7Tgsmn/UHpt/S3g== X-UI-Out-Filterresults: notjunk:1;V01:K0:3WPhEjkqAKI=:OAxx3xOWalQ+Z04n6Jww+u iGSfo+Q2YVjnGADvDE1GOh7mnEKTdbjQ3k8jT9+BjpNRHp+DtdXqKwSvm0GhkFZ3jGoeXP0+X ZaOlrkxq/fFVCrgxcWqMOXqW9NFcbdtRwPmRUjwHqtKvu8Q8KSb01UkxhxTQQgxkLFfP5ZOYR dZ8ECaJJHINh1jBVq4AyjbWwxyreMiOFz2hnu3Uo3gzhSd5/7kJqGW7Bc5xCXDJtHfuMSsp/n 7IgYR0u7dVw6IrX8G5PjkGzLg3CfjZYlk39EFB9jgS62uo3OtwQnTCSO7sEz3KKEpuYOzOkvc GjRWxCHHGp9SN0olb50f9X3HvZmj0I+35i/x2bdTLoRwjv3CcInesn6mJayFNHPmGeM/Hpe5G Ib7KKZjzydBzMdOohztNad98Q2+9q9jAQ8SyIXsgcGBsRxC15WF9dcC3WoScouMXCGfdq0AG8 kti6d9yLMiz0j20+43UaRYXKvmXJacvw0Jra/EF5GIuNmEGhTvwae4B5+E/o9I2ZJF6dLtjBv 8lPmvieG5hqPh+kSmYe02hkeutDLkiKPc5qnBdGfluB1mj5QAKxeNNwsXi0ExLx+qrL/Pe7aZ j39nm68Zp3jh3E6QzizPw8gavBoRe3R73CsPNXo/BympCbnjH2Psi//VOPPSiUMzDflldJX33 mu0QpZ0jXyiGJx7FWVFEMfB1+PVFN6gLbDQyRtMcJ0PW4noPtu5zYh/hYdk9y6dwuGpsjmAlE fpqHdjBgmiXKSqh3IBpddl5KugkXF+kcSDxIRPHS/QZ2Q3KP1YIhKJIXfozpv2sCkMom2WnqJ 5a7xfr8 Cc: "cake@lists.bufferbloat.net" Subject: Re: [Cake] GSO peel behaviour tweaks X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 10:53:13 -0000 Hi Kevin, On Nov 24, 2015, at 10:12 , Kevin Darbyshire-Bryant = wrote: > I've just pushed 2 commits related to GSO peeling behaviour to master. >=20 > 1st tweak is at worst benign and at best removes a multiply compare = for > every packet enqueued. I'd like to think the optimiser in the = compiler > would have done what I've done explicitly (in essence check this is a > gso packet 1st before thinking about peeling it) but when I checked on > x86_64 there was a definite difference in produced code. >=20 > 2nd tweak is *not* benign. In essence this forces peeling if either = ATM > framing or packet overhead is specified. Previously only ATM framing > forced peeling. I think this is more correct but unfortunately will = be > slower. Why? Does cake not account all the overhead that the de-composed = aggregate will cause on the wire? If not, it should do that and keep the = decision to peel or not-peel orthogonal, no? Best Regards Sebastian >=20 > Commits can be reverted - feel free :-) >=20 > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake