Thanks Ethan for the review,
In the commit message "iterated" => "iterated over". "adds a hugh" =>
> "adds a huge". "uses heap" => "uses a heap". "of monitored port" =>
> "of monitored ports". "ports that are timeout" => "ports that have
> timed out".
>
>
I'll fix these. Thanks,
> > + heap_change(&monitor_heap, &mport->heap_node, LLONG_MAX);
> > + /* If the earliest next wake up time is more than 100ms later,
> > + * wake up the monitor thread immediately. This is to avoid
> > + * waking up the monitor thread too frequently during batch
> > + * reconfiguration. */
> > + if (LLONG_MAX - heap_max(&monitor_heap)->priority
> > + - time_msec() > 100) {
> > + seq_change(monitor_seq);
> > + }
>
> I'd be inclined to just always do a seq_change() here for simplicity.
> Have you actually measured a difference when configuring large numbers
> of sessions? Even if so, does it really matter if we eat up a bit of
> CPU on boot?
>
I think this depends on how many bfd/cfm sessions are there.
For less than 1000 bfd/cfm sessions, I think the difference is not big.
But if more than that, it took more time. I'll do more experiments and
update with you later tmr.
> I think the code would be more readable of we had a macro which
> converted a time to a heap priority in the monitor file. It'd make it
> harder to forget a LLONG_MIN subtraction. I don't feel strongly about
> it though.
>
Thanks for the suggestion, I should do it.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
