CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] None.

TECHNICAL FIELD

[0002] The present disclosure is generally related to the field of data communication fixed networks and, in particular, to a virtual pipeline configured to organize an arbitrary logic pipeline using pipeline stage processors.

BACKGROUND

[0003] Programmable network devices are used to support in-network computing, network automation, and various network innovations. Such programmable network devices may include, for example, an application-specific integrated circuit (ASIC), a network processor (NP), a Tofino chip, and so on.

[0004] The programmable network devices can include a Protocol-Independent Switch Architecture (PISA) and can be programmed using the Programming Protocol-independent Packet Processors (P4) language.

SUMMARY

[0005] The disclosed aspects/embodiments provide a virtual pipeline architecture having an interconnection network (e.g., a crossbar switch) that provides an arbitrary pipeline. The arbitrary pipeline permits PSPs in a virtual pipeline architecture to be allocated arbitrarily as opposed to the fixed allocation of PSPs in a virtual pipeline architecture with a static or hard pipeline. The arbitrary pipeline also permits unused PSPs to be put in low-power mode, which saves energy. The arbitrary pipeline supports in-service incremental updates, which involves inserting and/or removing one or more PSPs. By using the arbitrary pipeline, network resources are better utilized and energy costs are reduced.

[0006] A first aspect relates to a virtual pipeline architecture comprising: an interconnection network; a plurality of pipeline stage processors (PSPs) coupled to the interconnection network, each of the plurality the PSPs configured to process a packet; a traffic manager (TM) coupled to the interconnection network; and an input/output port coupled to the interconnection network, the input/output port configured to receive the packet for processing by one or more of the plurality of PSPs and to output the packet after the packet has been processed by the one or more of the plurality of PSPs.

[0007] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the interconnection network comprises a multi-stage interconnection network (MIN).

[0008] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the interconnection network comprises a crossbar switch.

[0009] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the crossbar switch is configured to receive input from each of the plurality of PSPs, the traffic manager, and the input/output port independently.

[0010] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the crossbar switch is configured to provide output to each of the plurality of PSPs, the traffic manager, and the input/output port independently.

[0011] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the interconnection network permits the packet to be processed by the PSPs in any order.

[0012] Optionally, in any of the preceding aspects, another implementation of the aspect provides that any of the plurality of PSPs not tasked with processing the packet are configured to enter a low power idle state.

[0013] Optionally, in any of the preceding aspects, another implementation of the aspect provides that one of the plurality of PSPs not tasked with processing the packet and in a low power idle state is configured to be reprogrammed to process the packet in order to add a new stage.

[0014] Optionally, in any of the preceding aspects, another implementation of the aspect provides that one of the plurality of PSPs tasked with processing the packet is configured to be reprogrammed to enter a low power idle state to remove a stage.

[0015] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the traffic manager is configured to one or more of queue, buffer, and schedule the packet.

[0016] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the input/output port comprises an input port physically separated from an output port.

[0017] A second aspect relates to a method of processing a packet in virtual pipeline architecture, comprising: receiving, at an input/output port, the packet; routing, by an interconnection network, the packet to an ingress pipeline for processing, the ingress pipeline including a subset of a plurality of pipeline stage processors (PSPs) configured to process the packet in any order; routing, by the interconnection network, the packet to a traffic manager (TM) after the packet has been processed by the ingress pipeline; routing, by the interconnection network, the packet to an egress pipeline for processing, the egress pipeline including a different subset of the plurality of PSPs configured to process the packet in any order; and outputting, at the input/output port, the packet after the packet has been processed by the egress pipeline. [0018] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the interconnection network comprises a multi-stage interconnection network (MIN).

[0019] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the interconnection network comprises a crossbar switch.

[0020] Optionally, in any of the preceding aspects, another implementation of the aspect provides processing the packet using a PSP in a second stage before processing the packet using another PSP in a first stage.

[0021] Optionally, in any of the preceding aspects, another implementation of the aspect provides putting any of the plurality of PSPs not tasked with processing the packet into a low power idle state.

[0022] Optionally, in any of the preceding aspects, another implementation of the aspect provides reprogramming one of the plurality of PSPs not tasked with processing the packet and in a low power idle state to process the packet in order to add a new stage.

