[Cake] cake at 60gbit

[Toke Høiland-Jørgensen]

Pete Heist <pete at heistp.net> writes:

>> 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 thought about overflows, but I don't get any "weird" values, and
everything ends up back at zero when the flows stop. And it's not
actually tin_backlog that's causing the looping...

> - I’m assuming sparse_flow_count + bulk_flow_count wouldn’t be 0…

Yeah, they are; that's why it keeps looping. I've been looking at both
tin_backlog and the *_flow_count vars as different ways of checking
whether the tins are actually empty... they are all 0 when this happens.

-Toke