Re: [Ecn-sane] FQ in the core

[Mikael Abrahamsson <swmike@swm.pp.se>]

On Mon, 25 Mar 2019, Dave Taht wrote:

> 4) The biggest cpu overhead for any of this stuff is per-tenant (in
> the dc) or per customer shaping. This benefits a lot from a hardware

Agreed, I'd say typical deployment will allow to have 4-8 queues per 
tenant. If you need to shape customers then you need per-customer queue, 
and typically these linecards will have enough queues to do 4-8 per 
customer.

This rules out FQ, but it does allow to do things like WRED/PIE or 
something else on these few queues. So if we can skip bringing FQ back 
into the discussion all the time, I agree we can have a productive path 
forward that might actually have a good possibility to go into hardware.

A lot of deployments I've seen does bidirectional shaping in the "BNG", 
which will have one of these linecards with 128k queues per 10G port. ISPs 
will put many thousands of customers on this kind of port. There is no 
flow identification machinery to put things into queues, but it can 
probably match on bits in the header to put traffic into different queues.

So this is where PIE and L4S comes from (I imagine), it's coming from the 
side of "what can we do in this kind of hw". So who do we know who knows 
more about ASIC/NPU design who can help us with that?

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se