Hybrid fixed / programmable header parser for network equipment

Abstract

A packet processor of a network device includes a forwarding engine configured to determine an egress network interface via which a packet received by the network device is to be sent. The packet processor also includes a header parser configured to parse header information in a packet received by the network device. The header parser includes a first parsing circuit configured to parse a first portion of a header of the packet and prompt a programmable second parsing circuit to parse a second portion of the header. The first portion of the header has a header structure known to the first parsing circuit. The programmable second parsing circuit includes a configurable circuit system and a memory storing control information that controls the operation of the configurable circuit system to parse the second portion of the header.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 62 / 948,043, filed on December 13, 2019, entitled “Programmable Parsing Unit (PPU)”, which is incorporated herein by reference in its entirety. Technical Field

[0003] The present invention generally relates to network devices, such as network switches, bridges, routers, etc. More particularly, it relates to parsing headers of packets in network devices. Background Art

[0004] Network devices, such as switches, bridges, and routers, forward packets through a network based on addresses in the headers of the packets. Some network devices include multiple ports coupled to different network links. Such network devices typically receive packets via one port and process at least the header of the packet to determine which other port or ports the network device should send the packet via. The network device then forwards the packet to the determined one or more other ports.

[0005] In the process of processing packets, the network device will parse one or more headers of the packet to identify and / or extract information useful for processing the packet. Traditionally, header parsing is performed using a hardware engine that can run at wire-speed. Such a parsing engine is configured to parse headers with a fixed format (and with a fixed length) known at the time of the parsing engine design, and lacks flexibility in supporting new and / or proprietary header types that are unknown at the time of the parsing engine design. On the other hand, programmable implementations of header parsers utilize programmable processors to perform header parsing, but such programmable implementations are generally unable to support wire-speed processing at a commercially reasonable cost. Summary of the invention

[0006] In one embodiment, a network device includes: a plurality of network interfaces configured to be communicatively coupled to a plurality of network links; and a packet processor coupled to the plurality of network interfaces, the packet processor including: a forwarding engine configured to determine an egress network interface through which packets received via the plurality of network interfaces will be sent; and a header parser configured to parse header information in packets received via the plurality of network interfaces. The header parser includes: a first parsing circuit and a programmable second parsing circuit, the first parsing circuit configured to parse a first portion of a header of a packet and prompt the programmable second parsing circuit to parse a second portion of the header, the first portion of the header having a header structure known to the first parsing circuit, the programmable second parsing circuit including: i) a configurable circuit system and ii) a memory storing control information, the control information controlling the operation of the configurable circuit system to parse the second portion of the header.

[0007] In another embodiment, a method for processing a packet in a network device comprises: receiving a packet via a network interface of the network device; parsing a header of the packet, comprising: parsing a first portion of the header by a first parsing circuit, the first portion of the header having a header structure known to the first parsing circuit, prompting a programmable second parsing circuit of the network device to parse a second portion of the header by the first parsing circuit, retrieving control information from a memory of the programmable second parsing circuit by the programmable second parsing circuit, the control information indicating an operation to be performed in conjunction with parsing the second portion of the header, and parsing the second portion of the header by the programmable second parsing circuit, comprising controlling a configurable circuit system of the programmable second parsing circuit using the control information; determining, by a forwarding engine, one or more egress network interfaces via which the packet is to be sent, the one or more egress network interfaces determined using information parsed from the header by one or both of i) the first parsing circuit and ii) the programmable second parsing circuit; and sending the packet via the one or more egress network interfaces determined by the forwarding engine. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figure 1 is a simplified diagram of an example network device employing a hybrid fixed / programmable header parser, according to an embodiment.

[0009] Figure 2 According to an embodiment, the Figure 1 A simplified diagram of an example packet processor in a network device.

[0010] Figure 3 is a schematic diagram of an example Geneve packet format that a hybrid fixed / programmable header parser can process according to an embodiment.

[0011] Figure 4is a schematic diagram of an example network service header encapsulation packet format that can be processed by a hybrid fixed / programmable header parser according to another embodiment.

[0012] Figure 5 is a schematic diagram of an example Ethernet packet format that a hybrid fixed / programmable header parser can process according to one embodiment.

[0013] Figure 6 According to an embodiment Figure 2 A simplified diagram of an example programmable header parser for a packet processor.

[0014] Figure 7 According to an embodiment Figure 6 A simplified diagram of an example computational stage of a programmable header parser.

[0015] Figure 8 According to an embodiment Figure 7 A simplified diagram of an example computing hardware unit of a computing level.

[0016] Fig. 9 is a flow chart of a method of processing packets using a network device including a first parsing circuit and a programmable second parsing circuit according to one embodiment. DETAILED DESCRIPTION

[0017] The following description discloses many different embodiments or examples for implementing different features of the subject matter. Specific examples of components and arrangements are described below to simplify the disclosure. Of course, these are merely examples and are not intended to be limiting. In addition, the disclosure may repeat reference numbers and / or letters in various examples. This repetition is for the purpose of brevity and clarity and does not itself specify the relationship between the various embodiments and / or configurations discussed.

[0018] Before describing various embodiments in more detail, it should be noted that the embodiments are not limiting, as elements in such embodiments may vary. It should also be noted that the specific embodiments described and / or shown here have elements that can be easily separated from the specific embodiments, and optionally combined with any of several other embodiments, or replace elements in any of several other embodiments described here. The terms used here are to describe certain concepts, and the terms are not intended to be limiting. Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood in the field to which the embodiments belong.

[0019] In various embodiments described below, a network device such as a switch, a bridge, a router, etc. includes a hybrid fixed / programmable header parser that parses a header of a packet to identify and / or extract information for processing the packet. The hybrid fixed / programmable header parser includes a fixed header parser that is configured to parse a fixed first set of header types and / or headers having a fixed predefined length. In some embodiments, the fixed header parser is configured to parse a first set of header types that is fixed at the time of manufacture and cannot be changed / updated in the field. As an illustrative example, the first set of header types that can be parsed by the fixed header parser includes standardized and / or widely used header types, and optionally includes one or more proprietary header types that are known at the time of manufacture.

[0020] The hybrid fixed / programmable header parser also includes a programmable header parser that can be programmed to parse a second set of one or more header types that the fixed header parser cannot parse. In some embodiments, the programmable header parser can be programmed and / or reprogrammed after manufacture (e.g., "in the field") to parse different and / or additional header types that the hybrid fixed / programmable header parser cannot parse at the time of manufacture.

[0021] In some embodiments, the programmable header parser can be programmed to parse one or both of i) a variable length header and ii) a fixed length header. As an illustrative example, the second set of header types that the programmable header parser can be programmed to parse includes: one or more proprietary header types that the fixed header parser cannot parse. As another example, the second set of header types that the programmable header parser can be programmed to parse includes: one or more header types that are adopted after the header parser is designed or manufactured (e.g., adopted by the industry, by a standards committee, etc.). As yet another example, the second set of header types that the programmable header parser can be programmed to parse includes: one or more variable length header types that the fixed header parser cannot parse.

[0022] In some embodiments, the fixed header parser may also be programmed to a more restricted degree than the programmable header parser. For example, although the fixed header parser is also programmable to some extent, the fixed header parser cannot be programmed to parse some types of headers that the programmable header parser can be programmed to process. As an illustrative example, although the fixed header parser is also programmable to some extent, the fixed header parser cannot be programmed to parse variable length headers, while the programmable header parser can be programmed to parse variable length headers. In some embodiments, the fixed header parser can be programmed "in the field", but cannot be programmed to parse some types of headers that the programmable header parser can be programmed to parse.

[0023] Figure 1 1 is a simplified block diagram of an example network device 100 including a hybrid fixed / programmable header parser 104 according to an embodiment. The network device 100 typically forwards packets between two or more computer systems, network segments, subnets, etc. For example, in one embodiment, the network device 100 is a router. However, it is noted that the network device 100 is not necessarily limited to a particular protocol layer or a particular networking technology (e.g., Internet Protocol). For example, in other embodiments, the network device 100 is suitably a bridge, a switch, a virtual private network (VPN) concentrator, etc.

[0024] The network device 100 includes a plurality of network interfaces (eg, ports) 108 configured to be coupled to corresponding network links. The network interfaces 108 (sometimes referred to herein as "ports" for brevity) are configured to receive packets and send packets via corresponding network links.

[0025] The network device 100 also includes a packet memory 112 for storing packets received via the network port 108 while the network device 100 processes the packets until the network device 100 sends the packets via the network port 108 .

[0026] The network device 100 also includes a packet processor 116 coupled to the packet memory 112 and the port 108. The packet processor 116 generates respective packet descriptors (sometimes referred to herein as "descriptors") for packets received via the port 108. Each descriptor includes a data unit corresponding to a packet. The descriptor includes, among other things, information obtained from a header of the packet, and the descriptor is generally processed by the packet processor 116 to determine the port 108 (sometimes referred to as a "destination port") through which the packet corresponding to the descriptor is to be sent, and to cause the packet to be sent via the determined destination port 108. In some embodiments, the descriptor includes information corresponding to the packet that is not extracted from the header of the packet, such as an indication of the location in the memory 112 where the packet is stored, an indication of an action to be taken on the packet (e.g., an indication of how to modify the header of the packet, an indication to discard the packet, etc.).