[0023] Optionally, in any of the preceding aspects, another implementation of the aspect provides reprogramming one of the plurality of PSPs tasked with processing the packet to enter a low power idle state to remove a stage.

[0024] Optionally, in any of the preceding aspects, another implementation of the aspect provides queueing, buffering, or scheduling the packet with the traffic manager.

[0025] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the input/output port comprises an input port physically separated from an output port.

[0026] A third aspect relates to a programmable network device, comprising: a virtual pipeline architecture, comprising: an interconnection network; a plurality of pipeline stage processors (PSPs) coupled to the interconnection network, each of the plurality the PSPs configured to process a packet; a traffic manager (TM) coupled to the interconnection network; and an input/output port coupled to the interconnection network, the input/output port configured to receive the packet for processing by one or more of the plurality of PSPs and to output the packet after the packet has been processed by the one or more of the plurality of PSPs.

[0027] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the programmable network device comprises an application-specific integrated circuit (ASIC).

[0028] Optionally, in any of the preceding aspects, another implementation of the aspect provides that the programmable network device comprises a network processor (NP).

[0029] A fourth aspect relates to a virtual pipeline architecture means, comprising: an interconnection network means; a plurality of pipeline stage processor (PSP) means coupled to the interconnection network means, each of the plurality the PSP means configured to process a packet; a traffic manager (TM) means coupled to the interconnection network means; and an input/output port means coupled to the interconnection network means, the input/output port means configured to receive the packet for processing by one or more of the plurality of PSP means and to output the packet after the packet has been processed by the one or more of the plurality of PSP means.

[0030] For the purpose of clarity, any one of the foregoing embodiments may be combined with any one or more of the other foregoing embodiments to create a new embodiment within the scope of the present disclosure.

[0031] These and other features will be more clearly understood from the following detailed description taken in conjunction with the accompanying drawings and claims.

BRIEF DESCRIPTION OF THE DRAWINGS

[0032] For a more complete understanding of this disclosure, reference is now made to the following brief description, taken in connection with the accompanying drawings and detailed description, wherein like reference numerals represent like parts.

[0033] FIG. 1 is an example of a Protocol-Independent Switch Architecture (PISA).

[0034] FIG. 2 is a virtual pipeline architecture according to an embodiment of the disclosure. [0035] FIG. 3 is a virtual pipeline architecture with pipeline stage processors (PSPs) in a low power idle state according to an embodiment of the disclosure.

[0036] FIG. 4 is a virtual pipeline architecture where a stage has been added in the ingress pipeline and a stage has been removed from the egress pipeline according to an embodiment of the disclosure. [0037] FIG. 5 is a diagram that illustrates how PSPs are mapped to a hardwired pipeline similar to the ingress and egress pipelines of FIG. 1.

[0038] FIG. 6 is a diagram and corresponding graph that collectively illustrate how PSPs are mapped to a virtual (or arbitrary) pipeline similar the ingress and egress pipelines of FIGS. 3-4 using an interconnection network.

[0039] FIG. 7 is a method of processing a packet in virtual pipeline architecture according to an embodiment of the disclosure.

[0040] FIG. 8 is a schematic diagram of a network device according to an embodiment of the disclosure.

DETAILED DESCRIPTION

[0041] It should be understood at the outset that although an illustrative implementation of one or more embodiments are provided below, the disclosed systems and/or methods may be implemented using any number of techniques, whether currently known or in existence. The disclosure should in no way be limited to the illustrative implementations, drawings, and techniques illustrated below, including the exemplary designs and implementations illustrated and described herein, but may be modified within the scope of the appended claims along with their full scope of equivalents.

[0042] FIG. 1 is an example of a Protocol-Independent Switch Architecture (PISA) 100. As shown, the PISA 100 includes a traffic manager 102 disposed between an ingress pipeline 104 and an egress pipeline 106. The ingress pipeline 104 and the egress pipeline 106 of FIG. 1 each include a front-end parser 108, a plurality of pipeline stage processors (PSPs) 110, and a queue/buffer 112. The front-end parser 108 is configured to receive, parse, and craft packets (a.k.a., data packets, network packets, etc.). The front-end parser 108 is configured to forward the packets to the PSP 110 in the first stage (e.g., the PSP 110 immediately adjacent to the front- end parser 108).

