Re: [Cerowrt-devel] Ubiquiti QOS

[Dave Taht <dave.taht@gmail.com>]

On Thu, May 29, 2014 at 4:40 PM, Michael Richardson <mcr@sandelman.ca> wrote:
>
> David P. Reed <dpreed@reed.com> wrote:
>     > ECN-style signaling has the right properties ... just like TTL it can
>     > provide
>
> How would you send these signals?
>
>     > A Bloom style filter can remember flow statistics for both of these local
>     > policies. A great use for the memory no longer misapplied to
>     > buffering....
>
> Well.
>
> On the higher speed dataflow equipment, the buffer is general purpose memory,
> so reuse like this is particularly possible.
>
> On routers built around general purpose architectures, the limiting factor
> in performance is often memory throughput; adding memory rarely increases
> total throughput.   Packet I/O is generally quiet sequential and so makes
> good use of wide memory data paths and multiple accesses per address cycle.
> Updating of tables such as Bloom filter or any other hash has a big impact
> due to the RMW and random access nature.

In hardware using a parallel memory layout makes sense.

I had always envisioned the per flow fq_codel table to be on a lookaside cache,
much like how mac and route lookups happen today in hw. In a general purpose
architecture with fat amounts of cache (like ivy bridge) you can set aside
some main cache if you like.

It needent be big (64k for 1024 flows but you can shrink the structure some
if you want) - and it needent be fast, just fast enough to be accessed on
a per packet basis.

There are other ways to do it of course. you could set it up as 1024 8
32 bit register register banks, for example, in the asic or fpga, and eliminate
the concept of using ram for it entirely.

This is not a lot of gates  (quite a lot when you consider the invsqrt
dependency
in codel alone is 3k gates or so - or "free" in a FPGA with dsp multipliers)

I've never thought that pure "drop head" was possible in high speed hardware
- the various operations need to be pipelined, the timestamp needs to go
at the head of the packet for codel to operate on them, etc, etc...

> All I'm saying is that quantity of memory is seldom the problem, but access
> to it, is.

Concur. I keep hoping my parallela arrives. You can write your own ethernet
device with that...

> I do like the entire idea; it seems that it has to be implemented at the
> places where the flow converge, which is often in the DSL line card, or
> CTMS...

The elephant in the room on those devices is the per user rate shaper.
In software this
accounts for 95% of the cpu time and scheduling headaches, and that's without
dealing with ipv6 pools.

> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        | network architect  [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel



-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article