[0027] In one embodiment, the packet processor 116 includes a forwarding engine (not shown) configured to analyze the header information of the packet (contained in the descriptor) to determine the port 108 through which the packet is to be transmitted. As an illustrative example only, the forwarding engine is configured to use the destination address in the header of the packet (the destination address has been extracted from the header and stored in the descriptor corresponding to the packet) to perform a lookup in a forwarding database (not shown) that stores forwarding information indicating the correspondence between the destination address and the port 108 to determine the specific port (or ports) 108 through which the packet is to be transmitted. As another illustrative example, the forwarding engine is configured to use the virtual local area network identifier (VLAN ID) in the header of the packet (the VLAN ID has been extracted from the header and stored in the descriptor corresponding to the packet) to perform a lookup in a forwarding database (not shown) (e.g., the same forwarding database described above or a different forwarding database) that stores forwarding information indicating the correspondence between the VLAN ID and the port 108 to determine the specific port set 108 for the packet through which the packet is to be transmitted. According to one embodiment, a forwarding engine (not shown) is configured to store an ID of a destination port 108 (or a set of multiple destination ports) in a packet descriptor corresponding to the packet.

[0028] Other example functions performed by the packet processor 116 include one or any suitable combination of two or more of the following functions (or none of the following functions): i) modifying the header of the packet (e.g., updating the next hop address, adding a tunnel header, removing a tunnel header, etc.), ii) classifying the packet, iii) metering, such as for quality of service control, etc.

[0029] In some embodiments, the network device 100 includes a transmit queue 120 corresponding to the port 108. According to one embodiment, after the packet processor 116 determines the destination port 108 for the packet, the packet processor 116 enqueues a descriptor for the packet (or another suitable data unit corresponding to the packet) into the transmit queue 120 corresponding to the destination port 108. When the descriptor (or other suitable data unit) reaches the head of the transmit queue 120, the corresponding packet is read from the packet memory 112 and transmitted via the destination port 108.

[0030] According to one embodiment, the hybrid fixed / programmable header parser 104 is a component of the packet processor 116. The hybrid fixed / programmable header parser 104 includes a fixed header parser and a programmable header parser. According to some embodiments, the fixed header processor is configured to parse a fixed set of first header types and / or headers with a fixed predefined length. As an illustrative example, the first set of header types that can be parsed by the fixed header parser includes header types that are known at the time of manufacture, such as one or more of i) standardized and / or widely used header types, ii) one or more proprietary header types, etc.

[0031] The hybrid fixed / programmable header parser 104 also includes a programmable header parser that can be programmed to parse a second set of one or more header types that the fixed header parser cannot parse. In some embodiments, the programmable header parser can be programmed to parse one or both of i) a variable length header and ii) a fixed length header. As an illustrative example, the programmable header parser can be programmed to parse a second set of header types including one or more proprietary header types that the fixed header parser cannot parse. As another example, the programmable header parser can be programmed to parse a second set of header types including one or more variable length header types that the fixed header parser cannot parse.

[0032] Although the fixed header parser is described as "fixed", according to some embodiments, the fixed header parser may also be programmed to a more restricted degree than the programmable header parser. For example, although the fixed header parser is also programmable to some extent, the fixed header parser cannot be programmed to parse some types of headers that the programmable header parser can be programmed to parse. As an illustrative example, although the fixed header parser is also programmable to some extent, the fixed header parser cannot be programmed to parse variable length headers, while the programmable header parser can be programmed to parse variable length headers. In some embodiments, the fixed header parser can be programmed "in the field", but cannot be programmed to parse some types of headers that the programmable header parser can be programmed to parse.

[0033] In some embodiments, the fixed header parser cannot parse the header type due to a design defect or a manufacturing defect. Therefore, in some embodiments, the programmable header parser can be programmed to provide a "work around" for one or more defects in the fixed header parser, thereby salvaging a packet processor 116 that would otherwise become unusable or unsuitable for sale.

[0034] Figure 2 According to one embodiment Figure 1For explanation purposes, reference is made to a schematic diagram of an example packet processor 200 corresponding to the packet processor 116 of FIG. Figure 1 Describes Figure 2 However, in other embodiments, Figure 1 The packet processor 116 corresponds to another suitable packet processor different from the packet processor 200, and / or the packet processor 200 is included in a different Figure 1 in another suitable network device of the network device 100.

[0035] In one embodiment, the packet processor 200 is implemented using a pipeline architecture and includes a packet processing pipeline 220. According to one embodiment, the packet processing pipeline 220 includes a plurality of pipeline stages 224 in a pipeline arrangement, wherein at least some of the pipeline stages 224: i) receive packet descriptors from a previous pipeline stage 224 in the pipeline, ii) process the packet descriptors, and iii) provide at least some of the packet descriptors to a next pipeline stage 224 in the pipeline. For example, one of the pipeline stages 224 corresponds to a forwarding engine as described above. As another example, another pipeline stage 224 is configured to modify a header of a packet (e.g., update a next hop address, add a tunnel header, remove a tunnel header, etc.). As yet another example, another pipeline stage 224 is configured to perform a metering function, e.g., for quality of service control, etc.

[0036] Stage 224b (sometimes referred to herein as a "parser stage") corresponds to the hybrid fixed / programmable header parser described above. Although parser stage 224b is shown as being in the second position in pipeline 220 according to the ordering of stages 224 in pipeline 220 (e.g., parser stage 224b is located after the first position (stage 224a) and before the third position (stage 224c)), in other embodiments, parser stage 224b is in another suitable position in pipeline 220.

[0037] In one embodiment, stage 224a generates a corresponding packet descriptor for the received packet and provides the generated packet descriptor to parser stage 224b. For example, the descriptor provided by stage 224a to parsing stage 224b includes: an indicator of the location of the packet corresponding to the descriptor stored in packet memory 112. As another example, the descriptor provided by stage 224a to parsing stage 224b additionally or alternatively includes: an indicator of the port 108 via which the packet corresponding to the descriptor was received.

[0038] In another embodiment, parser stage 224b generates a packet descriptor. For example, for each received packet, stage 224a provides parser stage 224b with an indication of the location in packet memory 112 where the packet is stored and / or an indication of the port 108 via which the packet was received, and parser stage 224b generates a descriptor for the packet including one or both of an indication of the location in packet memory 112 where the packet is stored and an indication of the port 108 via which the packet was received.

[0039] According to one embodiment, the parser stage 224b is configured to: i) identify fields in a header of a packet, ii) extract information from the identified fields, iii) store some of the extracted information in a descriptor, iv) calculate further information using some of the extracted information, and v) store the calculated further information in the descriptor.

[0040] The parser stage 224b includes a fixed header parser 244 as described above. For example, according to some embodiments, the fixed header processor 244 is configured to parse a fixed first header type set, and / or a header having a fixed predefined length. The fixed header parser 244 receives header information from a received packet and parses at least a portion of the received header information. For example, the fixed header parser 244 is configured to: i) identify a first field in the header information (the identified field corresponds to a fixed first header type set), ii) extract information from the identified first field, and iii) store some of the extracted information in a descriptor corresponding to the packet. In some embodiments, the fixed header parser 244 is also configured to: i) use some of the extracted information to calculate further information, and ii) store the calculated further information in the descriptor.

[0041] In some embodiments, the fixed header processor 244 is further configured to determine when the header information includes one or more header types, wherein the one or more header types are to be parsed by a programmable header parser 248 coupled to the fixed header parser. In some embodiments, the one or more header types to be parsed by the programmable header parser 248 include: one or more header types that the fixed header processor 244 is unable to parse. Additionally or alternatively, according to some embodiments, the one or more header types to be parsed by the programmable header parser 248 include: header types that the fixed header parser 244 is capable of parsing, but are still to be processed by the programmable header parser 248. As an illustrative example, it may be determined that the fixed header parser 244 includes a defect that causes the fixed header parser 244 to incorrectly (or suboptimally) parse a known header in at least some cases, and therefore determine that the programmable header parser 248 parses the known header instead.

[0042] Fixed header parser 244 includes trigger circuit 252 configured to: determine whether the packet includes one or more header types to be parsed by programmable header parser 248; and in response to determining that the packet includes one or more header types to be parsed by programmable header parser 248, prompt programmable header parser 248 to parse the one or more header types included in the packet. For example, trigger circuit 252 is configured to: identify information in a first portion of a header (where fixed header processor 244 is capable of parsing the first portion of the header) that indicates the presence of a second header portion that is located after the first header portion, and where programmable header parser 248 is to parse header information that is located after the first header portion. Therefore, the information in the first portion of the header (which indicates the presence of the second header portion that is located after the first header portion) indicates to fixed header processor 244 that the header information, at a position corresponding to the end of the first portion of the header, includes one or more header types that programmable header parser 248 is to parse.

[0043] As an illustrative example only, one or more first fields in the header information may indicate that the payload portion of the packet begins at a different offset than the end of the first header portion that the fixed header processor 244 is able to parse, meaning that a second header portion exists between the first header portion and the payload. For example, the fixed header processor 244 is able to process header information through the first header portion, but cannot process header information outside of the first header portion in the packet. Therefore, the information indicating the offset at which the payload portion of the packet begins indicates to the trigger circuit 252 that the header information, at a location in the packet corresponding to the end of the first header portion, includes one or more header types that the fixed header processor 244 cannot parse.

