A lookup table engine that supports multiple protocols

Abstract

The lookup table engine (100) can be implemented in hardware logic and provides operation for a variety of different communication protocols and packet types. The lookup table memory (112) can be populated with rules, specifically indicating which bytes of a particular packet to extract, which comparisons to be made to those extracted bytes, and the actions to be taken based on the results of those comparisons. The lookup table engine can be implemented within a network accelerator (800) that receives packets, and the processor core (808) of the network accelerator can offload lookup operations to the lookup table engine.

Description

Technical Field

[0001] This disclosure generally relates to a lookup table engine, and more specifically, to a lookup table engine configured to support multiple protocols. Background Technology

[0002] A network consists of nodes connected via various configured ports. For a packet to be sent from one node to another that is not directly connected, intermediate nodes in the path must know where to send the packet. This can be achieved by the source node sending information such as the destination address along with the packet to the first receiving node. This information is checked by the first receiving node and each subsequent receiving node, which attempts to match this information against a destination entry in a programmed database called a lookup table. Based on the result, the receiving node forwards the packet to another receiving node closer to the destination node. This process continues until the packet reaches its destination node.

[0003] This node lookup process can be implemented in software or hardware. Typically, for speed and efficiency, this is done in hardware. Most hardware lookup table designs are fixed for a single protocol and the packet information fields within that protocol. Fixed protocols and formats help meet performance requirements to maintain a given network rate. However, even with these trade-offs, it often proves difficult to achieve the given performance at a given cost. Such solutions can also become obsolete if the lookup entries and logic cannot adapt to new versions and levels of protocols. Summary of the Invention

[0004] In one arrangement, a method includes: receiving a pointer to a first rule, wherein the first rule identifies a first plurality of bytes of a group; accessing the first rule from a first memory according to the pointer; applying the first rule, including generating a search word containing the first plurality of bytes of the group and omitting a second plurality of bytes; accessing a second rule referenced in the first rule, wherein the second rule identifies a plurality of comparison operations to be applied to a plurality of portions of the search word; performing the plurality of comparison operations according to the second rule; writing the results of the plurality of comparison operations to a buffer; and notifying a processor core of the results of the plurality of comparison operations.

[0005] In one arrangement, a circuit includes: a first plurality of registers, each of which is configured to receive data for a lookup operation from a corresponding processor core among a plurality of processor cores; a first memory configured to store a first plurality of rules, a second plurality of rules, and a plurality of lookup table sets; and a plurality of lookup table engines configured to access the first memory and access data from the first plurality of registers; wherein a first lookup table engine among the plurality of lookup table engines is further configured to: receive first data from a first processor core, wherein the first data references a first rule among the first plurality of rules for a first lookup operation and references a location of a group in a second memory; generate a search word according to the first rule, including storing a first byte subset of the group into a register and omitting storing a second byte subset of the group into the register; accessing a second rule among the second plurality of rules according to the first rule; generating a plurality of portions of the search word according to the second rule; comparing the plurality of portions of the search word with corresponding entries from the lookup tables according to the second rule; and writing an event to a scheduler of the first processor core based at least in part on the comparison results of the plurality of portions of the search word.

[0006] In one arrangement, a network accelerator includes: a first processor core; a processor scheduler communicatively coupled to the first processor core; and a lookup table engine communicatively coupled to the processor scheduler, wherein the lookup table engine is configured to: receive first data from the first processor core and, in response, access a first rule and a second rule; generate a search word from packets referenced in the first data based on the first rule, including storing a first portion of the packets and omitting storing a second portion of the packets; perform a plurality of comparison operations according to the second rule, wherein each comparison operation compares a corresponding byte of the search word with a corresponding byte from a lookup table entry; and write an event to the processor scheduler in part based on the result of the plurality of comparison operations. Attached Figure Description

[0007] Having described the invention in its general sense, reference will now be made to the accompanying drawings, in which:

[0008] Figure 1 This is an illustrated explanation of an example lookup table engine adapted according to some implementation examples.

[0009] Figure 2 This is an illustrated description of example methods for performing a lookup operation according to some embodiments.

[0010] Figure 3 This is a graphical illustration of example transfer rules based on some embodiments.

[0011] Figure 4 This is a diagrammatic illustration of an example structure of a data storage device according to some embodiments.

[0012] Figure 5 This is a diagrammatic illustration of example entry rules based on some embodiments.

[0013] Figure 6 This is an illustrated description of example entries based on some embodiments.

[0014] Figure 7 This is an illustrated description of example methods for processing groups according to some embodiments.

[0015] Figure 8 This is a diagrammatic illustration of an example network accelerator based on some embodiments.

[0016] Figure 9 This is an illustration of an example system-on-a-chip (SoC) based on some embodiments, which may include a network accelerator, such as... Figure 8 A network accelerator. Detailed Implementation

[0017] This disclosure provides a flexible lookup table engine that can be programmed to perform lookup operations on any protocol and any field within those groups. This can be achieved through a three-level lookup: table / transfer rules, entry rules, and entries. These roughly correspond to protocols, fields, and matching criteria.

