Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: Jonathan Morton <chromatix99@gmail.com>
To: Sebastian Moeller <moeller0@gmx.de>
Cc: Ryan Mounce <ryan@mounce.com.au>, Cake List <Cake@lists.bufferbloat.net>
Subject: Re: [Cake] overheads or rate calculation changed?
Date: Sat, 6 Jan 2018 22:44:23 +0200	[thread overview]
Message-ID: <AAF010A5-087C-4568-836A-0AC7EC942076@gmail.com> (raw)
In-Reply-To: <7416D2DC-A95B-40EA-B7AB-000BF9D113F8@gmx.de>

> On 23 Dec, 2017, at 11:03 pm, Sebastian Moeller <moeller0@gmx.de> wrote:
> 
> 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
> 
> 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


  parent reply	other threads:[~2018-01-06 20:44 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-18 20:32 Andy Furniss
2017-12-21  0:54 ` Andy Furniss
2017-12-22  6:38   ` Jonathan Morton
2017-12-22  7:58     ` Kevin Darbyshire-Bryant
     [not found]       ` <CAJq5cE3e-CbJ8X_Bpu3AhwbVmq-yD89HGe7rSNMTYqj+KSaBUg@mail.gmail.com>
2017-12-22 10:00         ` Jonathan Morton
2017-12-22 12:58           ` Kevin Darbyshire-Bryant
2017-12-22 15:55     ` Dave Taht
2017-12-22 23:38     ` Andy Furniss
2017-12-23  9:41       ` Sebastian Moeller
2017-12-23  9:59         ` Andy Furniss
2017-12-23 12:55           ` Sebastian Moeller
2017-12-23 13:11             ` Ryan Mounce
2017-12-23 14:21               ` Sebastian Moeller
2017-12-23 21:03                 ` Sebastian Moeller
2017-12-23 21:20                   ` Jonathan Morton
2017-12-24 10:34                   ` Kevin Darbyshire-Bryant
2017-12-24 10:39                     ` Jonathan Morton
2017-12-24 10:46                       ` Kevin Darbyshire-Bryant
2017-12-24 12:19                         ` Sebastian Moeller
2017-12-24 12:14                     ` Sebastian Moeller
2018-01-06 20:44                   ` Jonathan Morton [this message]
2018-01-06 22:46                     ` Sebastian Moeller
2018-01-07  0:33                       ` Jonathan Morton
2018-01-07  8:19                         ` Sebastian Moeller
2018-01-07 15:21                           ` Jonathan Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/cake.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AAF010A5-087C-4568-836A-0AC7EC942076@gmail.com \
    --to=chromatix99@gmail.com \
    --cc=Cake@lists.bufferbloat.net \
    --cc=moeller0@gmx.de \
    --cc=ryan@mounce.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox