From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by huchra.bufferbloat.net (Postfix) with ESMTP id 3ECA921F3E1 for ; Thu, 14 May 2015 07:58:12 -0700 (PDT) Received: from hms-beagle-5.home.lan ([217.247.216.138]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LjaEi-1ZUBCm2lr6-00bfcP; Thu, 14 May 2015 16:57:48 +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: <38FFDA3C-2F67-4831-B316-DF8CC7EF0167@gmail.com> Date: Thu, 14 May 2015 16:57:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <664C6B9D-67C2-4614-A9B0-140D3BEEA4AD@gmx.de> 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> To: Jonathan Morton X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:CQvCsNmGHdXWxVudviVhABIYx4aAH0U6jGZ2rtnyXJtSrg78mcq lvS5zDoBHQmy9+yn3l/CUCsTN52Z1as5xbOda2WkuylFDyQaW/KdEP3gCU78yRfpNmDfVB8 JJfqmo7HGiVnBL+D1fx3cxYP2pWo1A7FHCS044aduUjM8XsD0gr2n4byCT3Lgg7HZ0RjCnx EdMX19FOd9a5PBDDhbw4A== 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 14:58:54 -0000 Hi Jonathan, On May 14, 2015, at 15:12 , Jonathan Morton = wrote: >=20 >> On 14 May, 2015, at 13:58, Sebastian Moeller wrote: >>=20 >>> Peeling is on the agenda; that=92ll make sure we are dealing with = actual, individual packets when we need to. =20 >>=20 >> I agree, that sounds conceptually much cleaner, but peeling is going = to be costlier than pushing the segmentation to the NIC, so bandwidth = aficionados will not appreciate unconditional peeling, I would guess. >>=20 >>> Certainly when dealing with cell-framing overhead, we *always* need = to know individual packet sizes. >>=20 >> Well that or the sum for an aggregate as long as the sum takes all = fancy =93celling=94 into account, all we really need to know to how many = bits the data expands on the wire. >=20 > Since GRO and GSO are for Ethernet and thus *don=92t* take = cell-framing overhead into account, I really do have to break them up = for that purpose if no other. 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, and I assume one just adds the overhead to = each and does the atm cell adjustments if need be, no need to touch the = actual data or actually peel the geo. Then again I have not really = followed the code and could easily be out to lunch. But sure peeling = will be better fairness wise. >=20 > But beyond that, it can be conditional. I propose that peeling be = done if either: >=20 > 1) the ATM flag is set, or >=20 > 2) the aggregate would occupy more than 1ms on the wire (at the shaped = rate). Oh, I like where you going with this a lot! >=20 > This would imply that pairs of 1500-byte packets would be separated at = shaping rates up to 24Mbps, but smaller aggregates of smaller packets = could still pass unhindered. Conveniently, 24Mbps is also the ADSL cap, = although since that=92s the downstream rate, it=92s not quite so = relevant. Upstream the limit is more like 2.8Mbps (for AnnexJ) >=20 > Incidentally, GSO also interferes with my proposed ELR signalling, in = a way that it doesn=92t with ordinary ECN. ELR needs to consider = packets individually in order to apply the correct signalling pattern to = them. However, if the NIC did the signalling, that wouldn=92t be an = objection. Interesting thoughts. Best Regards Sebastian >=20 > - Jonathan Morton >=20