[Xorp-hackers] heavy CPU use for xorp_fea on startup
Pavlin Radoslavov
pavlin at ICSI.Berkeley.EDU
Tue Mar 4 18:20:52 PST 2008
> > In your implementation you need to be very careful that you capture
> > all places inside IfTree that are related to the new pif_index to
> > vif mapping.
> >
> I was thinking on the way home: Maybe just map if-index to if-name. If
> the mapping
> lookup fails, do a long slow linear lookup and if the object is found,
> add it to the if-index -> map.
> If it succeeds, then lookup the vif by way of the existing hash,
> double-check the if-index is
> correct (if not, do a slow lookup).
I think this adds lots of complexity.
Just a simple if-index to vif-name-pointer should be sufficient.
Off the top of my head, you need to consider the following places
inside IfTree that will affect the mapping:
* Any change to the _vifs (also vifs()) container of any of the
interfaces.
This will capture add/deletion of a vif.
* Any change of pif_index of IfTreeVif.
I think this change is captured by IfTreeVif::set_pif_index() but
you might want to double-check and look carefully for any direct
assignment to IfTreeVif::_pif_index.
Note that pif_index of 0 is invalid, so any vif with such index
shouldn't be on the map.
Thanks,
Pavlin
> I'll also update the if-index -> if-name hash when a vif is added so at
> least most of the
> time we shouldn't have to do a slow lookup.
>
> This should keep us from having to worry about stale memory references to
> vifs that might have been deleted, while giving good scaling lookups.
>
> Sound legit?
>
> Ben
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc http://www.candelatech.com
>
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
More information about the Xorp-hackers
mailing list