[0044] As another illustrative example, the trigger circuit 252 is configured to determine that the header information includes one or more header types located at a specific position in the packet that the fixed header processor 244 cannot parse when the port field in the first header portion is set to a specific value (or one of multiple specific values). Figure 3 is a diagram of an example Geneve packet format 300 defined by draft-ietf-nvo3-geneve-08 “Geneve: Generic Network Virtualization Encapsulation” of the Internet Engineering Task Force (IETF) on October 7, 2018. The packet format 300 includes a first header portion 304 that the fixed header processor 244 can parse, and a second header portion 308 that the programmable header parser 248 can parse.

[0045] First header portion 304 includes outer Ethernet header 324, outer Internet Protocol version 4 (IPv4) header 328, and outer User Datagram Protocol (UDP) header 332. Second header portion 308 includes Geneve header 364. Packet 300 also includes one or more inner headers and payload 372.

[0046] The outer UDP header 332 includes a destination port field 384, which is set to a specific value (e.g., 6081 or another suitable value) to indicate that the Geneve header 364 follows the outer UDP header 332. Therefore, according to one embodiment, in response to the trigger circuit 252 determining that the destination port field 384 is set to a specific value (e.g., 6081 or another suitable value), the trigger circuit 252 determines that another header (i.e., the Geneve header 364) that the fixed header processor 244 cannot parse follows the outer UDP header 332 at a position corresponding to the end of the outer UDP header 332.

[0047] The Geneve header 364 is a variable length header. More specifically, the Geneve header 364 includes: i) a variable length option field 392 having a variable length, and ii) a length field 394 indicating the length of the variable length option field 392. According to one embodiment, the programmable header parser 248 is configured to extract the length information from the length field 394 and use the extracted length information to determine the length of the variable length option field 392.

[0048] Although illustrative examples are discussed above in which the fixed header processor 244 (e.g., the trigger circuit 252) analyzes the payload offset information, and / or the port information in the first portion of the header to determine that the packet includes the second header portion that should be parsed by the programmable header parser 248, in other embodiments, the fixed header processor 244 (e.g., the trigger circuit 252) analyzes other suitable information in the first portion of the header to determine that the packet includes the second header portion that should be parsed by the programmable header parser 248. In other embodiments, the fixed header processor 244 (e.g., the trigger circuit 252) analyzes other suitable information in the second portion of the header to determine that the second header portion should be parsed by the programmable header parser 248 (e.g., the fixed header processor 244 (e.g., the trigger circuit 252) is capable of analyzing some information in the second portion of the header to determine that the second header portion should be parsed by the programmable header parser 248).

[0049] Figure 4Schematic diagram of an example network service header (NSH) encapsulation packet format 400 as defined by Request for Comment (RFC) 8300, Internet Engineering Task Force (IETF) "Network Service Header (NSH)" in January 2018. Packet format 400 includes a transport encapsulation header portion 404, an NSH header portion 408, and an original packet portion 412. In one embodiment, fixed header processor 244 is capable of parsing a subset of NSH header portion 408 and transport encapsulation header portion 404, while programmable header parser 248 is capable of processing another subset of NSH header portion 408, which will be described in more detail below.

[0050] The NSH header portion 408 includes a base header 424, a service path header 428, and one or more optional context headers 432. In one embodiment, the fixed header processor 244 is capable of parsing at least the base header 424 and the service path header 428.

[0051] The basic header 424 includes an Operation, Administration and Maintenance (OAM) bit field 444, a length field 448, and a metadata (MD) type field 452. The OAM bit field 444 is set to a specific value (e.g., one) to indicate that the packet 400 is an OAM packet. When the OAM bit field is set to a specific value (e.g., one), the NSH header 408 (e.g., (multiple) context headers 432) can be used for path identification information that is required to implement the service path and monitor and troubleshoot the service chain end-to-end via service-specific OAM messages. Administrators can use the information in the NSH header 408 (e.g., (multiple) context headers 432) (e.g., via a traffic analyzer) to verify the path details of the packets being forwarded along the service path (e.g., accounting, ensuring correct links, providing reports, etc.). In one embodiment, when the fixed parser 244 (e.g., the trigger circuit 252) determines that the OAM bit field 444 is set to a specific value (e.g., one), the fixed parser 244 (e.g., the trigger circuit 252) determines that the programmable header parser 248 is to parse at least a portion of the NSH header 408 (e.g., at least the (multiple) context headers 432).

[0052] The basic header 424 also includes a length field 448, which indicates the total length of the NSH header 408. In some embodiments, certain values ​​of the length field 448 indicate that the context header(s) 432 have a variable length format and should therefore be parsed by the programmable header parser 248. Thus, in some embodiments, when the fixed parser 244 (e.g., the trigger circuit 252) determines that the length field 448 is set to any value in a set of one or more specific values, the fixed parser 244 (e.g., the trigger circuit 252) determines that the programmable header parser 248 is to parse the context header(s) 432.

[0053] The basic header 424 also includes a metadata (MD) field 452 that indicates the format of the NSH header 408 (e.g., the format of the context header(s) 432) in addition to the basic header 424 and the service path header 428. For example, a first value (e.g., 0x1) of the MD field 452 indicates that the context header(s) 432 have a fixed length format, while a second value (e.g., 0x2) of the MD field 452 indicates that the context header(s) 432 have a variable length format. Therefore, in some embodiments, when the fixed parser 244 (e.g., the trigger circuit 252) determines that the MD field 452 is set to the second value (e.g., 0x2), the fixed parser 244 (e.g., the trigger circuit 252) determines that the programmable header parser 248 is to parse the context header(s) 432.

[0054] Figure 5 is a schematic diagram of an example Ethernet packet format 500 with a Cisco Metadata (CMD) tag. The packet format 500 includes an Ethernet header 504, as well as a payload and a cyclic redundancy check (CRC) portion 512. In one embodiment, the fixed header processor 244 is capable of parsing the first portion of the Ethernet header 504, but is unable to parse the second portion of the Ethernet header 504. On the other hand, the programmable header parser 248 is capable of processing the second portion of the Ethernet header 504, which will be described in more detail below.

[0055] The Ethernet header 504 includes a destination media access control (MAC) address field 524, a source MAC address field 528, an 802.1Q tag 532, a CMD tag 536, and an Ethertype field 540. The CMD tag 536 includes a CMD Ethertype field 564, a version field 568, a length field 572, a security group tag (SGT) option type field 576, an SGT value field 580, and optionally one or more other CMD option fields 584. The CMD Ethertype field 564 is located in the Ethernet header 504 at a position that corresponds to the position of the Ethertype field 540 in an Ethernet header that omits the CMD tag 536. The CMD Ethertype field 564 is set to a specific value (e.g., 0x8909), which indicates that the Ethernet header 504 includes the CMD tag 536. Thus, in some embodiments, when the fixed parser 244 (e.g., the trigger circuit 252) determines that the CMD Ethertype field 564 is set to a particular value (e.g., 0x8909), the fixed parser 244 (e.g., the trigger circuit 252) determines that the programmable header parser 248 is to parse at least some fields of the CMD tag 536, such as, for example, i) at least the length field 572, the SGT option type field 576, the SGT value field 580, and (multiple) other CMD option fields 584 (if present).

[0056] The length field 572 indicates the length of the CMD tag 536 following the length field 572. In some embodiments, certain values ​​of the length field 572 indicate that there are one or more other CMD fields 584 following the SGT value field 580 and should therefore be parsed by the programmable header parser 248. Thus, in some embodiments, when the fixed parser 244 (e.g., the trigger circuit 252) determines that the length field 572 is set to any value in a set of one or more specific values, the fixed parser 244 (e.g., the trigger circuit 252) determines that the programmable header parser 248 is to parse at least one or more other CMD fields 584 following the SGT value field 580.

[0057] In another embodiment where an Internet Protocol version 6 (IPv6) packet is encapsulated in an Ethernet frame, when the fixed parser 244 (e.g., the trigger circuit 252) determines that the EtherType field in the Ethernet header is set to a specific value (e.g., 0x88DD or another suitable value), the fixed parser 244 (e.g., the trigger circuit 252) determines that the programmable header parser 248 is to parse the IPv6 header of the IPv6 packet. In an illustrative embodiment, the IPv6 header corresponds to a header that is a Generalized Segment Routing over IPv6 (G-SRv6) header that includes one or more generalized segment identifiers (G-SIDs), and the programmable header parser 248 is configured to extract the one or more G-SIDs and store the extracted one or more G-SIDs in a descriptor corresponding to the packet.

[0058] Reference again Figure 2 In response to the fixed header processor 244 (e.g., the trigger circuit 252) determining that the header information includes one or more header types that the fixed header processor 244 cannot parse, the fixed header processor 244 (e.g., the trigger circuit 252) is configured to generate an enable signal that prompts the programmable header parser 248 to further parse the header information, for example, to parse portions of the header information that the header processor 244 did not fully parse and / or failed to fully parse.

[0059] Programmable header parser 248 receives header information corresponding to the packet and parses portions of the header information that were not parsed and / or not fully parsed by header processor 244. In some embodiments, the header information is received from fixed header parser 244. In other embodiments, the header information is received from another component of packet processor 220, such as stage 224a.

