From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (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 AC7783BA8E for ; Sat, 6 Jan 2018 15:44:30 -0500 (EST) Received: by mail-lf0-x22a.google.com with SMTP id g63so8408130lfl.11 for ; Sat, 06 Jan 2018 12:44:30 -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=iVeO25UXlSb8lnjysv1Zfq3TEJZJRMruk7P5cjj3DO0=; b=WyElRarSdJlcaabTfXSUfoD6m8A5ZeNm6fNQiQ8JRtFiV41onHCBBNKbJWeeiw5/lG jWJ16gte6HBGiFXjRxfvUy0pVRk2FegHpLe2j/bDZw6VbCvnLGz0erde1olTgatWnhZr YgYhHV6yW5VN7sX36rGAdwSPbhG4D1TosFsF068mAGQx3xRAaLjzK8k/QUNj/9TUZ6Jz bPAKH4QVPMRDKUaLdnPWRPI4FYCG7d72lZAdZqL/bS6dwe2WM+YjEv9RI0JO3JaHPHZY fB22UKc4UK8XlBvud/S9glYnUUH0kTPKrz+6v5J0nvH9Yj+UpVvnTepAiSxfXn6PAaVf RMOQ== 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=iVeO25UXlSb8lnjysv1Zfq3TEJZJRMruk7P5cjj3DO0=; b=JwM15WhNn/sYX+UofiZMDsyxwR+0oCW5e5WOamP95H/dFBNjmm5ZlAbpHcWEQBurDH Yo7jf/ohXl8Pi11XcWb92C1TmHCs3Veg2cZC0M3nyv/lJDrQHlz9SlV5H6gbA2bef2U5 0fFLoyLVjtrOU9vcOhvDGC5t9uEn+7gm57Va8obBDR37T7sYOGnSNFCIeNDMXdXyYngN vbnDIGqoBYY692nAKnPvDtSNgYZwpm6cWIh195PJ2z941vBMjdlkbCqvLqzxnUqs6Mo+ EtLYE1fzEXMpP/COTLcWim8X9x68ASYEB5/wKGwSV+9izr18HHz5sVPrkcUZy2jmgQVA 27Ww== X-Gm-Message-State: AKwxyteFkZ6WcB0xfluQGpTMD0zZyIfPT/LQpY9x2tStNjneB+oyHO4M UWf5ccqcEToCTc1UPyVOkh4= X-Google-Smtp-Source: ACJfBovjre63EciNYEYIKIrWmUsuVcriY+eOPmtZL5iaMlsX833kbnBiwICaktYLt+stF+zBPjY00g== X-Received: by 10.25.44.206 with SMTP id s197mr3281170lfs.15.1515271469493; Sat, 06 Jan 2018 12:44:29 -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 b84sm1551702ljf.60.2018.01.06.12.44.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 06 Jan 2018 12:44:28 -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: <7416D2DC-A95B-40EA-B7AB-000BF9D113F8@gmx.de> Date: Sat, 6 Jan 2018 22:44:23 +0200 Cc: Ryan Mounce , Cake List Content-Transfer-Encoding: quoted-printable Message-Id: 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: Sat, 06 Jan 2018 20:44:30 -0000 > On 23 Dec, 2017, at 11:03 pm, Sebastian Moeller = wrote: >=20 > just had a look for hard_header_len in the linux kernel: > linux/include/linux/netdevice.h: > * @hard_header_len: Maximum hardware header length. > * @min_header_len: Minimum hardware header length >=20 > this seems to corroborate our observation that hard_header_len is not = a veridical representation of the actual hardware header length, so I = assume the values cake returns are actually true. It also indicates that = except for pure ethernet interfaces hard_header_len is _not_ the right = parameter to evaluate for what cake is evaluating it for... Turns out min_header_len is always either zero or 14, and is scarcely = used anywhere. It seems to be completely ignored by non-Ethernet = interfaces. However, it appears that the correct value is stored implicitly in each = skb, and can be obtained through skb_network_offset(skb) - that's the = offset from the beginning of the packet to the IP header (assuming it's = an IP packet). This suggests to me that the via-ethernet keyword can be = retired, in favour of unconditionally subtracting that value from each = packet length before applying overhead compensation, and setting the = *default* overhead compensation to hard_header_len (to emulate the = current default behaviour). What we would lose that way is the present capability to add an overhead = to the raw packet length as reported by Linux. However, since that = doesn't reliably correspond to an actual packet length on the wire, = that's not really a useful capability to keep, except for direct = comparison with other overhead compensation methods. Comments? - Jonathan Morton