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.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 02DE03BA8E for ; Wed, 25 Apr 2018 13:54:55 -0400 (EDT) Received: from hms-beagle2.lan ([79.192.243.176]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MfEZG-1f0uE33q6k-00OsjU; Wed, 25 Apr 2018 19:54:54 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Sebastian Moeller In-Reply-To: Date: Wed, 25 Apr 2018 19:54:52 +0200 Cc: Eric Dumazet , Cake List , netdev@vger.kernel.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180425134249.21300-1-toke@toke.dk> <878t9b5n0q.fsf@toke.dk> <6bc11ded-028f-6c8f-964e-a569b4e10813@gmail.com> <8736zj6zj2.fsf@toke.dk> <8bae2ee1-efcc-1571-2a30-5b7779de2c88@gmail.com> To: Jonathan Morton X-Mailer: Apple Mail (2.3445.6.18) X-Provags-ID: V03:K1:q4BAAXVHsY7VcclIh1u52M0dleg1CtnRb9Q///9MuSbqp1CdwUp q6aHEYXfd4LHLg3+k8QuFaPD5GLSLPvKZ7dxcHAnCnEsbmNBObMZRmjPUSwHa0kwCGeA57n yxg4XqWYwCH7SZUAs3QpvscYuxz74cIwTWsCc2oz9WPXIeaK7p7tsC/XStPUEOQPO7cypJG jyDOSY+04EQ5xA8BWBaHA== X-UI-Out-Filterresults: notjunk:1;V01:K0:3KGIRGoj5PU=:K/6RG4plbuEv3i96vcKFel GNq8xusvGZZ4WWVwEBJY2mWilZOFOctlJguo7YN6qVkzcPot/geikJ1+rJOCh3JNxQk8w78Rd +jEOggkTxVXHd4xhNYSNz0i4+8LwgslPqSMDrEi+xbbOQiaMZwJECyl7M/55gF+aBTxr4HnB8 PHYTjhr08LrBbi8Yqi7ax8INC6MzokFeKKq1LNDyA4Ux6lWFXuNmu9GeJd5LgWnf10W5F1nUt yQ0JSKvf37JXJ+NzLwgNwk07kXyw893MRioEut/X/nnVpYNr5cgzedppIqpJx6qHEodX21vW6 +gfdox0IKgfPUD/TCl62yoXNJ3Le0mvrk2M6VQzISf8bZ5/rm9fTEL4WsNoL+gdi1GZNOtXNf urlAKBWCLN5C08xTmpuKQRYi77vfXrR83sxu7HLWGwmTbhGL8r5lLRpeBrB10yqGarZYoxCpp Yv1AsphRdezxytBbCMU9w7Nk9scxlWgeYFUeWC29otx+QhqMNTOrdelgDYhYw7iIauwigUmH5 h+Dw53mSMJgYZIzbBVZX5fnGI8cKdEV0vubxcdxAiCNx5p7GomtQmfUt/mggJggHM0oL3H719 K6SsowFJRvhXoA5L67EEwjClCW3WLDY/yRQRP/1fkhYPxpr+1s/r1D0nj6W1raZTmha1QKLLv /ML7lVSyxK1z/at8taGVgfoc06aHK/MucmeMy2vqpWWWB91Q0fTU7V6dTWBARZZqWDkJpPnsf OyDNYI1k+xfqRPbuGDvft++jr+go4Ube3+ss0Trn8srUuyRRW4pJh5LEjDw2SsNcSrRCATIPa UwMP3VTlKE6ZdY4bR2s9b2uB55aM1qACki/qpRn5S864Ztjcq0= Subject: Re: [Cake] [PATCH net-next v3] Add Common Applications Kept Enhanced (cake) qdisc X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2018 17:54:56 -0000 > On Apr 25, 2018, at 18:52, Jonathan Morton = wrote: >=20 >> We can see here the high cost of forcing software GSO :/ >>=20 >> Really, this should be done only : >> 1) If requested by the admin ( tc .... gso ....) >>=20 >> 2) If packet size is above a threshold. >> The threshold could be set by the admin, and/or based on a fraction = of the bandwidth parameter. >>=20 >> I totally understand why you prefer to segment yourself for < 100 = Mbit links. >>=20 >> But this makes no sense on 10Gbit+ >=20 > It is absolutely necessary, so far as I can see, to segment GSO = superpackets when overhead compensation is selected - as it very often = should be, even on pure Ethernet links. Without that, the calculation = of link occupancy time will be wrong. (The actual transmission time of = an Ethernet frame is rather more than just 14 bytes longer than the = underlying IP packet.) To elaborate a bit: For most link technologies the number of = on-the-wire segments (and the total IP size of the superpacket) would go = a long way, but for ATM with its mandatory per packet padding (to fill = an integer number of ATM cells) one really needs to know the precise = packet size. >=20 > Another reason to apply GSO segmentation is to achieve maximal = smoothness of flow isolation. This should still be achievable within = some tolerance at high link rates, but calculating this tolerance is = complicated by the triple-isolate algorithm. >=20 > If there's a way to obtain the individual packet sizes without = incurring the full segmentation overhead, it may be worth considering = (at high link rates only). I would want to leave it on by default, = because some of Cake's demonstrably superior latency performance depends = on seeing the real packets, not the aggregates, and the overhead only = becomes significant above 100Mbps on weak MIPS CPUs and 1Gbps on vaguely = modern x86 stuff. >=20 > - Jonathan Morton >=20 > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake