Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: Jonathan Morton <chromatix99@gmail.com>
To: Dave Taht <dave.taht@gmail.com>
Cc: cake@lists.bufferbloat.net
Subject: Re: [Cake] tail drop on complete overload
Date: Mon, 13 Apr 2015 02:42:52 +0300	[thread overview]
Message-ID: <548E5D50-943F-46F2-BF7C-BB25E704B1D6@gmail.com> (raw)
In-Reply-To: <CAA93jw7HDGZZMQriWiJvTkLvMYQYE9ZHUJQh-pWtgDn3dg2ehA@mail.gmail.com>


> On 13 Apr, 2015, at 01:16, Dave Taht <dave.taht@gmail.com> wrote:
> 
> The full flow space search on complete overload is terribly expensive,
> moreover it is not deterministic, and touches a lot of cache.

I would be interested to see if anyone can actually trigger this in practice.  It’s a slow-path function, which I assume would be rarely called - only when the queue is physically full.  By then, the overload mechanisms would already be in operation, dropping packets instead of marking them.  So it’s probably quite a lot easier to trigger it using a local sender than an external one - and if you *can* trigger it externally, then you’ve probably got enough CPU headroom to deal with it the right way.

Also, I don’t think it’s quite as expensive as you think.  Note that instead of iterating over the lists of flows, it iterates over the array of flow *backlog* counters in each class.  In the default configuration, that’s four 4KB arrays, accessed in ascending linear order (which on most practical memory architectures is the optimal pattern).  This is simply to pinpoint the longest queue, which I believe is desirable behaviour.

I don’t see how it can be non-deterministic.

The actual drop is as efficient as it can be.  Tail-drop would be *more* efficient, sure, since it just involves an early error return in enqueue(), but has its own behavioural risks.

It may be feasible - and in hardware would probably be easy - to keep track of the identity of the longest queue opportunistically.  This would reduce the cost of identifying that queue when it is necessary to do so, at the cost of a little extra overhead on processing every packet.  Is that worth it?

 - Jonathan Morton


  reply	other threads:[~2015-04-12 23:43 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-12 22:16 Dave Taht
2015-04-12 23:42 ` Jonathan Morton [this message]
2015-04-13 15:50   ` Dave Taht

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=548E5D50-943F-46F2-BF7C-BB25E704B1D6@gmail.com \
    --to=chromatix99@gmail.com \
    --cc=cake@lists.bufferbloat.net \
    --cc=dave.taht@gmail.com \
    /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