[c-nsp] Dynamic TCAM allocation/optimization? (was Re: N7K tcam handling)

[Tim Stevenson]

Hi Chris, please see inline below:

At 11:23 AM 3/11/2010, Chris Woodfield clamored:

>Can you elaborate (or point me to docs) on how this dynamic allocation works?

All I'm talking about is allocating logical FIB TCAM entries of 
specific widths. IPv4 unicast prefixes take one 72-bit entry in the 
TCAM. When we say "128K FIB TCAM entries" we are talking about 72 bit 
wide entries.

IPv4 multicast & IPv6 unicast entries consume 2 entries, logically 
it's a 144-bit wide entry. v6 multicast uses 244 bits (4 entries).

Earlier software releases statically carved the 128K entries into 
fixed size regions of each width. Now we carve it dynamically, based 
on need. There are still some constraints - eg, the minimum block 
size for a given width is 8K in current fwding engines.

>  Is the TCAM populated on demand based on traffic? I imagine the 
> old horror of the Sup1A's flow-based forwarding every time I hear this...

It is *definitely* NOT a cache based model. All I'm talking about is 
TCAM entry block sizes for different width logical entries.

>And while we're on the subject, are there any reasons why Cisco (or 
>any other vendor AFAIK) has seriously looked into methods of 
>"optimizing" the TCAM? I'm thinking in terms of "If 10.0.0.0/16 and 
>10.0.1.0/24 both have the same next hop, why do you need two TCAM slots?"

It's always a tradeoff. Presumably, if we spent CPU cycles churning 
through the RIB & deciding which entries could be "consolidated" (and 
then dealing with route adds/deletes, interface flaps, etc in such a 
scenario) then people would probably complain about how we chew up 
CPU trying to optimize the routing table rather than just using a bigger TCAM.

Hope that helps,
Tim



>Oh wait, that might mean your customers might not need to upgrade as 
>often. Never mind.
>
>-C
>
>On Mar 9, 2010, at 3:16 PM, Tim Stevenson wrote:
>
> > Hi Tony,
> > The FIB TCAM is already dynamically allocated as of 4.2 (ie, no 
> static/fixed allocation, blocks of various width entries 
> grow/shrink as necessary). At the control plane, you can control 
> the max prefixes for each, which naturally limits the h/w 
> consumption to those numbers as well.
> >
> > Hope that helps,
> > Tim
> >
> >
> > At 11:28 AM 3/9/2010, Tony Varriale clamored:
> >> <snip>
> >> And I believe you are going to allow configurable allocation between ipv4
> >> and ipv6 space.
> >>
> >> tv
> >>
> >> _______________________________________________
> >> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> >> 
> <<https://puck.nether.net/mailman/listinfo/cisco-nsp>https://puck.nether.net/mailman/listinfo/cisco-nsp>https://puck.nether.net/mailman/listinfo/cisco-nsp
> >> archive at 
> <<http://puck.nether.net/pipermail/cisco-nsp/>http://puck.nether.net/pipermail/cisco-nsp/>http://puck.nether.net/pipermail/cisco-nsp/
> >
> >
> >
> >
> > Tim Stevenson, tstevens at cisco.com
> > Routing & Switching CCIE #5561
> > Technical Marketing Engineer, Cisco Nexus 7000
> > Cisco - <http://www.cisco.com>http://www.cisco.com
> > IP Phone: 408-526-6759
> > ********************************************************
> > The contents of this message may be *Cisco Confidential*
> > and are intended for the specified recipients only.
> >
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > 
> <https://puck.nether.net/mailman/listinfo/cisco-nsp>https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at 
> <http://puck.nether.net/pipermail/cisco-nsp/>http://puck.nether.net/pipermail/cisco-nsp/




Tim Stevenson, tstevens at cisco.com
Routing & Switching CCIE #5561
Technical Marketing Engineer, Cisco Nexus 7000
Cisco - http://www.cisco.com
IP Phone: 408-526-6759
********************************************************
The contents of this message may be *Cisco Confidential*
and are intended for the specified recipients only.