[Xorp-hackers] xorp-ospf performance issues: busy-spins & packet floods.

Ben Greear greearb at candelatech.com
Sat Oct 20 16:55:17 PDT 2007

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...

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

More information about the Xorp-hackers mailing list