[Cake] Lockup at high speeds
toke at toke.dk
Fri Jun 1 15:58:02 EDT 2018
Jonathan Morton <chromatix99 at gmail.com> writes:
>> On 1 Jun, 2018, at 10:23 pm, Toke Høiland-Jørgensen <toke at toke.dk> wrote:
>> Happens in unlimited mode and when the shaper is set to 60gbps, but not when it is set to 40gbps.
> - 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
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
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...
More information about the Cake