[0060] Parsing performed by programmable header parser 248 includes identifying fields in the header information and extracting information from one or more identified fields. In some embodiments, parsing performed by programmable header parser 248 also includes calculating further information using information extracted from one or more identified fields.

[0061] The programmable header parser 248 also receives a descriptor corresponding to the packet. In one embodiment, the parsing performed by the programmable header parser 248 further includes storing information extracted from the header information in the descriptor. In other embodiments, additionally or alternatively, the parsing performed by the programmable header parser 248 includes storing at least some of the calculated further information in the descriptor.

[0062] In some embodiments, programmable header parser 248 receives information indicating a position within the header information at which programmable header parser 248 is to begin parsing (sometimes referred to herein as "offset information"). In some embodiments, the offset information is received from fixed header parser 244 (e.g., trigger circuit 252 is configured to generate the offset information).

[0063] In some embodiments, the set of header types that fixed header parser 244 can parse is fixed at the time of manufacture and cannot be changed / updated in the field. In some embodiments, fixed header parser 244 cannot parse certain types of headers and cannot be reprogrammed / updated in the field to parse those certain types of headers. For example, fixed header parser 244 cannot parse variable length headers and cannot be reprogrammed / updated in the field to parse variable length headers.

[0064] On the other hand, programmable header parser 248 can be programmed (e.g., at the time of manufacture) to parse headers that fixed header parser 244 is not able to fully parse. In some embodiments, programmable header parser 248 can optionally be reprogrammed in the field to parse different and / or additional header types that parsing stage 224b is not able to parse at the time of manufacture. In some embodiments, programmable header parser can be programmed to parse one or both of: i) variable length headers, and ii) fixed length headers.

[0065] Although fixed header parser 244 is described as "fixed", according to some embodiments, fixed header parser 244 may also be programmed to a more restricted degree than programmable header parser. For example, although fixed header parser 244 is also programmable to some extent, fixed header parser 244 cannot be programmed to parse some types of headers that programmable header parser 248 can be programmed to parse. As an illustrative example, although fixed header parser 244 is also programmable to some extent, fixed header parser 244 cannot be programmed to parse variable length headers, while programmable header parser 248 can be programmed to parse variable length headers. In some embodiments, fixed header parser 244 can be programmed "in the field", but cannot be programmed to parse some types of headers that programmable header parser 248 can be programmed to parse.

[0066] In some embodiments, the fixed header parser 244 is unable to parse a header type due to a design defect or a manufacturing defect. Therefore, in some embodiments, the programmable header parser 248 can be programmed to provide a "workaround" for one or more defects in the fixed header parser 244, thereby salvaging a packet processor 200 that would otherwise become unusable or unsuitable for sale. For example, according to one embodiment, the defective fixed header parser 244 is configured to parse those (multiple) portions of the header that the defective fixed header parser 244 is able to parse correctly despite the defect(s), and then the programmable header parser 248 is configured to parse those (multiple) portions of the header that the defective fixed header parser 244 is unable to parse correctly.

[0067] In various embodiments, pipeline 220 is configured to parse as much of the packet header as fixed header parser 244 can (or should) parse in a first parsing operation and to continue parsing unparsed segments of the packet header using programmable header parser 248 .

[0068] Figure 6 is a simplified diagram of an example programmable header parser 600 according to one embodiment. In one embodiment, the programmable header parser 600 is Figure 2 In another embodiment, the programmable header parser 600 is included in Figure 1 In other embodiments, Figure 1 A hybrid fixed / programmable header parser 104, and / or Figure 2 The programmable header parser 248 includes a suitable programmable header parser different from the programmable header parser 600. Similarly, in some embodiments, the programmable header parser 600 is used in a different Figure 1 The network device 100 may be a suitable network device, and / or may be different from the network device 100 Figure 2 The programmable header parser 600 is used in a suitable packet processor of the packet processor 200. In some embodiments, the programmable header parser 600 is not used in conjunction with a fixed header parser.

[0069] Programmable processor 600 includes one or more computation stages 604, and a descriptor modifier 608. Figure 6 Three computing stages 604 are shown in FIG. 6 , but in other embodiments, the programmable processor 600 includes a different suitable number of computing stages 604 other than three (eg, one, two, four, five, etc.).

[0070] As will be described in more detail below, each computation stage 604 can be programmed to perform desired operations associated with parsing header information. Descriptor modifier 608 is configured to modify a descriptor associated with a packet as specified by descriptor modification information generated by computation stage 604. In some embodiments, computation stage 604 is configured to: i) extract length information from a length field of a variable length header, and ii) parse a variable amount of header information, the variable amount depending on the extracted length information. In other embodiments, computation stage 604 is not capable of parsing a variable length header having a length field indicating the length of the variable length header.

[0071] The computation stages 604 are arranged in series so that the output of one computation stage 604 is provided as an input to another computation stage 604. In addition, the computation stages 604 are arranged in a feedback arrangement so that the output of the last computation stage 604 is optionally provided as an input to the first computation stage 604. For example, the output of computation stage 604c is provided as an input to computation stage 604a. In other embodiments, the computation stages of the programmable parser are not arranged in series. For example, in other embodiments, the computation stages of the programmable parser operate in parallel.

[0072] The computation stage 604 receives various information and / or signals from the fixed parser 244 (and / or from other circuitry in the packet processor 200, such as stage 224a). For example, according to one embodiment, the computation stage 604a receives an enable signal prompting the computation stage 604a to begin operation. The computation stage 604a also receives header information corresponding to the packet, and offset information indicating the location within the header information at which the programmable parser 600 is to begin parsing. In some embodiments, the computation stage 604a also receives metadata from other circuitry in the packet processor 116 / 200 that corresponds to the packet being parsed. In some embodiments, the metadata includes information provided by the fixed header parser (e.g., Figure 2 For example, metadata includes data generated by a fixed header parser (e.g., Figure 2 The metadata may include data extracted from the header of the packet (and / or data calculated from (and / or determined using data extracted from) the fixed header parser 244 of the programmable parser 600). This may enable the programmable parser 600 to skip re-extraction and / or re-calculation of data that has already been extracted / calculated by the hardware parser. In some embodiments where the packet processor 116 includes a pipeline such as the pipeline 220, the metadata may additionally or alternatively include data generated by a previous stage(s) in the pipeline (such as the stage 224a).

[0073] In some embodiments where the programmable parser 600 includes a plurality of computation stages 604, the computation stages 604 are configured to iteratively process the header information. In other embodiments where the programmable parser 600 includes a plurality of computation stages 604, respective computation stages 604 are additionally or alternatively configured to process respective portions of the header information. In other embodiments, the computation stage(s) 604 are additionally or alternatively configured to operate as a state machine, where the computation stages 604 exchange state information.

[0074] In some embodiments where the computation stage(s) 604 are configured to iteratively process header information and / or operate as a state machine, the computation stage(s) 604 are provided with initialization information by, for example, the fixed parser 244, or additionally / alternatively by other circuitry in the packet processor 116 / 200. As an illustrative example, the computation stage(s) 604 are provided with initial values ​​of one or more counting parameters. For example, one of the one or more counting parameters indicates a particular iteration in a set of ordered iterations to be performed by the computation stage(s) 604. As another example, one of the one or more counting parameters indicates a particular portion of the header information being processed. As yet another example, one of the one or more counting parameters indicates a particular state in a set of states of a state machine implemented by the computation stage(s) 604.

[0075] According to one embodiment, as part of processing header information, each calculation stage 604 is configured to selectively decrement the count. According to another embodiment, as part of processing header information, each calculation stage 604 is configured to selectively increment the count. According to another embodiment, as part of processing header information, each calculation stage 604 is configured to selectively set the count to a specific value. In one embodiment, as part of processing header information, each calculation stage 604 can be programmed to alternately decrement or increment the count. In another embodiment, as part of processing header information, each calculation stage 604 can be programmed to selectively i) decrement the count, ii) increment the count, or iii) set the count to a specific value.

[0076] In some embodiments where initialization information is provided for computation stage(s) 604 and computation stage(s) 604 are configured to implement a state machine, the initialization parameters include initial state information for the state machine.

[0077] In some embodiments where initialization information is provided to computation stage(s) 604, at least some of the initialization information corresponds to information contained in one or more of header information, offsets, and metadata.

[0078] Each computation stage 604 generates descriptor modification information (sometimes referred to herein as a "scratchpad") to instruct the descriptor modifier 608 how to modify the descriptor. In some embodiments, each of at least some of the computation stages 604 provides the descriptor modification information to another computation stage 604, which may modify the descriptor modification information or output the descriptor modification information unchanged. In other embodiments, the descriptor modification information is stored in one or more registers (or another suitable memory device) accessible by the descriptor modifier 608.

[0079] Each of at least some of the computation stages 604 generates (multiple) outputs that are used as (multiple) inputs to another computation stage 604. As an example, each of at least some of the computation stages 604 is configured to generate an enable signal that prompts another computation stage 604 to begin processing header information. As another example, each of at least some of the computation stages 604 is configured to generate offset information indicating a position within the header information at which another computation stage 604 begins processing the header information. As another example, each of at least some of the computation stages 604 is configured to generate count information, such as described above, and provide the count information to another computation stage 604. As another example, each of at least some of the computation stages 604 is configured to generate status information, such as described above, and provide the status information to another computation stage 604. As yet another example, each of at least some of the computation stages 604 is configured to generate descriptor modification information, such as described above, and provide the descriptor modification information to another computation stage 604. Providing descriptor modification information to another stage is an example of one computation stage 604 providing preliminary parsing results to another computation stage 604, which may then use the preliminary parsing results to further process the header information.

