Abstract: A network switch using a search engine to generate chained table lookup requests. After the search engine executes a first lookup, the next-pass logic in the search engine uses the first lookup result and information in the master key to generate a second lookup key as well as other parts of a second lookup request. A next-pass crossbar routes the second lookup request to a target memory, and the search logic executes the second lookup. The first lookup request may originate from a processing engine coupled to the search engine. The first and the second lookup results, if any, can then be returned back to the processing engine for further processing or decision making. The chain of lookups can be configured by software by specifying various operational parameters of the processing engines and the next-pass logic, including specifying a key construction mode for the second lookup.

Abstract: A network switch using a search engine to generate chained table lookup requests. After the search engine executes a first lookup, the next-pass logic in the search engine uses the first lookup result and information in the master key to generate a second lookup key as well as other parts of a second lookup request. A next-pass crossbar routes the second lookup request to a target memory, and the search logic executes the second lookup. The first lookup request may originate from a processing engine coupled to the search engine. The first and the second lookup results, if any, can then be returned back to the processing engine for further processing or decision making. The chain of lookups can be configured by software by specifying various operational parameters of the processing engines and the next-pass logic, including specifying a key construction mode for the second lookup.

Abstract: A network switch using a search engine to generate chained table lookup requests. After the search engine executes a first lookup, the next-pass logic in the search engine uses the first lookup result and information in the master key to generate a second lookup key as well as other parts of a second lookup request. A next-pass crossbar routes the second lookup request to a target memory, and the search logic executes the second lookup. The first lookup request may originate from a processing engine coupled to the search engine. The first and the second lookup results, if any, can then be returned back to the processing engine for further processing or decision making. The chain of lookups can be configured by software by specifying various operational parameters of the processing engines and the next-pass logic, including specifying a key construction mode for the second lookup.

Abstract: A network switch to support scalable and flexible access control list (ACL) lookup comprises a packet processing pipeline including a plurality of packet processing units each configured to generate a master key for an ACL lookup request to a memory pool and process a received packet based on ACL search results. The network switch further includes said memory pool including a plurality of memory groups each configured to maintain a plurality of ACL tables to be searched in one or more SRAM memory tiles of the memory group, accept and format the master key generated by the packet processing unit into a compact key based on a bitmap per user configuration, hash the formatted compact key and search the ACL tables stored in the one or more SRAM memory tiles using the formatted compact key, process and provide the ACL search results to the requesting packet processing unit.

Abstract: A network switch to support scalable and flexible wildcard matching (WCM) comprises a packet processing pipeline including a plurality of packet processing units each configured to generate a master key for a WCM request to a memory pool and process a packet based on looked up WCM rules. The memory pool includes a plurality of memory groups each configured to maintain a plurality of WCM tables to be searched in one or more SRAM memory tiles of the memory group, format the master key generated by the packet processing unit into a compact key based on a bitmap per user configuration, hash the formatted compact key and perform wildcard matching with the WCM tables stored in the one or more SRAM memory tiles of the memory group using the formatted compact key, process and provide the WCM rules from the wildcard matching to the requesting packet processing unit.

Abstract: A network switch to support scalable and flexible access control list (ACL) lookup comprises a packet processing pipeline including a plurality of packet processing units each configured to generate a master key for an ACL lookup request to a memory pool and process a received packet based on ACL search results. The network switch further includes said memory pool including a plurality of memory groups each configured to maintain a plurality of ACL tables to be searched in one or more SRAM memory tiles of the memory group, accept and format the master key generated by the packet processing unit into a compact key based on a bitmap per user configuration, hash the formatted compact key and search the ACL tables stored in the one or more SRAM memory tiles using the formatted compact key, process and provide the ACL search results to the requesting packet processing unit.

Abstract: A network switch to support scalable and flexible wildcard matching (WCM) comprises a packet processing pipeline including a plurality of packet processing units each configured to generate a master key for a WCM request to a memory pool and process a packet based on looked up WCM rules. The memory pool includes a plurality of memory groups each configured to maintain a plurality of WCM tables to be searched in one or more SRAM memory tiles of the memory group, format the master key generated by the packet processing unit into a compact key based on a bitmap per user configuration, hash the formatted compact key and perform wildcard matching with the WCM tables stored in the one or more SRAM memory tiles of the memory group using the formatted compact key, process and provide the WCM rules from the wildcard matching to the requesting packet processing unit.

Abstract: A shared memory stores packets for a packet processor. The shared memory is arranged into banks that are word-interleaved. All banks may be accessed in parallel during each time-slot by different requesters. A staggered round-robin arbiter connects requesters to banks in a parallel fashion. Requestor inputs to the arbiter are staggered to allow access to different banks in a sequential order over successive time-slots. Multi-processor tribes have many processors that generate random requests to the shared memory. A slot scheduler arranges these random requests into a stream of sequential requests that are synchronized to the staggered round-robin arbiter. A packet interface requestor stores incoming packets from an external network into the shared memory. The packet's offset within pages of the shared memory is determined by the first available bank that the packet can be written to, eliminating delays in storing incoming packets and spreading storage of frequently-accessed fields.

Abstract: A resource-lock monitor detects when processors in a multi-processor system are stuck waiting for access to a shared resource. A lock-monitor register has a lock bit and a sticky-lock bit for each processor being monitored. The lock and the sticky-lock bits are both set when the processor executes a lock instruction that also sends a lock-request to a resource arbiter. The lock bit is cleared when the resource arbiter grants access to the processor, but the sticky-lock bit remains set until sticky-lock bits are cleared by monitoring software at the end of a monitoring period. At the end of each monitoring period, monitoring software reads the lock and sticky-lock bits and finds a locked processor when a processor's lock bit is still set, but its sticky-lock bit is cleared. When the locked processor remains locked at the end of another monitoring period, an error handler resets the locked processor.

Abstract: A mechanism is disclosed for implementing resource locking in a massively multi-threaded environment. The mechanism receives from a stream a request to obtain a lock on a resource. In response, the mechanism determines whether the resource is currently locked. If so, the mechanism adds the stream to a wait list. At some point, based upon the wait list, the mechanism determines that it is the stream's turn to lock the resource; thus, the mechanism grants the stream a lock. In this manner, the mechanism enables the stream to reserve and to obtain a lock on the resource. By implementing locking in this way, a stream is able to submit only one lock request. When it is its turn to obtain a lock, the stream is granted that lock. This lock reservation methodology makes it possible to implement resource locking efficiently in a massively multi-threaded environment.