[c-nsp] TCAM refresher

[Tony Li]

On Mar 14, 2007, at 2:28 PM, Florian Weimer wrote:

> * Tony Li:
>
>>> And your ARP table entries.  Of course, Cisco could fix that by
>>> aggregating entries before they end up in the TCAM: If both
>>> 192.0.2.8/30 and 192.0.2.12/30 have the same adjacency, you can do
>>> with a route for 192.0.2.8/29 instead.  But there are probably  
>>> reasons
>>> for not doing it this way in the first place, so it's unlikely that
>>> such a change will arrive in time.
>
>> Such a change is computationally intensive and would frequently cause
>> problems with processor overload.
>
> Just out of curiosity, have actually you benchmarked this?
>
> (But I admit, the necessary code changes before you could do this look
> pretty significant.)


It's been implemented and benchmarked (albeit in a previous life).   
It is very CPU intensive and it is complicated.  At this point, you  
should not expect this to save you from near-term FIB overflow.


On Mar 14, 2007, at 2:33 PM, Chris Griffin wrote:
> How about unnecessary specifics in the presence of a valid covering  
> route?  I imagine the concern would be the potential CPU increase  
> if that covering route went away and you had to install a ton of  
> specifics into the FIB, but it might be a good optional feature.


Yet another case in the same analysis.  There are a fair number more.

Tony