James Bensley wrote:
The BCM16K documentation suggests that it uses TCAM for exact matching (e.g.,for ACLs) in something called the "Database Array" (with 2M 40b entries?), and SRAM for LPM (e.g., IP lookups) in something called the "User Data Array" (with 16M 32b entries?).
Which documentation? According to: https://docs.broadcom.com/docs/16000-DS1-PUB figure 1 and related explanations: Database records 40b: 2048k/1024k. Table width configurable as 80/160/320/480/640 bits. User Data Array for associated data, width configurable as 32/64/128/256 bits. means that header extracted by 88690 is analyzed by 16K finally resulting in 40b (a lot shorter than IPv6 addresses, still may be enough for IPv6 backbone to identify sites) information by "database" lookup, which is, obviously by CAM because 40b is painful for SRAM, converted to "32/64/128/256 bits data".
1 second / 164473684 packets = 1 packet every 6.08 nanoseconds, which is within the access time of TCAM and SRAM
As high speed TCAM and SRAM should be pipelined, cycle time, which matters, is shorter than access time. Finally, it should be pointed out that most, if not all, performance figures such as MIPS and Flops are merely guaranteed not to be exceeded. In this case, if so deep packet inspections by lengthy header for some complicated routing schemes or to satisfy NSA requirements are required, communication speed between 88690 and 16K will be the limitation factor for PPS resulting in a lot less than maximum possible PPS. Masataka Ohta