[Xorp-hackers] xorp-ospf performance issues: busy-spins & packet floods.
greearb at candelatech.com
Sat Oct 20 19:53:52 PDT 2007
Ben Greear 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
The attached patch still lets ospf busy-spin, but at least now it's
spinning doing reads and
writes of some SCTP payload instead of just spinning w/out obviously
It should get rid of several time calls and some static global variables
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2759 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20071020/bac14d00/attachment.bin
More information about the Xorp-hackers