Introduced: March 2010
The Broadcom BCM56840 series of silicon switchs have a code name Trident. It is called merchant silicon because Broadcom makes the part available to switch manufacturers who build competing products. In the trade press, this is often called a switch ASIC but Trident is actually a full custom design. This gives it a speed advantage over manufacturers that use gate-array ASICs where all customization is done in a final metalization layer. The following graphic shows the range of vendors that are using the same silicon:
A debate rages between manufacturers that claim generic silicon leads to generic switches that will have mediocre performance [cisco] and manufacturers like Arista that proudly proclaim that chip design is not their expertise and they have better things to do with their engineering dollars. Other manufacturers claim to use merchant silicon in some products and custom silicon in others [Brocade]. While Broadcom does not have direct end customers to guide development of new features, they get advice from the manufacturers that build products on which potential features will lead to better products -- and greater sales.
The Trident+ has a 9 MByte block of buffer which is partitioned by the switch software between dedicated per-port buffers and a dynamic buffer pool that can be allocated on demand. This memory is organized as 46080 cells of 208 bytes each. These cells are chained together to build buffers to hold packets of varying sizes. It is possible that the manufacturer may have staticly allocated all the memory directly to the ports and there is no dynamic pool. Teasing this out of data presented by manufacturer data sheets is difficult.
A flagship feature of the Trident+ is ultra low latency achieved with cut through switching. This may be important in data center applications. It definitely is a money maker for the high frequency trader crowd. It is irrelevant to file transfers over long RTT paths. To achieve the low latency performance, the Trident needs extemely fast access to its buffers. It gets that by putting them on the silicon with the switch. All Trident+ products show the same amount of packet buffer because the on-chip RAM cannot be augmented.
It might be that all Trident+ products carve up the buffers in the same way. But it seems unlikely that would be true. Broadcom parameterizes lots of controls in the switch. This lets the manufacturer set them to best advantage. We know that the BCM56840 is capable of flow control, and that not all manufacturers include it in their feature set. Flow control -- if it is used -- is part of a buffer management scheme. So we know that there are differences. It would be unwise to assume anything about the maximum queue depth without explicit confirmation from the manufacturer -- or in-house testing.
One thing that sets the Trident apart from its silicon merchant brethren like Intel is that Broadcom does not openly publish the technical data sheets for its products on its web site. Most users don't read chip data sheets; perhaps none should. And if manufacturers did a better job with product specifications, none would need to.
Industry pundits say that the only reason the Cisco Nexus 3064 contains a heart of Trident is because Cisco's silicon was late and they needed a cut through low latency product. Whether that is true or not, the Cisco ASIC that drives the 3548 is in production. A side note is that Cisco is less shy about exposing internal details than is Broadcom.
The trident2 was announced by Broadcom in August 2012. After a delay, products were announced by synchronized press releases from switch vendors in November 2013.
Addition 1 Jan 2016
Juniper has written extensively on buffering features of its Trident+ and Trident-II products. They refer to their default as a balanced configuration that works for both data center lossless traffic and best effort lossy traffic. The default trident+ configuration has 2 MBytes in the dynamicly allocated best effort egress queue. A system tuned for best effort traffic without lossless queues will improve this to 4.99 MBytes. If multicast queues can be eliminated from the mix, this would push up to about 6 MBytes. These numbers scale up 30 percent for Trident-II, reflecting its larger buffer pool.
Juniper has extensive controls of the buffer knobs. See, for example:
While these could be implemented by any manufacturers, they might not all be exposed in the switch config the way that Juniper has done.
Referring to the buffer table, it is from the size of the shared unicast best effort egress buffer that I base the estimate of 5 MBytes best burst size. This is not what derives from Juniper's default parameters. It is reserved for those that read the manuals.
Arista has a series of Day in the life of a packet papers that explain in some detail how the Trident+ and Trident-II work. Mostly, packets move quickly through input processing. Flow control might be an exception to this. Dropped packets are mostly from the egress queues.
BM56840 is a family of parts that includes both Trident and Trident+. Broadcom does not use internal development names like Trident in their literature. Neas as I can tell, at intoduction, the Trident required an external PHY chip to connect to the SFP+ ports. The trident+ (BCM56846) permits building a product without PHY chips which lowers cost and power consumption. The switch characteristics (speeds and feeds, address table sizes, packet buffer size) are the same.