[0080] although Figure 6 Computational stages 604 are shown outputting header information, metadata, and a scratch pad bus, but in various other embodiments, any suitable combination of one, two, or more of i) header information, ii) metadata, and iii) a scratch pad bus are provided in parallel with at least some of the computational stages 604, rather than via other computational stages 604.

[0081] Figure 7 is a simplified diagram of an example computing stage 700 according to one embodiment. In one embodiment, computing stage 700 and Figure 6 In other embodiments, Figure 6 Each computing level 604 corresponds to a suitable computing level different from computing level 700. Similarly, in some embodiments, in a computing level different from Figure 6 The programmable parser 600 is suitable for use in the computing stage 700 of the programmable parser.

[0082] The calculation stage 700 includes a selector circuit 704 configured to select a subset of the header information received by the calculation stage 700. In one embodiment, the selector circuit 704 selects different subsets of the header information based on the offset information received by the calculation stage 700. As an illustrative example only, the selector circuit 704 selects a 32-byte subset of the header information at a starting point that is determined at an interval of two bytes specified by the offset information. In other embodiments, a suitable size other than 32 bytes is selected (e.g., 16 bytes, 48 ​​bytes, etc.), and / or the interval of the selected starting point is a suitable interval other than two bytes (e.g., one byte, four bytes, etc.).

[0083] In one embodiment, the key generator circuit 708 is configured to generate a lookup key for a ternary content addressable memory (TCAM) 712. According to various embodiments, the key generator circuit 708 is configured to generate the lookup key by selecting bits from one, two, or more of the following: i) a subset of header information selected by the selector circuit 704, ii) descriptor modification information (scratch pad), iii) metadata, and iv) count information. In some embodiments, the key generator circuit 708 is controlled by state information such that the key generator circuit 708 generates the lookup key by selecting corresponding sets of bits from different combinations of one, two, or more of the following: i) a subset of header information selected by the selector circuit 704, ii) descriptor modification information (scratch pad), iii) metadata, and iv) count information according to the state information. In other embodiments, the key generator circuit 708 is additionally or alternatively controlled by state information such that the key generator circuit 708 generates a lookup key by selecting different sets of bits from one, two, or more of the following: i) a subset of the header information selected by the selector circuit 704, ii) descriptor modification information (scratch pad memory), iii) metadata, and iv) count information.

[0084] In one embodiment, TCAM 712 is configured to compare the key with corresponding content stored in corresponding entries of TCAM 712 and, when a match is found, output an index corresponding to the entry containing the match.

[0085] The index output by the TCAM 712 is used to look up an entry in a memory 716 (e.g., a register file, a random access memory (RAM), a flash memory, etc.). The memory 716 includes corresponding control information in a corresponding entry of the memory 716. In one embodiment, the control information retrieved from the memory 716 using the index is then used to control the computing hardware unit 720. Specifically, different control information controls the computing hardware unit 720 to perform corresponding different processing operations for other inputs of the computing hardware unit 720, such as any appropriate combination of one or two or more of the following: i) a subset of header information selected by the selector 704, ii) descriptor modification information (scratch pad memory), iii) metadata, and iv) counting information.

[0086] The contents of TCAM 712 and memory 716 are programmable, and the operation of compute stage 700 varies according to the contents of TCAM 712 and memory 716. In some embodiments, the contents of TCAM 712 and memory 716 can be reprogrammed (e.g., after initial programming is performed during manufacturing) so that the operation of compute stage 700 can be changed after manufacturing, e.g., "in the field." Because fixed header parsers (e.g., Figure 2 The fixed header parser 244) parses some parts of the header, thereby reducing the amount of the header that needs to be parsed by the programmable parser, thereby helping to reduce the amount of resource(s) of the programmable header parser, such as the size of the TCAM 712, the size of the memory 716, the complexity (and / or silicon area) of the computational unit 720, etc., compared to a programmable header parser of a similar structure that must parse the entire header.

[0087] According to various embodiments, examples of operations performed by the calculation unit 720 include: incrementing the count information, decrementing the count information, setting the count information to a specific value, etc. In some embodiments, the control information controls the calculation unit 720 to perform different operations (e.g., any suitable combination of two or more of incrementing, decrementing, setting to a specific value, etc.) on the count information from the operation set according to the control information.

[0088] Another example of an operation performed by the computing unit 720 includes setting the state information to a specific value. In one embodiment, the computing unit 720 sets the state information to a specific value specified by the control information retrieved from the memory 716.

[0089] Another example of an operation performed by the calculation unit 720 includes setting the offset information to a specific value. In one embodiment, the calculation unit 720 sets the offset information to a specific value specified by the control information retrieved from the memory 716. In one embodiment, the calculation unit 720 sets the offset information to a value calculated by the calculation unit 720. In one embodiment, based on the control information retrieved from the memory 716, the calculation unit 720 either i) sets the offset information to a specific value specified by the control information retrieved from the memory 716, or ii) sets the offset information to a value calculated by the calculation unit 720.

[0090] Another example of operations performed by the computation unit 720 includes extracting one or more fields from i) a subset of header information selected by the selector 704, ii) metadata, and / or iii) descriptor modification information (scratch pad). In one embodiment, the control information retrieved from the memory 716 specifies which field or fields are to be extracted from i) a subset of header information selected by the selector 704, ii) metadata, and / or iii) descriptor modification information (scratch pad). In some embodiments, the control information specifies i) a starting position within the input of the computation unit (e.g., the header information selected by the selector 704, ii) metadata, iii) descriptor modification information (scratch pad), etc.), and ii) a number of bits to be extracted.

[0091] Another example of an operation performed by the computation unit 720 includes performing an arithmetic operation on a field extracted by the computation unit 720. For example, the computation unit 720 is configured to multiply or divide the data extracted by the computation unit 720 by a multiple of 2 (e.g., by right-shifting or left-shifting the extracted data). In some embodiments, the control information specifies: i) whether a multiplication or division is to be performed (e.g., left-shift or right-shift), and the operands of the multiplication / division (e.g., the number of bits to be shifted).

[0092] Another example of an arithmetic operation performed by the calculation unit 720 includes adding a constant to or subtracting a constant from a field extracted by the calculation unit 720. In some embodiments, the control information specifies i) whether to perform addition or subtraction, and the constant to be added or subtracted.

[0093] Another example of an arithmetic operation performed by calculation unit 720 includes setting a subset of bits of a field extracted by calculation unit 720 to a constant. In some embodiments, the control information specifies i) which subset of bits in the extracted field are to be set, and ii) the constant to which the subset of bits are to be set.

[0094] Another example of an operation performed by the computation unit 720 includes setting a register of the computation unit 720 to a particular value. In some embodiments, the control information specifies the value to which the register is to be set.

[0095] Another example of an operation performed by the computing unit 720 includes performing an arithmetic operation between values ​​in two registers of the computing unit 720. The arithmetic operation performed between the values ​​in the two registers includes any suitable combination of one or two, or more, of addition, subtraction, comparison, etc. In one embodiment, the control information specifies the arithmetic operation to be performed. In another embodiment, the control information additionally or alternatively specifies two registers in a register set of the computing unit 720 on which the arithmetic operation is to be performed.

[0096] In various cases, the first register on which the arithmetic operation is performed includes one of: i) a first value corresponding to one or more fields extracted from a) a subset of header information selected by selector 704, b) metadata, and / or c) descriptor modification information (scratch pad), ii) a first constant, etc.; and the second register on which the arithmetic operation is performed includes one of: i) a second value corresponding to one or more fields extracted from a) a subset of header information selected by selector 704, b) metadata, and / or c) descriptor modification information (scratch pad), ii) a second constant, etc.

[0097] In some embodiments, one or more results generated by the calculation unit 720 are used to modify the descriptor modification information (scratch pad memory). In other embodiments, one or more results generated by the calculation unit 720 are additionally or alternatively used to modify the offset information to be provided to another calculation stage 604.

[0098] Figure 8 is a simplified diagram of an example computing unit 800 according to one embodiment. In one embodiment, the computing unit 800 is Figure 7 In other embodiments, Figure 7 The computing unit 720 corresponds to a suitable computing unit different from the computing unit 800. Similarly, in some embodiments, the computing unit 800 is used in a computer different from Figure 7 In a suitable computing level of computing level 700.

[0099] like Figure 8 As shown, various circuits receive control information and are controlled by it. In one embodiment, the control information is transmitted from Figure 7 The control information retrieved from the memory 716 corresponds to the control information retrieved from the memory 716. Figure 7In other embodiments of the computing unit 700 of the appropriate computing unit, the control information is retrieved from the memory of the other appropriate computing unit. The computing unit 800 performs different operations according to the control information provided to the computing unit 800.