[0043] The PSP 110 in the first stage may or may not process the packets received from the front-end parser 108. In order to process the packets, each PSP 110 includes, for example, a memory 114 and an arithmetic logic unit (ALU) 116. The PSPs 110 may include other components in practical applications.

[0044] The first PSP 110 forwards the packets to the PSP 110 in the second stage. The PSP 110 in the second stage may or may not process the packets received from the PSP 110 in the first stage. This process continues in succession until all of the PSPs 110 in subsequent stages have either processed the packets or forwarded the packets to the next PSP without performing any processing. The last PSP 110 in sequential order forwards the packets to the queue/buffer 112. The queue/buffer 112 temporarily stores the packets until the packets are transmitted. [0045] The traffic manager 102 receives the packets from the queue/buffer 112 of the ingress pipeline 104 and forwards the packets to the front-end parser 108 of the egress pipeline 106. The traffic manager 102 is configured to queue, replicate, and schedule the transmission of the packets. In some cases, the queue/buffer 112 is incorporated into, and forms part of, the traffic manager 102.

[0046] Unfortunately, programmable network devices incorporating the PISA 100 of FIG. 1 use a static or “hard” allocation of the resources. That is, the PSPs 110 are organized in a series of sequential stages (e.g., first stage, second stage, etc.) within the ingress pipeline 104 and the egress pipeline 106. Because of the static configuration of PSPs 110, reprogramming a programmable network device using the PISA 100 may fail. Take, for example, a PISA (e.g., PISA 100) having five PSPs 110 available in the ingress pipeline 104 and another five PSPs 110 available in the egress pipeline 106. When the P4 language used to reprogram the programmable network device calls for an ingress pipeline to have six PSPs in the ingress pipeline 104 and to have three PSPs 110 in the egress pipeline 106, the mapping fails because the ingress pipeline 104 only has five available PSPs 110. This failure occurs even though the egress pipeline 106 had three unused PSPs 110 in the design. Thus, the conventional allocation of PSPs 110 is inflexible and inefficient.

[0047] In addition, in the PISA 100 of FIG. 1, all of the PSPs 110 are chained together, even when the PSPs 110 of some of the stages are unused (e.g., do not perform any processing and simply forward the packet). This configuration consumes more power and introduces latency. Further, any in-service incremental update for the PISA 100 of FIG. 1 necessitates moving one or more of the PSPs 110, which is difficult and time consuming.

[0048] Disclosed herein is a virtual pipeline architecture having an interconnection network (e.g., a crossbar switch) that provides an arbitrary pipeline. The arbitrary pipeline permits PSPs in a virtual pipeline architecture to be allocated arbitrarily as opposed to the fixed allocation of PSPs in a virtual pipeline architecture with a static or hard pipeline. The arbitrary pipeline also permits unused PSPs to be put in low-power mode, which saves energy. The arbitrary pipeline supports in-service incremental updates, which involves inserting and/or removing one or more PSPs. By using the arbitrary pipeline, network resources are better utilized and energy costs are reduced.

[0049] FIG. 2 is a virtual pipeline architecture 200 according to an embodiment of the disclosure. As shown, the virtual pipeline architecture 200 comprises an interconnection network 202, a plurality of PSPs 204, a traffic manager 206, and an input/output port 208 (a.k.a., a packet input/output port). The virtual pipeline architecture 100 may be incorporated in a programmable network device 210 such as, for example, an application-specific integrated circuit (ASIC), a network processor (NP), a Tofino chip, and so on.

[0050] The interconnection network 202 is coupled to the input/output port 208, the traffic manager 206, and each of the PSPs 204. As shown by the arrows in FIG. 2, the interconnection network 202 is configured to receive input from, and deliver output to, each of the PSPs 204, the traffic manager 206, and the input/output port 208 independently. The input received and the output delivered by the interconnection network 202 may be a packet, an unprocessed packet, a fully or partially processed packet, information regarding or corresponding to a packet, etc. In an embodiment, the interconnection network 202 is coupled to each of the PSPs 204 via a single bi-directional link or connection (represented by the arrow).

