From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (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 B61D23BA8E for ; Sat, 6 Jan 2018 19:33:35 -0500 (EST) Received: by mail-lf0-x231.google.com with SMTP id u84so8702533lff.7 for ; Sat, 06 Jan 2018 16:33:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=n9rHfAhxe0/liDqudyJnlPgUGU710h/W+xlz5WA3su4=; b=fedTuXKH9SxDqsHF5NkrQYZLZrZIpRXj5dM01pPflVnu7RcDPqemTXlg4u9ae63SJG 951xn67CzXT3H6paZNWW3CIqSZtS3BrlE0qDA5IjEqpEDLu43m+RHUH1+pyIaxfHG8pK RDw9ew5OXXh3XZBtvm+aNAQUQP4NeiRPZwXXYjd/Zm08zvgZAcWUcJJjWVStERT9o3mO ocQWBCiZWWyRIc6XQ4ENMelmirVvBl87FSpHyOpewGQoT8NfXXCETaVhZluK7k41+qbk IJfhxyjbuZDo/Yucs4prz7mZPucic85Y0M+86tFf6psevFmnhIIvdFIUb3ibedgao8nG Po3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=n9rHfAhxe0/liDqudyJnlPgUGU710h/W+xlz5WA3su4=; b=dkpai6PCs3sApQPNRfzpLOdlyi48ZFxIZSxVgvk9dHn9kDFjYdPmNg5n/udqoTmFdL k/fdbPSUpNq9sWEf//JOSGvh8880ng+KqnSW7/rBcTp3OtBx9MMaKX8ZVbihy7V5YpgC 86ZkIrBnj/SXlMkw92osYufkvOM9XDcyTEYOgTmOdEadyZJW/zfehaeWisdmu1OctITR mzU6D322ufGgf36EL9Awrhzh3AYZOx9wBIm1yq8Lk88A50/iBd+HLe+GK1W3saUKn4/v AzpDXhu8MO6SJz1KmLHgxEY03s9zsGTEFyraxEevGqo46aSVnxbgpVkBXgILpwQRDFQv M7sA== X-Gm-Message-State: AKGB3mJGCrS5xoL4cbAq2dRBVGFemI0VZlMcF/V14IF2ch/fpsXOeWo/ 8ua5B4UG/52Kj0gm6EapF2g= X-Google-Smtp-Source: ACJfBotwWXkH/mdLZOWMNx/kK5DLyPez6b5yTJljHeoyoYfTjTom0f74bm3KQTzMOIsyR+6Yrk0Jjg== X-Received: by 10.46.67.147 with SMTP id z19mr3851832lje.49.1515285214506; Sat, 06 Jan 2018 16:33:34 -0800 (PST) Received: from [192.168.239.216] (mobile-access-bceee7-52.dhcp.inet.fi. [188.238.231.52]) by smtp.gmail.com with ESMTPSA id v6sm1401057ljc.19.2018.01.06.16.33.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 06 Jan 2018 16:33:33 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Jonathan Morton In-Reply-To: Date: Sun, 7 Jan 2018 02:33:31 +0200 Cc: Ryan Mounce , Cake List Content-Transfer-Encoding: quoted-printable Message-Id: <202188C4-062D-430B-838B-EAFEDB394002@gmail.com> References: <31d49a5d-02a2-3dc8-a455-52d453b83bdf@gmail.com> <3b255661-1b16-cc29-958f-bbbedbcbab9e@gmail.com> <8FB76CCB-1AAB-42F6-AEF8-D0D8A438EA91@gmx.de> <7ca86dce-7645-38e8-df4e-148245e9991c@gmail.com> <3B4D3F22-DA08-4A8A-A1E2-C31A2B627727@gmx.de> <7416D2DC-A95B-40EA-B7AB-000BF9D113F8@gmx.de> To: Sebastian Moeller X-Mailer: Apple Mail (2.3445.5.20) Subject: Re: [Cake] overheads or rate calculation changed? 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: Sun, 07 Jan 2018 00:33:36 -0000 > On 7 Jan, 2018, at 12:46 am, Sebastian Moeller = wrote: >=20 > I thibk cake should offer a mode in which it behaves as all other = qdiscs currently do and not do auto correction at all and a mode where = it corrects for the right amount, but keeping the current ake cbehavior = will not help anybody.... but most likely i misunderstood your proposal = in that regard. Let me explain a little more clearly, using your example: Here "by default" means with no overhead keywords used at all. = Currently, Cake does nothing with the packet lengths by default, acting = as though "raw" was specified. Instead, Cake will act as though "overhead 26" were specified on egress = and "overhead 14" on ingress in your case. Unlike its current = behaviour, it will recognise that it's actually getting raw IP packets, = and won't first attempt to subtract a non-existent header from them. = That's still different from tc-stab behaviour, but probably more useful. Conversely, with a typical Ethernet interface, it will act as though = "overhead 14" were specified on both egress and ingress, and will = effectively leave the packet length alone, recognising that there is in = fact an Ethernet frame header on the front of the packets handed in. If you then specify "overhead 34", you'll get exactly that, relative to = the transport-layer packet (that is, IP). You'll get visibility into this behaviour through the output of the = current configuration, which will include an overhead keyword. And all = this assumes that skb_network_offset(skb) *actually* does what I think = it does. What I'm not sure about yet is whether to keep "raw" and "via-ethernet" = with their current meanings - as that would probably have a (small) = runtime overhead as well as requiring more serious thought into how to = organise the configuration interface. Otherwise, I do intend to keep = "raw" as a way to reset to the default configuration. - Jonathan Morton