[0018] In some examples, the lookup table engine supports multiple lookup tables and therefore multiple protocols by leveraging multiple transition rules. These transition rules extract data from groups to intermediate data words, such as search words, for use in the lookup. Transition rules can also point to a set of entry stages contained in the table, extracted from the search word for matching. An entry stage can contain entry rules and a set of entries. Entry rules specify which parts of the search word to compare, and entries specify the matching criteria. In the example, when entries match, the lookup engine writes the results of the entries to the search word (space is reserved in the search word for the entry results). Entries can also specify what to do next, such as jumping to the next entry stage or ending the lookup. This flexibility allows multiple grouping fields and protocol levels to be compared and matched within the same lookup. When the lookup operation is complete, transition rules can be used to write the final results from the search word back to the groups for further grouping processing.

[0019] Compared to alternative technologies that use hard-coded lookup engines to examine specific grouping fields of a particular protocol, the programmability and general nature of the entries and matching logic in this disclosure offer greater versatility and improved future applicability.

[0020] Figure 1 This is an illustrated description of an example lookup table engine 100 adapted according to some embodiments. The lookup table engine 100 can be implemented using a fixed-purpose (i.e., hard-coded) circuit system, a programmable circuit system, or a combination thereof, and can be incorporated into another circuitry implemented within a system-on-a-chip (SoC), such as into a network accelerator. Examples of network accelerators include... Figure 8 The network accelerator 800, and the example SoC includes Figure 9 The SoC 900.

[0021] In one example, packets enter the network accelerator, for example... Figure 8 The network accelerator 800. Then, for example... Figure 8 The processor of one of the processor cores 808 can offload a lookup operation to the lookup table engine 100. The lookup table engine 100 can receive data from the processor core 808, which triggers the lookup table engine 100 to use its lookup table resources to determine the processor operation. The lookup table engine 100 can determine the processor operation based on rules, the contents of the lookup tables, and the contents of the packets. The lookup table engine 100 can then return a pointer or other data indicating the processor operation to the processor core. Examples of processor operations may include forwarding packets to a specific destination, discarding packets, performing statistical analysis on packets, etc.

[0022] The lookup table engine 100 includes a demultiplexer 102 that receives data from multiple processor cores. For example, a network accelerator may include multiple processor cores 808 configured to write data to lookup table register 104 to enable the lookup table engine 100 to perform a lookup operation. The demultiplexer 102 receives the data and directs it to the appropriate register in register 104. In one example, register 104 may contain multiple registers, each of which is assigned to a corresponding one of the processor cores 808. The demultiplexer 102 may then, in response to a processor ID from the requesting processor core, direct data from the processor core to the corresponding register in register 104.

[0023] Figure 1The lookup table engine 100 is configured for parallel operation. For example, as noted above, multiple processor cores in processor core 808 can request lookup operations from the lookup table engine 100, and these lookup operations can be performed concurrently. Such parallel operation can be facilitated by lookup table register 104, arbitrator 106, and lookup hardware logic 108. Arbitrator 106 can be configured to read data from register 104 and pass that data to the available portion of lookup hardware logic 108 one register at a time. In some examples, requests from processor core 808 may not be assigned priority; in this case, arbitrator 106 can circumvent register 104. In another example, some requests may be marked as real-time (RT), or others may be marked as non-real-time (NRT); in this case, arbitrator 106 can assign RT requests to the available portion of lookup hardware logic 108 before assigning NRT requests.

[0024] The lookup hardware logic 108 can be configured as multiple parallel portions of hardware logic, each configured to perform a lookup operation based on a request. A given portion of the lookup hardware logic 108 can receive a request via arbitrator 106 and by accessing rules and entries from memory 114 and by accessing data stored in another memory (e.g., ...). Figure 8 The lookup operation is performed by the group itself in the data memory 811. Each part of the lookup hardware logic 108 can be executed by... Figure 2 The operation process is as follows: 200 is used to perform the search operation.

[0025] The lookup operation may involve a scheduler that writes events to the processor, for example... Figure 8 The scheduler 807. Events may correspond to processor operations, and the scheduler may pass the processor operation to the appropriate processor core among processor cores 808.