[0051] The interconnection network 202 may take a variety of different structural or physical forms. In an embodiment, the interconnection network 202 comprises a multi-stage interconnection network (MIN). MINs are a class of high-speed computer networks usually composed of processing elements (PEs) on one end of the network and memory elements (MEs) on the other end, connected by switching elements (SEs). The switching elements themselves are usually connected to each other in stages, hence the name. MINs are typically used in high- performance or parallel computing as a low-latency interconnection (as opposed to traditional packet switching networks), though they could be implemented on top of a packet switching network. Though the network is typically used for routing purposes, the network could also be used as a co-processor to the actual processors for such uses as sorting, cyclic shifting (as in a perfect shuffle network), and bitonic sorting.

[0052] In an embodiment, the interconnection network comprises a crossbar switch. A crossbar switch is a collection of switches arranged in a matrix configuration. A crossbar switch has multiple input and output lines that form a crossed pattern of interconnecting lines between which a connection may be established by closing a switch located at each intersection, the elements of the matrix. Originally, a crossbar switch was literally formed from crossing metal bars that provided the input and output paths. Later implementations achieved the same switching topology in solid-state electronics. The cross-point switch is one of the principal switch architectures, together with a rotary switch, memory switch, and a crossover switch. [0053] In an embodiment, the interconnection network 202 (e.g., a crossbar switch) comprises a switch connecting one or more inputs (e.g., the input/output port 208, the traffic manager 206) to multiple outputs (e.g., each of the PSPs 204) in a matrix manner. That is, the interconnection network 202 is able to switch the one or more inputs to any of the outputs. As such, the interconnection network 202 is able to route a packet received at the input/output port 208 or received from the traffic manager 206 to any of the PSPs 204 coupled to the interconnection network 202.

[0054] The interconnection network 202 permits PSPs 204 in the virtual pipeline architecture 200 to be allocated arbitrarily as opposed to the fixed allocation of PSPs 110 in the virtual pipeline architecture 100 of FIG. 1 with the static or hard pipeline. That is, the interconnection network 202 provides an arbitrary pipeline. Because of this configuration, any of the PSPs 204 may be included in the ingress pipeline or in the egress pipeline. For example, any of the PSPs 204 may form the ingress pipeline and any of the PSPs not included in the ingress pipeline may form the egress pipeline.

[0055] The interconnection network 202 also permits a packet to be processed by the PSPs 204 in any order. That is, a third PSP (from left to right in FIG. 2) is able to process a packet before a second PSP (from left to right in FIG. 2) processes that packet. This concept will be more fully disclosed below.

[0056] The PSPs 204 of FIG. 2 are similar to the PSPs 110 of FIG. 1. That is, the PSPs are configured to process packets. However, the PSPs 204 of FIG. 2 are only coupled to the interconnection network 202 instead of being connected directly to each other in a sequential fashion like the PSPs 110 of FIG. 1. As shown in FIG. 2, the virtual pipeline architecture 200 includes “n” number of PSPs 204, where n is any positive integer. While nine of the PSPs 204 are depicted in FIG. 2, the virtual pipeline architecture 200 may include any number of the PSPs in practical applications.

[0057] Because the virtual pipeline architecture 200 includes n number of PSPs 204, the interconnection network 202 is considered to have an (n+2) by (n+2) scale, where n represents the number of PSPs 204 and the +2 represents the two inputs received by the interconnection switch. Those two inputs are the input/output port 208 and the traffic manager 206.

[0058] The traffic manager 206 is similar to the traffic manager 102 of FIG. 1. That is, the traffic manager 206 is configured to queue, replicate, and schedule the transmission of the packets. However, the traffic manager 206 of FIG. 2 is only coupled to the interconnection network 206 instead of being connected directly to two of the PSPs 110 of FIG. 1. That is, the traffic manager 206 is physically separated from the PSPs by the interconnection network 202. [0059] The input/output port 208 is configured to receive and transmit packets. While the input/output port 208 of FIG. 2 is shown as a single bi-directional port, the input port may be physical separate from the output port in practical applications. [0060] FIG. 3 is a virtual pipeline architecture 300 with PSPs 304 in a low power idle state according to an embodiment of the disclosure. The virtual pipeline architecture 300 is similar to the virtual pipeline architecture 200 of FIG. 2. That is, the virtual pipeline architecture 300 comprises an interconnection network 302, a plurality of PSPs 304, a traffic manager 306, an input port 308, and an output port 310. The manner in which a packet propagates through the virtual pipeline architecture 300 is represented by a dashed line.

