[Cake] cake at 60gbit

[Pete Heist]

> On Jul 6, 2018, at 12:31 AM, Toke Høiland-Jørgensen <toke at toke.dk> wrote:
> 
> I suspected that cake_dequeue() was looping forever, so I added some
> debug statements to investigate this; and turns out I was right. Using
> the debug patch below, in unlimited mode I get loop aborts on loop 'i'
> for unlimited mode and loop 'l' if I enable the shaper at 70 gbit. It
> happens pretty reliably, but only when I load up the link sufficiently
> (need 4-6 TCP flows which get ~50 Gbps of total throughput).
> 
> The weird thing is that what appears to be happening, is that cake
> somehow gets into a state where sch->q.qlen is >0 while all tin backlogs
> are 0. I have no clue how this happens; as far as I can tell, all
> changes to tin_backlog are paired with a change to q.qlen. The only
> thing outside of cake itself that modifies q.qlen is peek(), which is
> not being used here.

I’m not sure I’ll be much help, but here are the thoughts I start having with loop ‘i’:

- is tin_deficit overflowing at these rates? at 50gbit, 2^31-1 bytes happen in 344 ms (involuntary chuckle)
- what’s the value of tin_quantum_band here? but I suspect it’s ok.
- I’m assuming sparse_flow_count + bulk_flow_count wouldn’t be 0…

Dave’s point about the possibility of 0 length packets could also get sch->q.qlen and tin_backlog out of sync.

I’ll still look at loop ‘l’, but it starting with while(1) does open a door of sorts… ;)