[0026] The lookup operation may also include writing the result to the memory of the storage group (e.g., Figure 8 The data is stored in the data memory 811 and / or the results are written to the shared software register 110. The shared software register 110 is configured to be accessed by any processor core 808 in the network accelerator 800. For example, statistics that may be useful for other processes may be data that can be written to register 110.

[0027] Switching element 112 can be used to communicatively couple lookup hardware logic 108 to memory 114. Furthermore, lookup table engine 100 includes a configuration interface 116 configured to receive configuration data. Configuration interface 116 can be configured to communicate with memory 114 via switching element 112 to add, delete, or modify entries in memory 114. For example, configuration interface 116 can allow external application processor cores (e.g., in...) to... Figure 9 In 910, configure transfer rules, entry rules, and entries.

[0028] Figure 2 This is a schematic illustration of an example operation flow 200 for performing a lookup operation according to some embodiments. Operation flow 200 can be executed by lookup hardware logic 108. More specifically, a given portion of the parallel section of lookup hardware logic 108 can execute operation flow 200.

[0029] In operation flow 200, lookup hardware logic 108 performs a three-level lookup operation on a group using a table data structure stored in memory 114. The first level determines transfer rules within the table, specifying one or more portions of the group to be used in the search term. The second level determines entry rules within the table, specifying one or more portions of the search term used to query a set of entries. The third level determines entries within the table to update the search term. The updated search term can be used in another lookup iteration or to modify one or more portions of the original group. In some such examples, transfer rules specify the portion of the search term to be copied (e.g., appended or rewritten) to a specified portion of the group.

[0030] Therefore, lookup operations can use search terms to modify the header, data payload, and / or the rest of the packet. For more complex modifications to the packet, entries in the table can be configured with tasks for the processor core scheduler, which can cause the processor core to read the packet, modify the packet, and write the modified packet back to memory. Alternatively, tasks can cause the processor core to take other actions on the packet.

[0031] Processor core (e.g., Figure 8 One of the processor cores 808 can initiate a lookup operation by writing a group of data memory addresses to a set of registers 104 corresponding to the processor core. At action 201, the processor core can also write pointers for transfer rules to this set of registers 104. Although not shown in operation flow 200, the processor core can write data to indicate whether the request is real-time or non-real-time, including writing such data to this set of registers 104. In this example, when the processor core writes data to register 104, this acts as a request for a lookup operation.

[0032] At actions 202 and 204, the lookup hardware logic 108 uses the transfer rule pointer as an address to read the transfer rule from memory 114 and stores the transfer rule in its internal register 109. At actions 206 and 208, the lookup hardware logic 108 uses the data memory address from the processor core to identify the data memory (DMEM, e.g., ... Figure 8The lookup hardware logic 108 can use transfer rules to read specific bytes of the packet via direct memory access (DMA) logic at actions 206 and 208. At action 210, the lookup hardware logic 108 can store the bytes of the packet as a search word in its own internal register 109.

[0033] To begin constructing a new search word, lookup hardware logic 108 deletes the old search word from its own internal register 109 and then generates a new search word at action 210. Lookup hardware logic 108 may generate the new search word based on portions of a group specified by a transfer rule. According to some embodiments, Figure 3 Example transfer rule 300 is described below. Example transfer rule 300 may be data stored in memory 114 and accessed at action 202 by lookup hardware logic based on a transfer rule pointer from the processor core. In this example, transfer rule 300 contains 256 bits, but the scope of the implementation is not limited to any size of transfer rule. Example transfer rule 300 contains 10 DMA records 0-9. Each of DMA records 0-9 specifies a portion of a packet by specifying the bytes of the packet stored in data memory (e.g., memory 811). Each of DMA records 0-9 may point to different bytes or multiple bytes, and the total number of DMA records 0-9 may refer to less than the entire packet. In other words, lookup hardware logic 108 may read a portion of the packet specified by DMA records 0-9, and in doing so, less than the complete packet may be read and other portions of the packet may be omitted from reading.

[0034] DMA records 0-9 or other parts of the transfer rule can specify how to generate a search word by writing each part of the packet to register 109 inside the lookup hardware logic 108. For example, DMA records 0-9 can specify the order of the corresponding parts of the packet in the search word. The lookup hardware logic 108 can read the portion of the packet specified by DMA records 0-9 and write those read portions into its internal register 109 as the search word. Therefore, the search word can contain some, but not all, of the bytes of the packet. Furthermore, while example transfer rule 300 contains 10 DMA records, the scope of the implementation can include any appropriately scaled transfer rule containing more or fewer DMA records.

[0035] The transfer rule specifies how to generate the search word to include relevant bytes from the packet and omit irrelevant bytes. The specific relevant and irrelevant bytes for a given packet can depend on the packet type. For example, Ethernet packets may have a different format and different relevant portions than Controller Area Network (CAN) frames. For instance, example relevant portions of an Ethernet packet might include the destination address, VLAN ID, Media Access Control address, Ethernet type, Internet Protocol address, TCP / UDP port number, etc. For a CAN frame, examples of relevant data might include the CAN ID and CAN port. Of course, the relevant data may be the same or different for a given use case. Examples of data that might be irrelevant in some use cases might include user data in the payload. However, a given transfer rule can be programmed to extract any appropriate data from the packet to generate the search word.

[0036] In this example, the processor core determines which transition rule to use for operation flow 200. The processor core can use any criterion to determine the appropriate transition rule. For example, in some implementations, a packet stream from a single endpoint may contain a thread ID, and the thread ID can be used to identify the endpoint. An example endpoint may contain... Figure 9 The packet switches 920 and 925. The processor core can resolve the thread ID to determine the endpoint, and then determine the transfer rule based on the thread ID. In such cases, the endpoint may be limited to a single communication protocol, such as Ethernet, and the thread ID will therefore lead to one or more transfer rules customized for Ethernet. In another example, the endpoint may be associated with a Control Area Network (CAN) protocol, and therefore the thread ID will lead to one or more transfer rules customized for CAN. Additionally, for each protocol, multiple packet types may exist, and the processor core can be configured to identify packet types within a protocol and select transfer rules at least in part based on the packet type. An example includes acknowledgment (ACK) packets in Ethernet, which are a specific type of packet within the Ethernet protocol, and the processor core can be configured to select transfer rules specifically for ACK packets.

[0037] In any case, the processor core provides a pointer to a transfer rule, which can be one of several different transfer rules stored in memory 114. Each transfer rule can be customized to extract specific bytes from a specific packet type. In this example of operation flow 200, the processor core selects a transfer rule applied by lookup hardware logic 108 for the packet protocol, and possibly more specifically, for the packet type within the protocol. Other transfer rules for other protocols and packet types can be stored in memory 114, and subsequent transfer rule pointers can point to those other transfer rules.

[0038] In some examples, operation flow 200 utilizes a search term specified by a transfer rule and based on grouping, and also utilizes a shared search term 222. The shared search term 222 can be shared among various instances of the hardware logic 108, such that a lookup based on a first group on an instance of the hardware logic 108 can update the shared search term 222 used on other instances of the hardware logic 108. Therefore, the complete search term used by the hardware logic 108 may contain a portion of search term 210 and a portion of shared search term 222.

[0039] When a complete search term is generated, lookup hardware logic 108 searches for the corresponding entry in a table data structure in memory 114 to determine the operation to be performed on the group. In some examples, entries are grouped into multiple stages, and example transfer rule 300 includes a stage offset field. The stage offset field directs lookup hardware logic 108 to the address of an entry rule that marks the beginning of a stage of the entry and specifies the relevant portion of the entry in the search term to be used to query that stage. Therefore, the address of the entry rule can be separated from the address of the transfer rule in memory 114 by a space equal to the stage offset. In other words, example transfer rule 300 points to the corresponding entry rule. In some examples, multiple transfer rules may point to the same entry rule.

[0040] Figure 4 This is an illustration of an example structure 400 of memory 114 according to some embodiments. In this example, memory 114 includes four shards and multiple columns and rows, and the range of embodiments may include any suitable number of shards, columns, and rows. Different rows store different data, and each different row has its own row address, where a specific data segment within a row can be identified by a row offset within the row. A first address in numerical order is used to store a transfer rule (Xfer rule). Subsequent rows in numerical order contain a first entry rule (entry rule - phase A), followed by entries applicable to entry rule - phase A. The remaining addresses in numerical order within memory 114 contain additional entry rules (e.g., entry rule - phase B) and their corresponding associated entries. Notably, each entry rule is followed by its associated entry, such that lookup hardware logic 108 can read from a contiguous range of addresses to access both the entry rule and its associated entry.

[0041] Return to Figure 2 Following example operation flow 200, the lookup hardware logic 108 has generated a search word at action 210. At action 212, the lookup hardware logic 108 uses the stage offset field of the transfer rule to access the corresponding entry rule. In simple terms, the entry rule specifies the comparison operation to be performed with the search word. The entry rule can also specify where in the internal register 109 of the lookup hardware logic 108 the result of the comparison operation within the search word will be written.

[0042] In one example, an entry rule corresponds to multiple entries, for example in Figure 4 In this example, the entry rule - phase A corresponds to the entry marked as entry - phase A. The entry rule can specify the first part of the search term to be compared using the first rule. In this example, the first part of the search term can be referred to as the comparison term at action 214. The entry rule can specify additional parts to generate subsequent comparison terms, each of which is compared using an entry.

[0043] Figure 5 This is a diagrammatic illustration of an example entry rule 500 according to some embodiments. Entry rule 500 may specify the value to be used in the comparison with the comparison word, a portion of the search word to be modified when the comparison is true, the value of a portion of the search word to be modified (e.g., within the portion of search word 210 and / or the portion of shared search word 222), one or more scheduler parameters for the operation to be performed on the group, and / or other suitable parameters and values.

[0044] Example entry rule 500 includes a type field that identifies the entry rule as an entry rule. Example entry rule 500 also contains 12 comparison records 0-11. Each comparison record specifies a corresponding byte index within the search word, where this byte index is a portion of the search word—the comparison word at action 214. Figure 4 In the example, the sample entry rule contains entry rule-phase A, and the entry used for comparison with the comparison word contains entry-phase A. Sample entry rule 500 also includes a result record field, which specifies where in the internal register 109 of the lookup hardware logic 108 the result of the comparison operation within the search word will be written. The size of entry rule 500 is merely an example, and the scope of implementations may include entry rules of any appropriate size.

[0045] As noted above, the lookup hardware logic 108 generates a comparison word 214 based on the byte index of the comparison record in the entry rule. The corresponding entry may contain a mask and a value, which the lookup hardware logic 108 reads at action 216. At action 218, the lookup hardware logic 108 compares the comparison word with the mask and the value, and then returns the result at action 220. The lookup hardware logic 108 can generate comparison word 214, compare the value and mask with the comparison word at action 218, and return the result, as many times as the entry rule for generating the comparison word. Figure 5 In the example, there are a total of 12 comparison records, which allows for the generation of a single comparison word and the execution of 12 comparison operations. However, some embodiments may not use all comparison records, thus the lookup hardware logic 108 may perform fewer than 12 comparison operations. The scope of the implementation may include any appropriate number of comparison operations for a given entry rule.

[0046] A given entry may contain multiple fields that list specific parameters for a given comparison operation for the comparison word. Figure 6 This is an illustration based on example entry 600 of some embodiments.

[0047] Entry 600 includes a type field indicating that the entry is an entry. Entry 600 also includes a mask index and a mask length field, which indicate the range of bits to be ignored within the comparison word for the comparison operation. The scheduler index field provides an index to the scheduler pointer. In the example, if the comparison operation is positive (e.g., a match exists), the lookup hardware logic 108 can use the scheduler index field to retrieve the scheduler pointer from its own internal register 109 and pass that scheduler pointer to the processor scheduler (e.g., ...). Figure 8 (Scheduler 807). If the comparison operation is affirmative, the result field indicates the value to be written to the search word.

[0048] The jump index provides the index within memory 114 to which the lookup hardware logic 108 jumps. In this example, bits 82:91 indicate whether the comparison operation is a shared operation, and if so, where the result is written. For example, a shared operation might write its result to the search word in internal register 109 of the lookup hardware logic 108 and to shared register 110. The value field indicates the value used for the matching comparison. For example, the lookup hardware logic 108 might perform a Boolean operation on the unmasked bits of the comparison word against the value in the value field, and determine whether it is a match or not based on the Boolean operation.

[0049] Although Figure 6 The examples involve exact matches with value fields, but the scope of the implementation is not limited to this. In fact, relationships other than exact matches, such as less than, greater than, etc., are also within the scope of the implementation. In practice, multiple value fields can be used and ANDed together to create a range of values, such that a match will be generated by the unmasked bits of the comparison words falling within the defined range. Furthermore, transition rules, entry rules, and entries that are programmatically defined for a given embodiment are also within the scope of the implementation. In other words, fields, the number of fields, the length of data items, etc., can be configured to serve a given embodiment.

[0050] Return to Figure 2The lookup hardware logic 108 generates a comparison word 214, compares the value and mask with the comparison word at action 218, and returns the result, as many times as the number of entries used to generate the comparison word. For a given comparison operation, if the comparison operation is a shared operation, operation flow 200 may include writing the result at action 220 to both search word 210 and shared search word 222. Furthermore, operation flow 200 may include sending a scheduler pointer to the processor scheduler at action 224 based on the result of the comparison operation and the contents of the corresponding entries. In some examples, not every entry causes the scheduler pointer to be sent at action 224; in fact, several sets of entries can be programmed such that only some entries indicate the scheduler pointer. In examples where the comparison operation is marked as a real-time or non-real-time operation, the lookup hardware logic 108 may send the scheduler pointer to the scheduler's real-time or non-real-time interface.

[0051] Once the lookup hardware logic 108 has performed a comparison operation on the comparison word, the search word 210 stored in the internal register 109 of the lookup hardware logic 108 is complete. The lookup hardware logic 108 can then write the search word containing the result of the comparison operation to the data memory (e.g., according to the DMA record of the applicable transfer rules). Figure 8 (Memory 811). For example, the DMA record of the applicable transfer rule can instruct the lookup hardware logic 108 to write the search word to the address range of the packet that also contains data memory. The lookup hardware logic 108 passes the scheduler pointer to the processor scheduler, which can then cause the processor to perform an action on the data memory address range containing the packet and the search word.

[0052] Various embodiments may include advantages over other systems. For example, the transfer rules, entry rules, and entry hierarchy used by the search engine 100 in operation flow 200 may provide additional functionality superior to existing systems. Specifically, engineers can program the transfer rules, entry rules, and entries to accommodate various communication protocols and packet types. As noted above, memory 114 may store multiple different transfer rules, each adapted for a specific communication protocol and / or packet type. In this way, search engine 100 can be configured to perform appropriate actions for any expected packet. This contrasts with other systems that may only process a single packet type. Furthermore, search engine 100 can be constructed using hardware logic, making it efficient in terms of transistor count and semiconductor area.

[0053] Figure 7 This is an illustrated description of an example method 700 for processing groups according to some embodiments. Example method 700 may be performed, for example, by a search engine, such as... Figure 1 The search engine 100.

[0054] Before the search engine begins its operation, the processor core (e.g., Figure 8 The processor core (808) can offload its lookup functionality to the lookup engine. For example, in this example, the processor core can be notified that a packet has been received by the network accelerator. (About...) Figure 8 A more detailed example of a network accelerator is described below. The processor core can verify a thread ID, which may imply or otherwise identify the communication endpoint from which packets are received, the protocol, and possibly the packet type. Using any appropriate information, such as the thread ID, packet scan information, etc., the processor core determines the appropriate transfer rule for the packet. The processor core then sends a pointer to the transfer rule and a pointer to the packet's location in data memory to the lookup engine. (See reference...) Figure 2 An example is described where the processor core sends the transfer rule pointer and data memory address to the lookup engine.

[0055] At action 702, the lookup engine receives a pointer to a first rule. In this example, the first rule identifies the first plurality of bytes of the packet. The example may include transfer rules that identify some, but not all, of the bytes of the packet. Action 702 includes receiving the pointer, and the lookup engine may use the pointer to access the first rule at action 704. For example, the lookup engine may access the first rule from a data address in first memory based on the pointer. The first memory may contain a different memory than the data memory that stores the packet. For example, the first memory may correspond to... Figure 1 The memory 114, and the data memory can correspond to Figure 8 The memory 811.

[0056] At action 706, the lookup engine applies the first rule. Action 706 may involve generating a search word based on multiple bytes identified by the first rule. In one example, the lookup engine may extract the identified bytes from a packet in data storage and write those extracted bytes to register 109. In this example, the search word contains some bytes from the packet, but not all bytes of the packet. In one example, the relevant data may contain some header data that may indicate source or destination information, but in some cases, any packet data may be relevant data. At action 706, the search word written to internal register 109 contains a subset of the packet but is smaller than the complete packet.

[0057] At action 708, the lookup engine accesses the second rule. In one example, such as through a transfer rule containing address information of an entry rule (the second rule), the second rule is referenced in the first rule. The second rule can identify multiple comparison operations to be applied to multiple parts of the search term. The example described above where the entry rule contains many comparison records, where each comparison record identifies one or more bytes to be compared using the entry. In this example, there are as many comparison operations as comparison records and entries.

[0058] At action 710, the lookup engine performs a comparison operation according to the second rule. For example, the lookup engine may include hardware logic (e.g., lookup hardware logic 108) containing Boolean logic gates operable to receive a comparison word and a value from the entry. The Boolean logic gates output the result. In some examples, the lookup engine may store the result along with the search word in internal register 109.

[0059] At action 712, the search engine writes the results of multiple comparison operations to a buffer. For example, the search engine may modify a portion of the search term in action 710 based on the comparison operations, and at action 712, transfer rules and / or other configuration elements cause the search engine to write a portion of the search term to the grouped portion. However, the scope of the implementation may include writing the results of the comparison operations to any appropriate location.

[0060] At action 714, the lookup engine notifies the processor core of the results of multiple comparison operations. In one example, the lookup engine may send a scheduler pointer to the processor core's scheduler (e.g., ...). Figure 8 (Scheduler 807). A specific scheduler pointer can be determined by the results of multiple comparison operations, such as some comparison operations matching or some comparison operations not matching. The scheduler pointer can direct the processor core to the address range that stores the results and identify the operations that can cause the processor core to perform specific actions regarding packets. Examples of actions that can be performed by the processor core include modifying packets, discarding packets, forwarding packets to their destination, etc.

[0061] The scope of the embodiments is not limited to the series of actions 702-714. Instead, other embodiments may add, omit, rearrange, or modify some actions. For example, some embodiments may repeat method 700 for each received group, and may, for example... Figure 9 The SoC 900 computing device receives packets continuously or periodically during normal operation.

[0062] In some examples, the lookup operation described above can be used for various system purposes. In one example, a network accelerator can use lookup table operations to perform Ethernet IPv4 address lookups and routing / forwarding. For example, receiving and processing Ethernet frames with IPv4 addresses, such as according to... Figure 2 and Figure 7 The lookup operation matches the frame's IPv4 address with the IPv4 address configured in memory 114. Such a match allows the lookup engine 100 to indicate to the processor where the frame should be routed or forwarded, such as to another Ethernet port or application processor core.

[0063] In another example use, a lookup operation can facilitate Ethernet Access Control Lists (ACLs). For example, an ACL entry might contain Layer 2-4 fields (e.g., MAC address to TCP / UDP / CDMP port). Each ACL entry can specify whether to allow or deny a matching frame. The lookup table memory 114 can be configured to enforce such ACL entries in priority order. For example, entries can be configured such that a match indicates whether a given frame should be dropped or forwarded.

[0064] In yet another example use case, the lookup operation facilitates CAN frame / Protocol Data Unit (PDU) routing. In one example, a CAN frame or PDU is received and begins processing, as described above. Figure 2 and Figure 7 As described. If the lookup operation matches the CANID and / or CAN port or other CAN fields, the match result can be configured to indicate where the frame or PDU should be routed or forwarded.

[0065] Figure 8 According to some embodiments, a search engine may be included (e.g., Figure 1 A diagrammatic illustration of an example network accelerator 800 (search engine 100). The example network accelerator 800 can be implemented within a system-on-a-chip (SoC), for example... Figure 9 Example SoC900.

[0066] The network accelerator 800 includes multiple processor cores 808, which can include any suitable processor core, whether general-purpose or otherwise, and have any set instruction set size. In one example, each processor core 808 executes firmware to provide processing functionality to the network accelerator 800. For example, the timer manager 801 can perform actions including sending a function instruction and arguments to the scheduler 807 when a timer expires. The scheduler 807 can then pass the function instruction and arguments to one of the processor cores 808. The processor core 808 can fetch instructions from the instruction memory 806 via bus 893 or receive instruction pointers from the direct memory access (DMA) interface 813.

[0067] An application processor core (e.g., in 910) can offload network functions to network accelerator 800, so that the application processor core itself does not have to perform these functions. Configuration interface 116 allows the application processor core to communicate with any component of network accelerator 800. For example, the application processor core can communicate via bus 891, and such communication can be written to register 104 and / or cause instructions to be sent to one of the processor cores 808.

[0068] Security accelerator 802 may perform security functions on behalf of processor core 808. For example, certain types of packets (e.g., Ethernet packets) may be designated as untrusted. In such an example, processor core 808 may cause such packets to be indicated as secure or insecure by security accelerator 802 before further processing.

[0069] Packet Switching Interface (PSI) endpoints 804 and 816 can receive and send packets to and from the network accelerator 800 via buses 892 and 894, respectively. Upon receiving a packet, PSI endpoints 804 and 816 can perform a read operation using the Memory Manager (MMS) 815 to allocate space in the data memory 811. Once space in the data memory 811 is allocated, PSI endpoints 804 and 816 can store the packet in the allocated address range of the data memory 811.

[0070] The network accelerator 800 includes two PSI endpoints 804 and 816 for increased bandwidth, where PSI endpoint 804 is dedicated to Ethernet use and PSI endpoint 816 is dedicated to other packet protocols. However, various embodiments may be adapted to use more or fewer PSI endpoints as needed.

[0071] In some examples, the application processor core can configure the action to be taken for a specific packet by writing lookup table entries to lookup table memory 812. When a packet is received and ready for processing, processor core 808 can cause lookup table engine 100 to perform a lookup operation within a lookup table entry in lookup table memory 114. The lookup operation can trigger subsequent actions, such as events sent by lookup engine 100 to scheduler 807, where such events can trigger actions by processor core 808.

[0072] In some examples, the queue manager 810 can be used by the processor core 808 to manage queues.

[0073] Larger systems implementing network accelerator 800 (e.g., SoC 900) can send interrupts to processor core 808 via interrupt interface 814 and bus 895.

[0074] Priority manager 817 is implemented to prioritize some packets over others based on configuration data from the application processor core. For example, some packets may contain data indicating priority, and priority manager 817 may perform priority functions, such as enforcing the order of data memory allocation for packets based on their priority.

[0075] Various components are coupled within the network accelerator 800 via data switch 809 in a communicative manner.

[0076] Figure 9 This is an illustrative diagram of an example SoC 900 based on some embodiments. A network accelerator 800 may be implemented on the SoC 900, but the scope of implementation may include the network accelerator 800 being implemented in any suitable system for offloading network functions by any suitable processor core.

[0077] In this example of the invention, Ethernet packets may be received by Ethernet packet switch 920. Packets of other protocols, such as Controller Area Network (CAN), may be received by packet switch 925. However, the scope of the implementation may include more or fewer packet switches to handle more or fewer communication protocols as needed.

[0078] Continuing with packet reception, packets from packet switches 920 and 925 are subsequently sent to packet direct memory access (DMA) 930, which in this example formats various packets into one or more formats valid for processing by network accelerator 800. Once packet DMA 930 has formatted the packets, it can send them to network accelerator 800 via buses 892 and 894. Packet DMA 930 can communicate with the rest of SoC 910 via system packet channel 935.

[0079] As noted above, network accelerator 800 can perform network functions on packets, allowing network functions to be offloaded from the rest of SoC 910. Examples of operations that network accelerator 800 can perform include, but are not limited to, reformatting packets from one protocol to another (e.g., Ethernet to CAN and vice versa), dropping packets, forwarding packets to different endpoints, sending payload data from packets to the rest of SoC 910, and so on. For outgoing packets, network accelerator 800 can send such packets to packet DMA 930, to Ethernet packet switch 920, or to packet switch 925 via one of buses 892 or 894. Network accelerator 800 can also send payload data from packets to the rest of SoC 910 via bus 893.

[0080] The rest of the SoC 910 can be configured as needed. For example, the rest of the SoC 910 may include one or more processor cores (e.g., application processor cores, digital signal processing cores, etc.), system memory, memory interfaces, or accelerators.

[0081] This disclosure is described with reference to the accompanying drawings. The drawings are not to scale and are provided for illustrative purposes only. Several aspects of this disclosure are described below with reference to exemplary applications. It should be understood that numerous specific details, relationships, and methods are set forth to provide an understanding of this disclosure. This disclosure is not limited to the described order of actions or events, as some actions may occur in a different order and / or simultaneously with other actions or events. Furthermore, not all described actions or events are required to implement the methods according to this disclosure.

[0082] Unless otherwise indicated, corresponding reference numerals and symbols in different figures generally refer to corresponding parts. Figures are not necessarily drawn to scale. In the figures, the same reference numerals refer to the same elements throughout, and various features are not necessarily drawn to scale. In the following discussion and claims, the terms “comprising,” “having,” “with,” or variations thereof are intended to be inclusive in a manner similar to the term “comprising,” and therefore should be construed as meaning “comprising but not limited to….” Furthermore, the terms “coupled,” “connected,” and / or “coupled” are intended to encompass indirect or direct electrical or mechanical connections or combinations thereof. For example, if a first device is coupled to or electrically coupled to a second device, the connection may be a direct electrical connection or an indirect electrical connection via one or more intervening devices and / or connections. Elements electrically connected to intervening wires or other conductors are considered coupled. Terms such as “top,” “bottom,” “front,” “rear,” “above,” “over,” “below,” “under,” etc., may be used in this disclosure. These terms should not be construed as limiting the position or orientation of structures or elements, but are used to provide spatial relationships between structures or elements.

[0083] The term "semiconductor die" is used herein. A semiconductor device can be a discrete semiconductor device, such as a bipolar transistor, a pair of power FET switches fabricated together on a single semiconductor die, or an integrated circuit having multiple semiconductor devices (e.g., multiple capacitors in an A / D converter). A semiconductor device can contain passive devices such as resistors, inductors, filters, and sensors, or active devices such as transistors. A semiconductor device can be an integrated circuit having hundreds or thousands of transistors coupled to form functional circuitry such as a microprocessor or memory device. A semiconductor device may also be referred to herein as a semiconductor device or an integrated circuit (IC) die.

[0084] The term "semiconductor package" is used herein. A semiconductor device package has at least one semiconductor die electrically coupled to terminals and a package body protecting and covering the semiconductor die. In some arrangements, multiple semiconductor dies may be packaged together. For example, a power metal-oxide-semiconductor (MOS) field-effect transistor (FET) semiconductor device and a second semiconductor device (e.g., a gate driver die or a controller die) may be packaged together to form a single packaged electronic device. Additional components, such as passive components (e.g., capacitors, resistors, and inductors or coils), may be included in the packaged electronic device. The semiconductor die is mounted on a package substrate that provides conductive leads. A portion of the conductive leads forms terminals for the packaged device. In a wire-bonded integrated circuit package, bonding wires couple the conductive leads of the package substrate to bonding pads on the semiconductor die. The semiconductor die may be mounted to a die pad on the package substrate with the device-side surface facing away from the substrate and the back-side surface facing the package substrate. Semiconductor packages can have an encapsulation formed in a molding process from a thermosetting epoxy molding compound or by using an epoxy resin, plastic, or resin that is liquid at room temperature and subsequently cures. The encapsulation provides a hermetically sealed package for a packaged device. An encapsulation process can be used to form the encapsulation in a mold; however, a portion of the leads of the package substrate is not covered during encapsulation, and these exposed lead portions form the terminals of the semiconductor package. Semiconductor packages may also be referred to as "integrated circuit packages," "microelectronic device packages," or "semiconductor device packages."

[0085] Although various examples of this disclosure have been described above, it should be understood that they are presented by way of example only and not by way of limitation. Many changes may be made to the disclosed examples based on the disclosure herein without departing from the spirit or scope of this disclosure. Modifications to the described embodiments are possible within the scope of the claims, and other embodiments are also possible. Therefore, the breadth and scope of the invention should not be limited to any of the examples described above. In fact, the scope of this disclosure should be defined according to the appended claims and their equivalents.

Claims

1. A method comprising: Receive a pointer to a first rule, wherein the first rule identifies a first portion of the packet; According to the pointer, access the first rule from the first memory; Based on the first rule, a search term is generated that includes the first part and omits the second part of the grouping; Based on the first rule, access the second rule, wherein the second rule identifies the comparison operation to be applied to a portion of the search term; Perform the comparison operation according to the second rule; Based on the result of the comparison operation, the grouping is modified; as well as The modified group is written to the second memory.

2. The method of claim 1, wherein for each of a set of comparison operations, the second rule identifies the corresponding portion of the search word to be compared and the corresponding entry from the lookup table.

3. The method of claim 1, wherein the second memory comprises a data memory configured to store a plurality of packets.

4. The method of claim 3, wherein the modified group is written according to the format specified in the first rule.

5. The method of claim 1, wherein receiving the pointer to the first rule comprises receiving the pointer from a processor core.

6. The method of claim 1, wherein the first rule is included in a rule set having a plurality of other rules, wherein the rule set is for a plurality of grouping types.

7. The method of claim 1, wherein accessing the second rule comprises reading the second rule from the first memory according to an offset specified in the first rule.

8. The method of claim 1, further comprising: Events are written to the scheduler of the processor core, where the events correspond to functions to be executed by the processor core.

9. The method of claim 8, wherein the function includes actions performed with respect to the group.

10. A circuit comprising: A first set of registers, wherein each register in the first set of registers is configured to receive data for a lookup operation from a corresponding processor core in a set of processor cores; A first memory, configured to store a first rule set, a second rule set, and a lookup table set; as well as A set of lookup table engines configured to access the first memory and access data from the first set of registers; The first lookup table engine in the set of lookup table engines is further configured to: First data is received from a first processor core, wherein the first data references a first rule in the first rule set used for a first lookup operation and references the location of a group in a second memory; Generate a search term according to the first rule, which includes storing a first subset of the group into a register and omitting storing a second subset of the group into the register; According to the first rule, access the second rule in the second rule set; According to the second rule, a comparison value is generated based on a portion of the search term; According to the second rule, the comparison value is compared with the corresponding entry from the lookup table; and The event is written to the scheduler of the first processor core, at least in part based on the comparison results of the portion of the search word.

11. The circuit of claim 10, wherein the comparison value comprises multiple bytes of the search word.

12. The circuit of claim 10, wherein the first rule corresponds to a first packet protocol, wherein a third rule in the first rule set corresponds to a second packet protocol, and wherein the first lookup table engine is further configured to generate another search term according to the third rule for use in a second lookup operation.

13. The circuit of claim 12, wherein a second lookup table engine in the set of lookup table engines is configured to generate the search term according to the first rule for a third lookup operation, and to generate the other search term according to the third rule for a fourth lookup operation.

14. The circuit of claim 10, wherein the first lookup table engine is further configured to receive the first data from the first processor core via the first set of registers.

15. The circuit of claim 10, further comprising a configuration interface, wherein the configuration interface is configured to receive configuration data and configure the first rule set, the second rule set, and the lookup table according to the configuration data.

16. The circuit of claim 10, further comprising: The second set of registers, wherein the first lookup table engine is configured to place the comparison result in the second set of registers in response to determining that the second rule indicates a shared operation, and wherein the second set of registers is configured to be read by each of the set of processor cores.

17. A network accelerator, comprising: First processor core; A processor scheduler, which is communicatively coupled to the first processor core; as well as A lookup table engine, communicatively coupled to the processor scheduler, wherein the lookup table engine is configured to: Receive first data from the first processor core, and in response, access the first rule and the second rule; Based on the first rule, a search term is generated from the group referenced in the first data, wherein the search term includes a first part of the group and omits a second part of the group; Multiple comparison operations are performed according to the second rule, wherein each comparison operation compares a corresponding part of the search term with a corresponding value from a lookup table entry; as well as The event is written to the processor scheduler in part based on the results of the multiple comparison operations.

18. The network accelerator of claim 17, further comprising: A data storage device configured to store the packets and configured to store the results of the plurality of comparison operations; as well as A lookup table storage is configured to store a plurality of rules including the first rule and the second rule, and is also configured to store the lookup table entries.

19. The network accelerator of claim 18, wherein the first data includes a first pointer to the packet in the data memory and a second pointer to the first rule in the lookup table memory.

20. The network accelerator of claim 17, wherein the first processor core is configured to: The first data is generated in response to the source of the group to include an indication of the first rule.

Images