[Xorp-hackers] rtrmgr and TaskManager

[Ben Greear]

On 10/06/2009 06:55 AM, Bruce Simpson wrote:
> Ben Greear wrote:
>> Well, here's the slow-down I'm seeing..but WTF would someone add a
>> 1-second
>> sleep here???
>
> I don't really have time to delve into the Router Manager specifics
> right now, but I'll share some of what's evident from the XRL
> replacement work.
>
> My guess here is that the Router Manager code is letting the EventLoop
> run so other task(s) can get serviced. At this point in execution, the
> processes are not being started; instead, the XRLs being fired off to
> configure the process during startup, are shimmed.
>
> One reason why this is required, is because XRL is trying to be
> completely asynchronous. There's a fair amount of complexity in XRL, and
> the Router Manager, to deal with the fact that XRL method resolution
> happens on a per-method basis, and is completely asynchronous. The
> EventLoop needs to be run() in order for things to happen, mostly
> because C++ doesn't have continuations.
>
> The lack of a synchronous model for coding to XRL, as an RPC mechanism,
> means that we have some complexity in the 'show_*' tools. These are also
> written in C++, because XRL is tied to C++ as an implementation language.
>
> Any XRLs invoked by the Router Manager come from the template files; the
> *.xrls files are used to validate XRL invocation against the targets.
> These are always XRLs of the form 'finder://' which forces the
> resolution to go via the Finder (an indirect method call using the
> textual Finder protocol).
>
> ...
>
> I'd argue that the Router Manager really needs to be revisited entirely,
> and it has been in the commercial product, although not to the extent
> I'd argue needs doing to make the routing processes useful outside of
> the framework they're embedded in right now, as the code is realized in
> the community branch.
>
> It is purely configuration space stuff, and involves a text parser for a
> configuration language, a configuration tree containing the current
> router config state, and the marshaling/pushing of that state to and
> from the routing processes.
>
> One might argue that it doesn't even need to be written in C++, and an
> object scripting language (e.g. Python, Ruby) would be sufficiently
> mature (and fast) to do what a Router Manager needs to do. All of these
> things could be realized in an OO scripting language.
>
> Of course, we don't really have free time on the board right now to deal
> with this right off the bat. The timer you mention here as an issue
> probably could be speeded up, however a time gap there is probably still
> necessary to let other callbacks run.
>
> I'm wary of wading into it too much before a 1.7-RC is cut, although if
> you find that cutting corners in these areas helps, and doesn't disturb
> functionality, it is something we can consider at that time.

Anything that depends on waiting for other tasks to run by just sleeping
for a while is a broken algorithm, so I'd prefer to see the problems sooner
than later.  From my poking at the code, I can't see any reason it should
need to sleep though...other tasks can run just fine after that one
completes.  If there are others that *must* run first, hopefully they
are properly chained with callbacks (the commit seems to be done thus).
I'm going to run with zero timer there and see if any problems
shake out.  After several hours yesterday, I had seen no problems, but saw significant
speed-up in 'commit' xorpsh commands which is very useful for me.

With regard to re-architecting rtr-mgr:  Networking is asynchronous by design
and considering that external events (interfaces coming & going, link state
bouncing, etc) can happen at any time, the code just needs to deal properly
with async events.  The one thing I'd work towards is more of a 'desired'
v/s 'actual' config.  Users could always configure any logical configuration
and the system will try to make this happen, but it will also deal properly
with 'phantom' things like interfaces that don't exist currently.  A different
programming language isn't going to help any of that I think..and I'd very
much like to keep with c/c++.

Thanks,
Ben

>
> cheers,
> BMS


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com