From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 EF57F21F3E0 for ; Thu, 14 May 2015 11:16:05 -0700 (PDT) Received: from hms-beagle-5.home.lan ([217.247.216.138]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MLujU-1YpgPa1SFI-007kLz; Thu, 14 May 2015 20:15:58 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: <444770E9-51C0-4935-8E00-5008CDB388E5@gmail.com> Date: Thu, 14 May 2015 20:15:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <554F64E1.6000609@gmail.com> <554F9594.60808@gmail.com> <50DB1E31-61AE-4298-B80F-8C6F7487C99B@gmail.com> <002A5BFC-5511-4995-8785-370251F24083@gmx.de> <38FFDA3C-2F67-4831-B316-DF8CC7EF0167@gmail.com> <664C6B9D-67C2-4614-A9B0-140D3BEEA4AD@gmx.de> <444770E9-51C0-4935-8E00-5008CDB388E5@gmail.com> To: Jonathan Morton X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:zN4XJJndgryfT0nQ/FB0c9HAJHbqjovg27S1e4GUBfX0iQ2+l0e p1p/RBd4AbGYywq975xfsqnf3x/vDCPyUgpABjEEYN0SccRgIFfrBSr9HcwbqlZHzzMR3pD rMEFTvmlSqVLm+ZOvmWyDo+q1hfohYZUSQjk9Qt0wsEXteoOMjEZpWU5IlHdOpCjNjyCVCN wJlO8QUgY2C+Qr6xj1MQw== X-UI-Out-Filterresults: notjunk:1; Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] openwrt build with latest cake and other qdiscs 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: Thu, 14 May 2015 18:16:41 -0000 Hi Jonathan, On May 14, 2015, at 17:32 , Jonathan Morton = wrote: >=20 >> On 14 May, 2015, at 17:57, Sebastian Moeller wrote: >>=20 >> I am probably daft, but looking at the comment in front of = skb_gso_network_seglen() (see = http://lxr.free-electrons.com/ident?i=3Dskb_gso_network_seglen ) makes = me thick there is a way of getting the lengths of the individual = segments of a GSO aggregate >=20 > All the segments (except possibly the last) will be MTU sized, I = suspect. The necessary headers would be duplicated, with fresh = (sequential) IP IDs, adjusted TCP sequence numbers and recalculated = checksums. The size of the last segment (and maybe the number of = segments) would depend on the header size, since a bigger header (due = eg. to TCP timestamps) reduces the payload per packet. As I said, I am out of my league here ;), I would not be amazed = if there was a way to get to the segment lengths without going to the = data (as I believe the GSO header has all the information to pick the = individual payloads out of the continuous GSO skb, but I lack the skill = to find the correct reference) >=20 > I don=92t immediately see how to reliably calculate the sizes of the = resulting packets. So I=92d rather split them up and be certain about = it, in the cases where it matters most, and take the size of the = aggregate as sufficiently reliable in other cases. I guess your idea of peeling for ATM carrier and for >1ms wire = time aggregates sounds like a decent idea=85 Best Regards Sebastian >=20 > - Jonathan Morton >=20