[c-nsp] 6500 WS-X6748-GE-TX and memory

[Ian Cox]

At 08:41 PM 3/27/2007 +0200, Christoph Loibl wrote:
>Hi!
>
>On Mar 27, 2007, at 8:01 PM, Ian Cox wrote:
>
>>At 07:28 PM 3/27/2007 +0200, Arnold Nipper wrote:
>>>On 27.03.2007 17:51 Nick Griffin wrote
>>>
>>>>Let me rephrase, assume I have no reason. What would a selling
>>>>point be? I
>>>>cannot not find any good documentation regarding the memory. What
>>>>enhancements does it provide, more CAM entries, things of that
>>>>nature.
>>>>Perhaps I just need more information on the card, to help
>>>>understand the
>>>>need for additional memory that what it ships with by default.
>>>
>>>IIRC this gives you more buffer for your line card. I.e. you will be
>>>able to buffer up to 1 GB worth of traffic.
>>
>>Not it does not give you more buffering on the line card. The larger
>>memory part is for the processor on the line card so it can hold
>>large FIB tables.
>
>Do I get this right... The memory is just for the DFC enabled cards?

You need more memory on the DFC cards because they have software 
copies of the FIB, ACLs tables etc that are used to program the hardware.

>So why is there such a large amount of memory on the CFC only cards?

I would not call 256Mbytes exactly large. The local CPU has to 
program the port ASICs and retrieve statistics. There are nearly 100 
counters per port, and MAC and PHY ASICs have hundreds of registers 
one must program. Then there is the fabric and bus interface ASICs 
that have hundreds more registers. The interface queues are built 
into the port ASICs and use SRAMs. Along with state machines for auto 
negotiation, ... With an SXE5 image approximately 64Mbytes is used. 
You can not easily buy 128Mbyte memory parts any more so that is why 
the 256Mbytes.


>There is no special data to store on the CFC line-cards except the
>interface queues (which seem to be somehow integrated into the
>interface chips)?

Interface queues on the ports on most switch platforms are done in 
DDR/QDR SRAMs, Reduced Latency DRAM (RLDRAM), FCRAM which are 
generally soldered to the board. Some designs even manage to fit the 
memory on the ASIC itself.

>I am not really familiar enough with this routers/switches
>architecture (but curious - as we plan to put some of those in
>various places). Does CFC mean that the whole packets are sent from
>line-card to the SUP and if the SUP-Engine decides that it should be
>transmitted on a port of the receiving line-card the packet goes over
>the backplane a second time?

On the 6500, the CFC transmits the packet on the backplane bus once 
to the supervisor. All the ASICs attached to the bus see the packet 
and the supervisor PFCx sends back the instructions to rewrite the 
packet and which port(s) the packet is going out. If the packet is 
going out the same line card then it gets rewritten and sent out. The 
process in different platforms varies due to the way they are designed.

The following link at the bottom describes how sup32 forwards packets 
on the bus. The Sup720 with CFCs is different in that only headers go 
the Supervisor, and if the packet stays on the same complex then it 
does not need to go across the switch fabric. If the packet has to go 
to a different card or a different fabric channel on the same card 
then it is sent across the fabric.

http://www/en/US/products/hw/switches/ps708/products_white_paper0900aecd803e508c.shtml


Ian

>  Or is just the header (whatever needed
>for the forwarding decision) sent to the SUP-Engine, ... ?
>
>Stoffi
>
>
>>
>>>It much depends what your application is. If you have sercer
>>>connected
>>>to that linecard having more buffer might be a good idea. Having
>>>connected routers you may not want yout switch to buffer too much.
>>>
>>>
>>>
>>>Arnold
>>>--
>>>Arnold Nipper / nIPper consulting, Sandhausen, Germany
>>>email: arnold at nipper.de       phone: +49 6224 9259 299
>>>mobile: +49 172 2650958         fax: +49 6224 9259 333
>>>_______________________________________________
>>>cisco-nsp mailing list  cisco-nsp at puck.nether.net
>>>https://puck.nether.net/mailman/listinfo/cisco-nsp
>>>archive at http://puck.nether.net/pipermail/cisco-nsp/
>>_______________________________________________
>>cisco-nsp mailing list  cisco-nsp at puck.nether.net
>>https://puck.nether.net/mailman/listinfo/cisco-nsp
>>archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>--
>CHRISTOPH LOIBL ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>mailto:c at tix.at   |No trees were killed in the creation of this message.
>http://pix.tix.at |However, many electrons were terrible inconvenienced.
>CL8-RIPE ++++++++++++++++++++++++++++++++++++ PGP-Key-ID: 0x4B2C0055 +++