Latest cobalt updates

[George Amanakis]

To answer my own question: I think there is a reason for not doing so. If cake_enqueue() gets called there is a packet we need to dequeue later on. So it wouldn't be wise to schedule the watchdog blindly at "now+q->tins[i].cparams.target" even though the scheduler's queue is still empty at that point. 

 
>On Sunday, September 17, 2017, 10:34:31 AM EDT, George Amanakis <g_amanakis at yahoo.com> wrote: 
>Dear Jonathan,
>I am looking/testing the latest cobalt updates.Most of them make sense. 
>I have a question though.
>At the end of cake_dequeue() you schedule the watchdog at 
>"now+q->tins[i].cparams.target" if "!sch->q.qlen". This seems very 
>reasonable. Instead in the beginning of cake_enqueue() you do:
>
> 916                 if (!sch->q.qlen) {
> 917                         if (q->time_next_packet < now) {
> 918                                 q->time_next_packet = now;
> 919                         } else if (q->time_next_packet > now) {
> 920                                 sch->qstats.overlimits++;
> 921 #if LINUX_VERSION_CODE < KERNEL_VERSION(4, 8, 0)
> 922 codel_watchdog_schedule_ns(&q->watchdog, q->time_next_packet, true);
> 923 #else
> 924 qdisc_watchdog_schedule_ns(&q->watchdog, q->time_next_packet);
> 925 #endif
> 926                         }
> 927                 }
> 928         }
>
>Is there any reason why you haven't scheduled the watchdog at 
>"now+q->tins[i].cparams.target" like in cake_dequeue()?
>
>Thank you,
>George

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20170918/db8f4cc6/attachment.html>