[0061] As shown in FIG. 3, the packet is received by the input port 308. The packet is then routed to the PSP 304 in a first stage of the ingress pipeline by the interconnection network 302. Once the packet has been processed by the PSP 304 in the first stage of the ingress pipeline, the packet is routed to the PSP 304 in a second stage of the ingress pipeline by the interconnection network 302. Once the packet has been processed by the PSP 304 in the second stage of the ingress pipeline, the packet is routed to the PSP 304 in a third stage of the ingress pipeline by the interconnection network 302. Once the packet has been processed by the PSP 304 in the third stage of the ingress pipeline, the packet is routed to the traffic manager 306.

[0062] The traffic manager 306 delivers the packet back to the interconnection network 302. The packet is then routed to the PSP 304 in a first stage of the egress pipeline by the interconnection network 302. Once the packet has been processed by the PSP 304 in the first stage of the egress pipeline, the packet is routed to the PSP 304 in a second stage of the egress pipeline by the interconnection network 302. Once the packet has been processed by the PSP 304 in the second stage of the egress pipeline, the packet is output at the output port 310.

[0063] Notably, the PSPs 304 not included in the ingress pipeline or the egress pipeline are able to be put in a low power idle state. In FIG. 3, a total of four PSPs 304 have been put in the low power idle state. When in the low power idle state, the PSPs 304 do not process or even receive the packet. This is possible due to the arbitrary pipeline created by the interconnection network 304. Because unused PSPs 304 can be put in a low-power or idle mode, the virtual pipeline architecture 300 of FIG. 3 is able to save energy.

[0064] FIG. 4 is a virtual pipeline architecture 400 where a stage has been added in the ingress pipeline and a stage has been removed from the egress pipeline according to an embodiment of the disclosure. The virtual pipeline architecture 400 is similar to the virtual pipeline architecture 300 of FIG. 3. That is, the virtual pipeline architecture 400 comprises an interconnection network 402, a plurality of PSPs 404, a traffic manager 406, an input port 408, and an output port 410. The manner in which a packet propagates through the virtual pipeline architecture 400 is represented by a dashed line. [0065] As shown in FIG. 4, the packet is received by the input port 408. The packet is then routed to the PSP 404 in a first stage of the ingress pipeline by the interconnection network 402. Notably, the virtual pipeline architecture 400 has been reprogrammed relative to the virtual pipeline architecture 300 of FIG. 3. The reprogramming has caused a new second stage to be added or inserted. That is, the third PSP (from left to right) in FIG. 3, which used to be the low power idle state, has now been activated and included in the ingress pipeline. Therefore, once the packet has been processed by the PSP 404 in the first stage of the ingress pipeline, the packet is routed to the PSP 404 in the new second stage of the ingress pipeline by the interconnection network 302. As shown in FIG. 4, the PSP 404 in the first stage is not immediately adjacent to the PSP 404 in the second stage. Rather, the PSP 404 in the third stage of the ingress pipeline is disposed in between the PSP 404 in the first stage and the PSP 404 in a second stage. This configuration illustrates how the PSPs 404 may process the packet in any order.

[0066] Once the packet has been processed by the PSP 404 in the second stage of the ingress pipeline, the packet is routed to the PSP 404 in a third stage of the ingress pipeline by the interconnection network 402. Once the packet has been processed by the PSP 404 in the third stage of the ingress pipeline, the packet is routed to the PSP 404 in a fourth stage of the ingress pipeline by the interconnection network 402. Once the packet has been processed by the PSP 404 in the fourth stage of the ingress pipeline, the packet is routed to the traffic manager 406. [0067] The traffic manager 406 delivers the packet back to the interconnection network 402. The packet is then routed to the PSP 404 in a first stage of the egress pipeline by the interconnection network 402. Notably, the virtual pipeline architecture 400 has been reprogrammed relative to the virtual pipeline architecture 300 of FIG. 3. The reprogramming has caused a stage to be removed. In the illustrated example, the PSP 304 in FIG. 3 is no longer being used to process the packet in the virtual pipeline architecture 400 of FIG. 4 based on the reprogramming. Therefore, once the packet has been processed by the PSP 404 in the first stage of the egress pipeline, the packet is output at the output port 410.