[0100] The calculation unit 800 includes a counter modification circuit 804, which is configured to alternately increase the count value, decrease the count value, or set the count value to a specific value under the control of the control information. For example, the modified count information (count out) is provided to another calculation stage 604 ( Figure 6 In one embodiment, when the control information specifies that the count value is to be set to a particular value, the control information also specifies the particular value.

[0101] The computing unit 800 also includes a plurality of computing subsections 808. In one embodiment, each computing subsection 808 has a similar structure, and for the sake of brevity, only one computing subsection 808 (computing subsection 808a) is shown. In other embodiments, one or more other computing subsections 808 have a suitable structure different from the computing subsection 808a.

[0102] The computing sub-portion 808a receives metadata, descriptor modification information (scratch pad), (eg, by the selector 704 ( Figure 7 In various other embodiments, the computing subsection 808a does not receive the metadata, descriptor modification information (scratch pad) and the subset of header information (e.g., selected by the selector 704 ( Figure 7 ) selected) in any suitable combination of one or two or more. In other embodiments, the calculation sub-section 808a additionally or alternatively receives other suitable information, such as counting information, state information, etc.

[0103] Selector circuit 812, under control of the control information, selects one of a subset of header information, metadata, and descriptor modification information (scratch pad) to generate the selected information. Field extraction circuit 816 is coupled to selector circuit 812 and selects one or more subsets of bits from the selected information to generate (multiple) extracted fields.

[0104] Shift logic circuit 820 is coupled to field extraction circuit 816. Shift logic circuit 820 selectively shifts (multiple) extracted fields to the left or right (or does not perform a shift) under the control of control information. As is known to those of ordinary skill in the art, shifting a binary value to the left by x bits corresponds to multiplying the binary value by 2^x. Similarly, shifting a binary value to the right by x bits corresponds to dividing the binary value by 2^x. Therefore, in some cases, shift logic circuit 820 is used to perform 2^x multiplication or division on (multiple) extracted fields. In some embodiments, the control information indicates i) whether the shift is to the left or right, and ii) the number of bits shifted. In some embodiments, when the control information indicates a shift of 0 bits, shift logic circuit 820 is only used to pass (multiple) extracted fields through without modification. Shift logic circuit 820 generates an output referred to herein as "shift information". When no shift is performed, "shift information" is simply the (multiple) unmodified extracted fields received by shift logic circuit 820.

[0105] The set bit logic circuit 824 is coupled to the shift logic circuit 820. Under the control of the control information, the set bit logic circuit 824 selectively sets one or more bits (or no bits) in the shift information to (multiple) desired values. In some embodiments, the control information indicates i) which bit or bits (if any) are to be set, and ii) (multiple) specific values ​​of one or more corresponding bits. In some embodiments, when the control information indicates that there are no bits to be set, the set bit logic circuit 824 is only used to pass the shift information without modification. The set bit logic circuit 824 generates an output referred to herein as "information with set bits". When no bit value is set, the "information with set bits" is simply the unmodified shift information received by the set bit logic circuit 824.

[0106] The adder / subtractor circuit 828 is coupled to the set bit logic circuit 824. Under the control of the control information, the adder / subtractor circuit 828 selectively adds or subtracts a constant to the information with the set bit (or does not perform addition or subtraction). In some embodiments, the control information indicates i) whether to perform addition, subtraction, or no operation, and ii) if performed, the constant to be added or subtracted. In some embodiments, when the control information indicates not to perform any operation, the adder / subtractor circuit 828 is only used to pass the information with the set bit without modification. The adder / subtractor circuit 828 generates an output referred to herein as "sum / difference". When no addition or subtraction operation is performed, the "sum / difference" is simply the unmodified information with the set bit received by the adder / subtractor circuit 828.

[0107] The sum / difference is stored in register 832. Register 832 is communicatively coupled to one or more other computation subsections 808, such that the sum / difference generated by computation subsection 808a is available to one or more other computation subsections 808. In other embodiments, register 832 is not communicatively coupled to any other computation subsection 808, and the sum / difference generated by computation subsection 808a is not available to any other computation subsection 808.

[0108] The set value circuit 836 generates an output under the control of the control information. The control information indicates a specific value to which the set value circuit 836 sets the output of the set value circuit 836.

[0109] The calculation subsection 808a includes an arithmetic function circuit 840, which is configured to selectively perform an arithmetic function using a first operand and a second operand under the control of the control information. In various embodiments, the arithmetic function circuit 840 is configured to selectively perform an arithmetic function as specified by the control information from a set of one or more arithmetic functions, the set of one or more arithmetic functions including any appropriate combination of one or two or more of the following: i) adding the first operand and the second operand to generate a sum, ii) subtracting the second operand from the first operand to generate a difference, ii) subtracting the first operand from the second operand to generate a difference, iii) comparing the first operand to the second operand to generate a comparison result, etc. In some embodiments, when the control information indicates that no operation will be performed, the arithmetic function circuit 840 is only used to pass the first operand without modification.

[0110] Arithmetic function circuit 840 generates an output referred to herein as an “arithmetic result.” When no operation is performed, the “arithmetic result” is simply the unmodified first operand received by arithmetic function circuit 840 .

[0111] The selector circuit 844 selects a first operand of the arithmetic function circuit 840 under the control of the control information. The selector circuit 844 selects a value as the first operand from a set of candidate first operands, the set of candidate first operands including: i) the extracted field(s) generated by the field extraction circuit 816, ii) the sum / difference stored in the register 832, and iii) the output of the set value circuit 836. In various other embodiments, the set of candidate first operands includes other suitable values ​​and / or excludes any suitable combination of one or two or more of the following: i) the extracted field(s) generated by the field extraction circuit 816, ii) the sum / difference stored in the register 832, and iii) the output of the set value circuit 836.

[0112] The selector circuit 848 selects the second operand of the arithmetic function circuit 840 under the control of the control information. The selector circuit 844 selects a value as the second operand from a set of candidate second operands, and the set of candidate second operands includes: a plurality of values ​​generated by other calculation subsections 808. In some embodiments, the plurality of values ​​generated by other calculation subsections 808 include: values ​​in registers in other calculation subsections 808 corresponding to registers 832 in calculation subsection 808a. In various other embodiments, the set of candidate second operands includes other suitable values ​​(e.g., values ​​generated by calculation subsection 808a), and / or excludes one or more values ​​generated by other calculation subsections 808.

[0113] The selector 852 is coupled to the arithmetic function circuit 840 and is configured to, under the control of the control information, selectively i) write the arithmetic result to the descriptor modification information (scratch pad memory) and / or ii) output the arithmetic result as a memory to be provided to another calculation stage 604 ( Figure 6 ). In one embodiment, the selector 852 is configured to selectively perform only one of the following under the control of the control information: i) writing the arithmetic result to the descriptor modification information (scratch pad memory), or ii) outputting the arithmetic result as a value to be provided to another calculation stage 604 ( Figure 6 ) offset information. In another embodiment, the selector 852 is configured to selectively perform one or both of the following under the control of the control information: i) write the arithmetic result to the descriptor modification information (scratch pad memory), and / or ii) output the arithmetic result as a value to be provided to another calculation stage 604 ( Figure 6 ) offset information.

[0114] Reference again Figure 1 and Figure 2 In other embodiments, the programmable parsing circuitry of the hybrid fixed / programmable header parser 104 and / or the programmable header parser 248 includes: a processor, and a memory coupled to the processor, the memory storing software and / or firmware instructions (or other suitable machine-readable instructions), and the processor is configured to execute the software and / or firmware instructions (or other suitable machine-readable instructions) stored in the memory to parse the second portion of the header, as described above. Because only a portion of the header is parsed using software, at least in some embodiments, the programmable header parser 248 is able to parse a portion of the packet at line speed. In addition, because only a portion of the header is parsed using software, the hybrid packet parser 200 (which includes the fixed header parser 244 and the programmable header parser 248) is able to easily parse the entire packet header at line speed, and, at least in some embodiments, is able to do so using fewer programmable computing resources than a more traditional fully programmable header parser.

[0115] Fig. 9 is a flow chart of an example method 900 for processing packets in a network device including a first parsing circuit and a programmable second parsing circuit according to one embodiment. Figure 1 The network device 100 corresponds to the first parsing circuit and the programmable second parsing circuit are components of the hybrid fixed / programmable header parser 104. In other embodiments, the method 900 is performed by a different Figure 1 The network device 100 may be implemented by another suitable network device.

[0116] In one embodiment, the first analysis circuit and the programmable second analysis circuit are respectively Figure 2 The fixed header parser 244 and the programmable header parser 248 correspond to each other. In other embodiments, different Figure 2 The method 900 may be implemented by the first parsing circuit and the programmable second parsing circuit of the fixed header parser 244 and / or the programmable header parser 248.

[0117] In one embodiment, the second resolution circuit is programmable with Figure 6 In other embodiments, a programmable parser 600 different from Figure 6 Method 900 may be implemented using suitable programmable parsing circuitry of programmable parser 600 .

[0118] In one embodiment, the programmable second resolution circuit includes Figure 7 In other embodiments, the method 900 is implemented using a suitable programmable parsing circuit that includes an architecture different from the computational stage 700.

[0119] In one embodiment, the programmable second resolution circuit includes Figure 8 In other embodiments, the method 900 is implemented using a suitable programmable parsing circuit that includes an architecture different from the computing hardware unit 800.

[0120] For explanation purposes only, refer to Figure 1-8 Method 900 is described. However, as described above, method 900 may be used in a manner different from that described above. Figure 1 , 2 and 6-8 described other network devices and analysis circuit systems to achieve. Similarly, method 900 can be combined with reference to Figure 3-5 Packet formats other than those described may be used.

