[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
  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.


> 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