Re: [Cake] Lockup at high speeds

["Toke Høiland-Jørgensen" <toke@toke.dk>]

Jonathan Morton <chromatix99@gmail.com> writes:

>> On 1 Jun, 2018, at 10:23 pm, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>> 
>> Happens in unlimited mode and when the shaper is set to 60gbps, but not when it is set to 40gbps.
>
> Observations:
>
>  - The shaper converts a rate in B/s into a time-per-byte value stored
>  in floating-point - cake_set_rate(). It is plausible that such a
>  conversion becomes faulty when exposed to especially large values.

Yeah. When changing the rate to a 64-bit value I changed the shifts in
cake_set_rate() to the maximum possible to try to mitigate this...

>  - 40Gbps is 5.0 GB/s, 0.2000 ns/B.  60Gbps is 7.5 GB/s, 0.1333 ns/B.
>  No obvious power-of-two threshold is crossed; both are between 0.25
>  and 0.125 ns/B, require 40 bits to store as bps and 33 as B/s.
>
>  - In unlimited mode, the time-per-byte should be zero and the shaper
>  should therefore always pass traffic without advancing, but
>  time_next_packet will be continually reset to the latest delivery
>  time.

Right. I was wondering if there was some way we could end up looping
through cake_dequeue() forever if the shaper is not limiting things;
there is both a while(1) and a couple of 'goto begin's in there. I guess
if the sparse/bulk flow counts or sch->q.len accounting got messed up we
might? But that shouldn't happen, should it?

> What happens if a watchdog timer is set for a time that has already
> elapsed?

As far as I can tell from tracing through those functions, that just
ends up inserting a timer value into an rbtree. So I don't think that in
itself can cause bad things to happen...

-Toke