[0121] At block 904, the network device receives a packet. In one embodiment, the network device receives the packet via a network interface. For example, network device 100 receives the packet via network interface 108 according to one illustrative embodiment.

[0122] At block 908, a header of the packet is parsed by the first parsing circuit and the programmable second parsing circuit. In one embodiment, parsing the header of the packet includes i) parsing a first portion of the header by the first parsing circuit, and ii) parsing a second portion of the header that is different from the first portion of the header by the programmable second parsing circuit. In another embodiment, parsing the header of the packet further includes: i) prompting, by the first parsing circuit, a programmable second parsing circuit of a network device to parse the second portion of the header; ii) retrieving, by the programmable second parsing circuit, control information from a memory of the programmable second parsing circuit, the control information indicating an operation to be performed related to parsing the second portion of the header, and iii) parsing, by the programmable second parsing circuit, the second portion of the header including controlling a configurable circuit system of the programmable second parsing circuit using the control information.

[0123] In one embodiment, method 900 also includes: generating, by the first parsing circuit, an indication of a location within the set of header information from the packet at which the programmable second parsing circuit is to begin parsing; and using, by the programmable second parsing circuit, the indication of the location in connection with parsing a second portion of the header.

[0124] In another embodiment, method 900 also includes: determining, by the first parsing circuit and using information parsed from the header of the packet, whether the programmable second parsing circuit is to parse the second part of the header; and in response to determining that the programmable second parsing circuit is to parse the second part of the header, the first parsing circuit selectively prompting the programmable second parsing circuit to parse the second part of the header.

[0125] In some embodiments, determining whether the programmable second parsing circuit is to parse the second portion of the header includes using information parsed from the first portion of the header of the packet to determine whether the programmable second parsing circuit is to parse the second portion of the header.

[0126] As an illustrative embodiment, determining whether the programmable second parsing circuit is to parse the second portion of the header includes: using the port information parsed from the header of the packet to determine whether the programmable second parsing circuit is to parse the second portion of the header. Figure 3 As described above, the first parsing circuit may determine, based on information included in the destination port field 384 of the outer UDP header 332, whether the programmable second parsing circuit is to parse the second portion of the header.

[0127] As another illustrative embodiment, determining whether the programmable second parsing circuit is to parse the second portion of the header includes: using header length information parsed from the header of the packet to determine whether the programmable second parsing circuit is to parse the second portion of the header. Figure 4 and Figure 5 As described above, the first parsing circuit may determine whether the programmable second parsing circuit is to parse the second portion of the header based on information included in the length field of the header, such as the length subfield 448 of the NSH 408 and / or the length field 572 of the CMD tag 536 .

[0128] As another illustrative embodiment, determining whether the programmable second parsing circuit is to parse the second portion of the header includes: using the Ethernet type information parsed from the header of the packet to determine whether the programmable second parsing circuit is to parse the second portion of the header. Figure 5 As described above, the first parsing circuit can determine whether the programmable second parsing circuit is to parse the second part of the header based on the information in the CMD Ethernet type field 564 of the CMD tag 536.

[0129] In other embodiments, determining whether the programmable second parsing circuit is to parse the second portion of the header includes additionally or alternatively using information parsed from the second portion of the header of the packet.

[0130] In some embodiments, retrieving the control information includes: generating a key using information from a header; providing the key to a TCAM having a plurality of TCAM entries; generating an index output by the TCAM indicating a match of the key to one of the TCAM entries; and retrieving the control information from a memory using the index output from the TCAM. As an illustrative embodiment, the key generator 708 optionally generates a key using information from a header of the packet; the key is provided to the TCAM 712; and the index generated by the TCAM 712 is used to retrieve the control information from the memory 716.

[0131] At block 912, a forwarding engine of the network device determines one or more egress network interfaces via which to send the packet. In one embodiment, determining the one or more egress network interfaces includes the forwarding engine determining the one or more network egress interfaces using information parsed from the header by one or both of i) a first parsing circuit and ii) a programmable second parsing circuit.

[0132] In block 916, the network device sends the packet via the one or more network interfaces determined at block 912. For example, network device 100 sends the packet via one or more network interfaces 108, according to one illustrative embodiment.

[0133] Embodiment 1: A network device comprises: a plurality of network interfaces configured to be communicatively coupled with a plurality of network links; and a packet processor coupled to the plurality of network interfaces, the packet processor comprising: a forwarding engine configured to determine an egress network interface, packets received via the plurality of network interfaces to be sent via the egress network interface; and a header parser configured to parse header information in packets received via the plurality of network interfaces; wherein the header parser comprises: a first parsing circuit configured to parse a first portion of a header of the packet and prompt a programmable second parsing circuit to parse a second portion of the header, the first portion of the header having a header structure known to the first parsing circuit; and a programmable second parsing circuit, the programmable second parsing circuit comprising i) a configurable circuit system and ii) a memory storing control information, the control information controlling the operation of the configurable circuit system to parse the second portion of the header.

[0134] Embodiment 2: A network device according to embodiment 1, wherein: the first parsing circuit is further configured to generate an indication of the following location, where the programmable second parsing circuit will start parsing at the location within a set of header information from the packet; and the programmable second parsing circuit is also configured to use the indication of the location related to the second part of the parsed header.

[0135] Embodiment 3: A network device according to embodiment 1 or 2, wherein the first parsing circuit is configured to: determine whether the programmable second parsing circuit is to parse the second part of the header using information parsed from the header of the packet; and selectively prompt the programmable second parsing circuit to parse the second part of the header in response to determining that the programmable second parsing circuit is to parse the second part of the header.

[0136] Embodiment 4: The network device of embodiment 3, wherein the first parsing circuit is configured to use information parsed from the first portion of the header of the packet to determine whether the programmable second parsing circuit is to parse the second portion of the header.

[0137] Embodiment 5: The network device according to embodiment 3 or 4, wherein the first parsing circuit is configured to: use the port information parsed from the header of the packet to determine whether the programmable second parsing circuit is to parse the second part of the header.

[0138] Embodiment 6: A network device according to any one of embodiments 3-5, wherein the first parsing circuit is configured to: use header length information parsed from a header of the packet to determine whether the programmable second parsing circuit is to parse the second portion of the header.

[0139] Embodiment 7: A network device according to any one of embodiments 3-6, wherein the first parsing circuit is configured to: use Ethernet type information parsed from the header of the packet to determine whether the programmable second parsing circuit is to parse the second part of the header.

[0140] Embodiment 8: A network device according to any one of embodiments 3-7, wherein the first parsing circuit is configured to: use information parsed from the second part of the header of the packet to determine whether the programmable second parsing circuit is to parse the second part of the header.

[0141] Embodiment 9: A network device according to any one of embodiments 3-8, wherein the programmable second parsing circuit includes: a key generator configured to generate a key using information from a header; a ternary content addressable memory (TCAM) including multiple TCAM entries, the TCAM being configured to generate an index output indicating a match between the key and one of the TCAM entries; a memory device for storing control information in memory entries corresponding to the TCAM entries, and outputting a subset of the control information in the corresponding memory entries corresponding to the index output output by the TCAM; and a configurable computing hardware circuit system configured to perform computing operations specified by the subset of the control information output by the memory device.

[0142] Embodiment 10: A network device according to any one of embodiments 3-9, wherein the programmable parsing second circuit comprises: a memory storing machine-readable instructions; and a processor coupled to the memory, the processor being configured to execute the machine-readable instructions stored in the memory.

[0143] Embodiment 11: A network device according to any one of embodiments 3-10, wherein: the packet processor includes a packet processing pipeline having multiple pipeline stages; the forwarding engine is the first pipeline stage among the multiple pipeline stages; and the header parser is the second pipeline stage among the multiple pipeline stages.

[0144] Embodiment 12: A method for processing a packet in a network device, the method comprising: receiving a packet via a network interface of the network device; parsing a header of the packet, comprising: parsing a first part of the header by a first parsing circuit, the first part of the header having a header structure known to the first parsing circuit, prompting a programmable second parsing circuit of the network device by the first parsing circuit to parse a second part of the header, retrieving control information from a memory of the programmable second parsing circuit by the programmable second parsing circuit, the control information indicating an operation to be performed related to parsing the second part of the header, and parsing the second part of the header by the programmable second parsing circuit, comprising a configurable circuit system that controls the programmable second parsing circuit using the control information; determining, by a forwarding engine, one or more egress network interfaces through which the packet is sent, the one or more egress network interfaces being determined using information parsed from the header by one or both of i) the first parsing circuit and ii) the programmable second parsing circuit; and sending the packet via the one or more egress network interfaces determined by the forwarding engine.

[0145] Embodiment 13: The method according to embodiment 12 also includes: generating, by the first parsing circuit, an indication of the following position, where the programmable second parsing circuit will start parsing at the position within the set of header information from the packet; and using, by the programmable second parsing circuit, the indication of the position related to the second part of the parsed header.

[0146] Embodiment 14: The method according to embodiment 12 or 13 further includes: determining, by the first parsing circuit and using information parsed from the header of the packet, whether the programmable second parsing circuit is to parse the second part of the header; wherein, prompting the programmable second parsing circuit of the network device to parse the second part of the header by the first parsing circuit includes: in response to determining that the programmable second parsing circuit is to parse the second part of the header, the first parsing circuit selectively prompting the programmable second parsing circuit to parse the second part of the header.

