Looks good to me, just some nits.
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".
> + 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 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.
Ethan
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
