From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 4D1A421F3DC for ; Thu, 14 May 2015 06:12:24 -0700 (PDT) Received: by laat2 with SMTP id t2so66852230laa.1 for ; Thu, 14 May 2015 06:12:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=aZNa3tp4nqlDFLrxvqbQ8P1gNBzkkodE678EWTRnkYI=; b=SmL8qkI540asCHoeFPnFwjdF/yThH2pDjf9e9sGbG4lBKLhi8jMBH5v8nWFaWawize qjKgsx90Wdqbfzddc3Yqnqxb5hWWXCSy+TVyN/x3DIQRCMlCN9nk++ML0V6pLM1052S0 0kExLMta6o3bSzT7o5RUQuE1vU8tMIXZddY5squGNvKFzaWn+DGetGBlRjRiFZfjhhTJ sKPng5tfhoOMQX32z6BOK0oom8ZXlbzU0muzzCx4nyRBMtRL2Z2n9uiqMfrhBh4udRmB MBoI0sckUEsGnPBAObTukDJSG2Vt1gziIQUDZBC45l9x0V7/6bUzTX3jP49UjPqMvFm5 jxjQ== X-Received: by 10.112.211.167 with SMTP id nd7mr3190874lbc.62.1431609142821; Thu, 14 May 2015 06:12:22 -0700 (PDT) Received: from bass.home.chromatix.fi (87-95-105-63.bb.dnainternet.fi. [87.95.105.63]) by mx.google.com with ESMTPSA id sh6sm6126189lbb.31.2015.05.14.06.12.18 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 May 2015 06:12:21 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Jonathan Morton In-Reply-To: Date: Thu, 14 May 2015 16:12:06 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <38FFDA3C-2F67-4831-B316-DF8CC7EF0167@gmail.com> References: <554F64E1.6000609@gmail.com> <554F9594.60808@gmail.com> <50DB1E31-61AE-4298-B80F-8C6F7487C99B@gmail.com> <002A5BFC-5511-4995-8785-370251F24083@gmx.de> To: Sebastian Moeller X-Mailer: Apple Mail (2.2098) 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 13:12:53 -0000 > 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. 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. But beyond that, it can be conditional. I propose that peeling be done = if either: 1) the ATM flag is set, or 2) the aggregate would occupy more than 1ms on the wire (at the shaped = rate). 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. 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. - Jonathan Morton