[0147] Embodiment 15: A method according to embodiment 14, wherein: determining whether the programmable second parsing circuit is to parse the second part of the header includes: using information parsed from the first part of the header of the packet to determine whether the programmable second parsing circuit is to parse the second part of the header.

[0148] Embodiment 16: A method according to embodiment 14 or 15, wherein: determining whether the programmable second parsing circuit is to parse the second part of the header includes: using port information parsed from the header of the packet to determine whether the programmable second parsing circuit is to parse the second part of the header.

[0149] Embodiment 17: A method according to any one of embodiments 14-16, wherein: determining whether the programmable second parsing circuit is to parse the second part of the header includes: using header length information parsed from the header of the packet to determine whether the programmable second parsing circuit is to parse the second part of the header.

[0150] Embodiment 18: A method according to any one of embodiments 14-17, wherein: determining whether the programmable second parsing circuit is to parse the second part of the header includes: using Ethernet type information parsed from the header of the packet to determine whether the programmable second parsing circuit is to parse the second part of the header.

[0151] Embodiment 19: A method according to any one of embodiments 14-18, wherein: determining whether the programmable second parsing circuit is to parse the second part of the header includes: using information parsed from the second part of the header of the packet to determine whether the programmable second parsing circuit is to parse the second part of the header.

[0152] Embodiment 20: A method according to any one of embodiments 12-19, wherein retrieving control information comprises: generating a key using information from a header; providing the key to a ternary content addressable memory (TCAM) comprising a plurality of TCAM entries; generating an index output by the TCAM, the index output indicating a match between the key and one of the TCAM entries; and retrieving control information from a memory using the index output from the TCAM.

[0153] At least some of the various blocks, operations, and techniques described above may be implemented using hardware, a processor executing firmware instructions, a processor executing software instructions, or any combination thereof. When implemented using a processor executing software or firmware instructions, the software or firmware instructions may be stored in any computer-readable memory, such as RAM, ROM, flash memory, integrated memory of a processor, etc. The software or firmware instructions may include machine-readable instructions that, when executed by a processor, cause the processor to perform various actions.

[0154] When implemented in hardware, the hardware may include one or more discrete components, one or more ICs, application specific integrated circuits (ASICs), programmable logic devices (PLDs), and the like.

[0155] Although the present invention has been described with reference to specific examples, these examples are only for illustration and not limitation of the present invention, and changes, additions and / or deletions may be made to the disclosed embodiments without departing from the scope of the present invention.

Claims

1. A network device, comprising: a plurality of network interfaces configured to be communicatively coupled to the plurality of network links; and a packet processor coupled to the plurality of network interfaces, the packet processor comprising: a forwarding engine configured to determine an egress network interface through which packets received via the plurality of network interfaces are to be sent, and a header parser configured to parse header information in the packets received via the plurality of network interfaces; The header parser includes: a first parsing circuit configured to: i) parse a first portion of a header of a packet to extract first information from the first portion of the header, ii) output the extracted first information for processing by other circuitry of the packet processor separate from the header parser, and iii) and prompt a programmable second parsing circuit to parse a second portion of the header, the first portion of the header having a header structure known to the first parsing circuit, and The programmable second parsing circuit includes i) a configurable circuit system and ii) a memory storing control information, wherein the control information controls the operation of the configurable circuit system to parse the second part of the header to extract second information from the second part of the header, and the programmable second parsing circuit is configured to output the extracted second information for processing by the other circuit system of the packet processor.

2. The network device according to claim 1, wherein: The first parsing circuit is further configured to generate an indication of a location within the set of header information from the packet at which the programmable second parsing circuit is to begin parsing; and The programmable second parsing circuit is further configured to use the indication of the position in connection with parsing the second portion of the header.

3. The network device according to claim 1, wherein the first parsing circuit is configured to: using information parsed from a header of the packet, determining whether the programmable second parsing circuit is to parse the second portion of the header; and In response to determining that the programmable second parsing circuitry is to parse the second portion of the header, the programmable second parsing circuitry is selectively prompted to parse the second portion of the header.

4. The network device according to claim 3, wherein the first parsing circuit is configured to: Using information parsed from the first portion of the header of the packet, it is determined whether the programmable second parsing circuit is to parse the second portion of the header.

5. The network device according to claim 3, wherein the first parsing circuit is configured to: Using the port information parsed from the header of the packet, it is determined whether the programmable second parsing circuit is to parse the second portion of the header.

6. The network device according to claim 3, wherein the first parsing circuit is configured to: Using header length information parsed from a header of the packet, it is determined whether the programmable second parsing circuit is to parse the second portion of the header.

7. The network device according to claim 3, wherein the first parsing circuit is configured to: Using the EtherType information parsed from the header of the packet, it is determined whether the programmable second parsing circuit is to parse the second portion of the header.

8. The network device according to claim 3, wherein: The first analysis circuit is configured as follows: Using information parsed from a second portion of a header of the packet, it is determined whether the programmable second parsing circuit is to parse the second portion of the header.

9. The network device according to claim 1, wherein: The programmable second analysis circuit comprises: a key generator configured to generate a key using information from the header; a ternary content addressable memory (TCAM) comprising a plurality of TCAM entries, the TCAM configured to generate an index output indicating a match of the key with one of the TCAM entries; a memory device to store control information in memory entries corresponding to the TCAM entries and to output a subset of the control information in the corresponding memory entries corresponding to the index output of the TCAM; and A configurable computing hardware circuit system is configured to perform computing operations specified by the subset of control information output by the memory device.

10. The network device of claim 1, wherein the programmable second resolution circuit comprises: a memory storing machine-readable instructions; and A processor is coupled to the memory, the processor being configured to execute machine-readable instructions stored in the memory.

11. The network device according to claim 1, wherein: The packet processor includes a packet processing pipeline having a plurality of pipeline stages; The forwarding engine is a first pipeline stage among the plurality of pipeline stages; and The header parser is a second pipeline stage among the plurality of pipeline stages.

12. A method for processing a packet in a network device, the method comprising: receiving a packet via a network interface of the network device; The header of the packet is parsed by a header parser of the packet processor, including: The first part of the header is parsed by a first parsing circuit of the header parser, wherein the first part of the header has a header structure known to the first parsing circuit, including: extracting first information from said first portion of said header, outputting the extracted first information for processing by other circuitry of the packet processor separate from the header parser, the first parsing circuit prompting a programmable second parsing circuit of the network device to parse a second portion of the header, retrieving, by the programmable second parsing circuitry, control information from a memory of the programmable second parsing circuitry, the control information indicating operations to be performed in connection with parsing the second portion of the header, and Parsing the second portion of the header by the programmable second parsing circuit includes controlling configurable circuitry of the programmable second parsing circuit using the control information, the parsing of the second portion of the header including: extracting second information from the second portion of the header, and outputting the extracted second information for processing by the other circuitry of the packet processor; determining, by a forwarding engine of the packet processor, one or more egress network interfaces via which to send the packet, the one or more egress network interfaces being determined using information from one or both of: i) the extracted first information and ii) the extracted second information; and The packet is sent via the one or more egress network interfaces determined by the forwarding engine.

13. The method according to claim 12, further comprising: generating, by the first parsing circuit, an indication of a location within a set of header information from the packet at which the programmable second parsing circuit is to begin parsing; and The indication of the position associated with parsing the second portion of the header is used by the programmable second parsing circuit.

14. The method according to claim 12, further comprising: determining, by the first parsing circuit and using information parsed from the header of the packet, whether the programmable second parsing circuit is to parse the second portion of the header; Wherein prompting the programmable second parsing circuit of the network device to parse the second part of the header by the first parsing circuit includes: in response to determining that the programmable second parsing circuit is to parse the second part of the header, the first parsing circuit selectively prompting the programmable second parsing circuit to parse the second part of the header.

15. The method according to claim 14, wherein: Determining whether the programmable second parsing circuit is to parse the second portion of the header includes using information parsed from the first portion of the header of the packet to determine whether the programmable second parsing circuit is to parse the second portion of the header.

16. The method of claim 14, wherein: Determining whether the programmable second parsing circuit is to parse the second portion of the header includes using port information parsed from the header of the packet to determine whether the programmable second parsing circuit is to parse the second portion of the header.

17. The method of claim 14, wherein: Determining whether the programmable second parsing circuit is to parse the second portion of the header includes using header length information parsed from a header of the packet to determine whether the programmable second parsing circuit is to parse the second portion of the header.

18. The method of claim 14, wherein: Determining whether the programmable second parsing circuit is to parse the second portion of the header includes using Ethertype information parsed from the header of the packet to determine whether the programmable second parsing circuit is to parse the second portion of the header.

19. The method of claim 14, wherein: Determining whether the programmable second parsing circuit is to parse the second portion of the header includes using information parsed from the second portion of the header of the packet to determine whether the programmable second parsing circuit is to parse the second portion of the header.

20. The method of claim 12, wherein retrieving the control information comprises: generating a key using information from the header; providing the key to a ternary content addressable memory (TCAM) comprising a plurality of TCAM entries; generating, by the TCAM, an index output indicating a match of the key to one of the TCAM entries; and Control information is retrieved from the memory using the index output from the TCAM.

Images