[Xorp-hackers] xorp-ospf performance issues: busy-spins & packet floods.
pavlin at icir.org
Sat Oct 20 20:02:07 PDT 2007
Ben Greear <greearb at candelatech.com> wrote:
> Pavlin Radoslavov wrote:
> > See SelectorList::get_ready_priority() inside libxorp/selector.cc
> > for example.
> > It is used to find the best priority of a file descriptor that is
> > ready.
> What do you think about having the run() method execute the timer(s),
> then tasks, then the selector. I'd run the selector last since it can
> We can get rid of the get_ready_priority() all together that way. If you
> really wanted to not handle all of the available fds at once (ie, allow low
> priorities to be skipped), then we could just not process all of them.
> I can't
> think of a good reason to do that, however.
> Then, we have only one call to select(), as well as making sure that each
> of the run-queues (timers, tasks, selectors) gets some time to run. I
> am suspicious
> that the loop I see in ospf has to do with an endless timer loop where
> the ospf
> code keeps trying to fire timers but never reads/writes the sockets. I
> also assume
> that if it could actually process the sockets, it's timers would be
> satisfied and quit
> re-arming themselves. This is idle conjecture at this time, but it
> would fit the
> strace log I saw...
The problem should be approached by deciding first what kind of
semantics do we want from the eventloop.
Mark Handley will be a better person to query about the current set of
semantics (tasks, priority, etc), because he introduced and
implemented them so he can provide the insights and reasonings
behind various choices.
> I think I can code this up and test it out if it's something you'd
> consider merging.
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc http://www.candelatech.com
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
More information about the Xorp-hackers