[0068] Notably, the PSPs 404 not included in the ingress pipeline or the egress pipeline are able to be put in a low power idle state. In FIG. 4, a total of four PSPs 404 have been put in the low power idle state. As shown, the virtual pipeline architecture 400 has different PSPs 404 in the low power idle state relative to the virtual pipeline architecture 300 in FIG. 3. While the virtual pipeline architecture 400 and the virtual pipeline architecture 300 both show four PSPs 304, 404 in the low power idle state, it should be recognized that more or fewer of the PSPs 304, 404 may be in the low power idle state or active in practical applications depending on the programming of the virtual pipeline architecture 300, 400. In addition, while the illustrated example shows one stage being added and one stage being removed, any number of stages may be added or removed by the reprogramming. From the foregoing, it should be recognized that the arbitrary pipeline depicted in FIG. 4 supports in-service incremental updates, which involves inserting and/or removing one or more PSPs.

[0069] FIG. 5 is a diagram 500 that illustrates how PSPs 502 are mapped 500 to a hardwired pipeline similar to the ingress and egress pipelines of FIG. 1. For the purpose of discussion, each of the PSPs 502 is referenced with a letter. As shown, any packet received by PSP A is delivered to PSP B. PSP B then transmits the packet to PSP C, which passes the packet along to PSP D. Finally, PSP D sends the packet to PSP E. PSP E can then output the packet. In this configuration, each PSP 502 must remain powered and active in order to receive, process, and/or transmit the packet to the next PSP 502 in line. Moreover, the PSPs are physically coupled to together and, as such, the packet must pass through all of the PSPs in serial fashion.

[0070] FIG. 6 is a diagram and corresponding graph 600 that collectively illustrate how PSPs 602 are mapped to a virtual (or arbitrary) pipeline similar the ingress and egress pipelines of FIGS. 3-4 using an interconnection network 604. For the purpose of discussion, each of the PSPs 602 is referenced with a letter. As shown, a packet received by PSP A is delivered to both PSP B and PSB C via the interconnection network 604. In this example, the packet is processed in parallel by PSP B and PSB C. Depending on how a virtual pipeline architecture is programmed, the packet can be processed in parallel by two or more PSPs to, for example, improve overall processing times.

[0071] PSP C transmits the packet to PSP D, which passes the packet along to PSP E. PSP B also transmits the packet to PSP E. PSP E can then output the packet. In this configuration, any PSP 602 can be active (and process the packet) or can be placed in low power idle state and not even receive the packet. This is possible because the PSPs 602 are each coupled to the interconnection network 604 instead of being directly coupled to each other in a serial or hardwired configuration.

[0072] FIG. 7 is a method 700 of processing a packet in virtual pipeline architecture (e.g., virtual pipeline architecture 200, 300, 400) according to an embodiment of the disclosure. The method 700 may be implemented by a programmable network device, for example, after the programmable network device has been programmed or reprogrammed.

[0073] In block 702, a packet is received at an input/output port (e.g., input/output port 208, 308, 408). The packet may include various headers or other instructions indicating how the packet should be processed or handled by the virtual pipeline architecture. [0074] In block 704, the packet is routed, by an interconnection network (e.g., interconnection network 202, 302, 402), to an ingress pipeline for processing. The ingress pipeline may include a subset of the available PSPs. For example, when the virtual pipeline architecture includes nine available PSPs, four of those PSPs may be used to process the packet as part of the ingress pipeline. In an embodiment, the PSPs are configured to process the packet in any order due to the functionality of the interconnection network. For example, the packet may be processed using a PSP in a second stage before processing the packet using another PSP in a first stage. Processing of the packet by the PSPs in the ingress pipeline may include, for example, parsing a header of the packet, encapsulating the packet, decapsulating the packet, and so on.

[0075] In block706, the packet is routed, by the interconnection network, to the traffic manager (e.g., traffic manager 206, 306, 406) after the packet has been processed by the ingress pipeline. The traffic manager may queue, buffer, and schedule delivery of the packet once received from the ingress pipeline.

