[Xorp-hackers] New consolidated Xorp performance improvement patch uploaded.

[Bruce M Simpson]

Ben Greear wrote:
>>
>> The RTA_TABLE stuff looks interesting and useful, do you plan to 
>> forward port this to the HEAD revision?
> Yes, I plan to port everything to HEAD, and drop whatever is fixed by 
> Pavlin's fixes.  When I get something
> working again, I'll post it.

Excellent, look forward to it.

>> The RIB shouldn't really be setting the admin distance for 
>> static_routes at all.
> My hack works for me (and is small and easy to keep merged)..but I'll 
> gladly drop it if someone adds the ability to do it right.

The infrastructure's all already there; the protocol(s) just need to be 
taught to send a "set_protocol_admin_distance" XRL to the RIB before 
they try to register their OriginTable(s). It should only be done once 
and specify the RIBs which the process plans to add routes to.

OLSR only ever originates unicast IPv4 routes at the moment; see 
XrlIO::register_rib(). I had some snafus during development because I'd 
left in a call to register a multicast table, but didn't include it in 
set_protocol_admin_distance, which used to cause an error in the RIB; 
this has since been demoted to a warning.

It isn't possible to do this for *all* of the protocols, particularly 
the "connected" table which has special meaning to the RIB.

Also, the RIB does not yet handle changing admin distance for a running 
process, because this involves blowing away of a lot of RIB and FEA 
state; the code path to do it hasn't been written yet. It has to be done 
though as the admin distance gets embedded in every OriginTable which a 
routing protocol instantiates.

>>
>> P.S. __PRETTY_FUNCTION__ is gcc specific. 
>
> It would be easy enough to #define it to something similar for non-gcc 
> compilers...no need to remove useful functionality
> for the majority of the target platforms just because some don't 
> support a feature...

No need to cause breakage when gcc is not being used for an equally good 
but unspecified reason :-)

I've been looking at doing some logging code related to the very 
specific needs of routing processes -- __PRETTY_FUNCTION__ is useful, as 
it produces a fully qualified, undecorated name, including the class 
name, which you can then strsep() on "::" as a delimiter; but because 
it's non-standard, it breaks with anything which isn't gcc.

If you look around there's a proposal from an ex-Apple guy to add 
__class__ to the C99 and C++0x specs, it might be good to give him some 
political support somehow.

cheers
BMS