[Xorp-hackers] PATCH: Add startup methods for faster startup.

Ben Greear greearb at candelatech.com
Tue Oct 6 09:51:25 PDT 2009


On 10/06/2009 04:50 AM, Bruce Simpson wrote:
> Ben Greear wrote:
>> If there is no status and no startup method in a xorp target, the
>> router-mgr uses a 2-second
>> sleep for 'verification'. This slows down startup of Xorp quite a bit
>> when you have lots
>> of protocols running.
>>
>> This patch adds startup methods to many of the common targets. There
>> are still more to
>> go, however.
>
> Thanks for tracking this down; yes, I've noticed that process startup is
> slower than it could be, but have only had free time / mindspace to look
> at the XRL specifics.
>
> Could this be made a more general change? If the XIF method for startup
> you are adding is not specific to a particular protocol, it might be an
> idea to make it part of the common.xif -- which is where most of the
> process control knobs are.
> I'd rather not get too far into the machinery here, because I'm about to
> take a badly needed break. I guess the firewall and ifmgr modules are a
> special case, because they're separate service bundles located in the
> FEA process.

It could probably be put in common code.  I'm just learning this code
myself...likely can get a cleaner patch later when I understand things
better.

>
> On a more general note:
> One of the things Pavlin raised in an old BugZilla ticket, is the fact
> that the Router Manager is fairly complex because it implements
> transactions on the config tree itself.
> If this is pushed into the protocols themselves (they'd have to keep
> their own config snapshot, and adopt a commit-rollback transaction model
> in the XIF RPC interfaces), then the Router Manager gets a bit simpler
> overall.

I dislike that because then it would become virtually impossible to restart
failed protocol processes.  I think the rtr-mgr should hold all config state.

As mentioned earlier, I think the commit/rollback thing has been somewhat over-thought
as well.  There are way too many ways to fail a commit...I think it should only fail
if there are logical issues (and in that case, the rtr-mgr shouldn't even try
to 'commit': it should not even accept the change in the first place.)  If it tries
to push something to a module and that module reports error, then we flag that piece
of configuration as pending, or invalid, or similar and these flags would show up
when the user did a 'show run' or similar.  Then they know they need to fix it,
perhaps by re-configuring, or perhaps by fixing broken hardware, or some other
external thing.

My various patches to not fail commits when we don't have to is my ongoing effort
towards this type of behaviour....

Ben

>
> cheers,
> BMS


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



More information about the Xorp-hackers mailing list