[0076] In block 708, the packet is routed, by the interconnection network, to an egress pipeline for processing. In an embodiment, the egress pipeline includes a different subset of the PSPs. That is, the PSPs called upon to execute the egress pipeline are different than those called upon to execute the ingress pipeline. In an embodiment, the PSPs are configured to process the packet in any order due to the functionality of the interconnection network. For example, the packet may be processed using a PSP in a second stage before processing the packet using another PSP in a first stage. Processing of the packet by the PSPs in the egress pipeline may include, for example, reformatting of the packet, encapsulating the packet, and so on.

[0077] In block710, the packet is output, at the input/output port, after the packet has been processed by the egress pipeline.

[0078] In an embodiment, the method 700 includes putting any of the plurality of PSPs not tasked with processing the packet into a low power idle state. That is, any of the plurality of PSPs not forming the ingress pipeline or the egress pipeline may be placed in the low power idle state. In an embodiment, the method 700 includes reprogramming one of the plurality of PSPs not tasked with processing the packet and in a low power idle state to process the packet in order to add a new stage. In an embodiment, the method includes reprogramming one of the plurality of PSPs tasked with processing the packet to enter a low power idle state to remove a stage. [0079] FIG. 8 is a schematic diagram of anetwork device 800 (e.g., a programmable network device). The network apparatus 800 is suitable for implementing the disclosed embodiments as described herein. The network device 800 comprises ingress ports/ingress means 810 and receiver units (Rx)/receiving means 820 for receiving data; a processor, logic unit, or central processing unit (CPU)/processing means 830 to process the data; transmitter units (Tx)/transmitting means 840 and egress ports/egress means 850 for transmitting the data; and a memory/memory means 860 for storing the data. The network device 800 may also comprise optical-to-electrical (OE) components and electrical-to-optical (EO) components coupled to the ingress ports/ingress means 810, the receiver units/receiving means 820, the transmitter units/transmitting means 840, and the egress ports/egress means 850 for egress or ingress of optical or electrical signals.

[0080] The processor/processing means 830 is implemented by hardware and software. The processor/processing means 830 may be implemented as one or more CPU chips, cores (e.g., as a multi-core processor), field-programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), and digital signal processors (DSPs). The processor/processing means 830 is in communication with the ingress ports/ingress means 810, receiver units/receiving means 820, transmitter units/transmitting means 840, egress ports/egress means 850, and memory/memory means 860. The processor/processing means 830 comprises a virtual pipeline architecture module 870. The virtual pipeline architecture module 870 is able to implement the methods disclosed herein. The inclusion of the virtual pipeline architecture module 870 therefore provides a substantial improvement to the functionality of the network device 800 and effects a transformation of the network device 800 to a different state. Alternatively, the virtual pipeline architecture module 870 is implemented as instructions stored in the memory/memory means 860 and executed by the processor/processing means 830.

[0081] The network device 800 may also include input and/or output (I/O) devices/I/O means 880 for communicating data to and from a user. The I/O devices EO means 880 may include output devices such as a display for displaying video data, speakers for outputting audio data, etc. The I/O devices EO means 880 may also include input devices, such as a keyboard, mouse, trackball, etc., and/or corresponding interfaces for interacting with such output devices. [0082] The memory/memory means 860 comprises one or more disks, tape drives, and solid- state drives and may be used as an over-flow data storage device, to store programs when such programs are selected for execution, and to store instructions and data that are read during program execution. The memory/memory means 860 may be volatile and/or non-volatile and may be read-only memory (ROM), random access memory (RAM), ternary content-addressable memory (TCAM), and/or static random-access memory (SRAM).

[0083] While several embodiments have been provided in the present disclosure, it may be understood that the disclosed systems and methods might be embodied in many other specific forms without departing from the spirit or scope of the present disclosure. The present examples are to be considered as illustrative and not restrictive, and the intention is not to be limited to the details given herein. For example, the various elements or components may be combined or integrated in another system or certain features may be omitted, or not implemented.

[0084] In addition, techniques, systems, subsystems, and methods described and illustrated in the various embodiments as discrete or separate may be combined or integrated with other systems, components, techniques, or methods without departing from the scope of the present disclosure. Other examples of changes, substitutions, and alterations are ascertainable by one skilled in the art and may be made without departing from the spirit and scope disclosed herein.