JP2002198999A - Non-blocking and multi-context pipeline system processor - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a packet processor optimizing the processing ability by processing plural pipelines in parallel in various stages in a pipeline system. SOLUTION: In each stage, plural packets are processed internally by a sub-processor in the pipeline system. In an embodiment, packets are processed in a round robin system. When a particular packet is processed in a particular stage, the packet can move to the next stage passing other packets which have not completed the process. In another embodiment, a packet is continues by processed until a conditional branch command to cause a potential function stop or any other command happen. When such a command happens, a next usable packet is selected and processed instead of wasting the processing cycles during the function stop or processing the present packet based on the expected result.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION This application is filed on Nov. 7, 2000, entitled "High Speed
Provisional Application No. 60 / 246,647, entitled "ed Network Processor" and March 2001.
"Non-Blocking, Mul
ti-Context Pipelined Proc
Provisional Application No. 60/278310 entitled "Essor"
Claim the benefits of the issue, the contents of which are incorporated herein by reference.

[0002] The present invention relates generally to packet switched controllers in data networks, and more particularly to
It relates to maximizing the use of pipelined packet processors when processing incoming data packets.

[0003]

2. Description of the Related Art After completing all processing tasks for a first packet data, a legacy packet processor
Of packet data is started. A conventional pipelined packet processor may provide a streamlined packet processor associated with a legacy packet processor by allowing processing to begin on a second packet data before completing the processing of the first packet data. Perform processing. Such a conventional pipeline strategy is generally achieved by performing different sets of processing tasks that are performed individually at different stages of the pipeline, ie, processing different packets in parallel at different stages.

[0004] One problem with the described conventional pipelined packet processing is that the stages are blocking. Specifically, the speed of the processing pipeline is only as fast as the slowest packet in the chain. A packet that has been processed earlier in the current stage generally has to wait for progress to the next stage if the next stage is processing another frame. That is, the processing capacity of the current stage may not be fully utilized while waiting for the completion of the processing of the next stage.

Another problem with conventional processor technology is in executing conditional branch instructions, which are generally executed during each stage of packet processing. Conditional branch instructions are:
It takes the form of "if <condition> then <condition>". Determining whether a branch condition is true generally requires several processor cycles while the information is retrieved, decoded, executed, and written. Since the next conditional branch instruction to be executed depends on the result of the previous branch condition, conventional processors either wait several processor cycles until the result is actually returned, or based on the predicted result. Either continue processing. Both of these solutions can be quite negative in time. Waiting for actual results can effectively delay processing, while processing based on predicted results can result in loading erroneous instructions that may need to be removed later. is there.

[0006] Therefore, there is a need for a packet processor with improved throughput and processing efficiency.
The processing power of such a processor should not be underutilized while waiting for the next stage to become available and / or for the outcome of a branch condition. At the same time, such processors should not be susceptible to the risk of mispredictions.

[0007]

SUMMARY OF THE INVENTION The present invention addresses the efficient use of the packet processing capabilities of packet processors that process multiple packets in parallel in various pipeline stages.

[0008]

SUMMARY OF THE INVENTION In one embodiment of the present invention, a packet processor includes a plurality of logical blocks (also called stages). The first of packet processors
Performs one or more processing operations on the packet data, and the second logical block performs one or more operations on the packet data in response to the packet data output from the first logical block. Perform multiple processing operations. At least one of the first or second logical blocks
Before outputting the packet data to the at least one logical block in response to the packet data input at time T, the packet data is transmitted to the at least one logical block in response to the packet data input at time T + t where t> 0. It is preferable to output to one logical block.

In another embodiment of the present invention, a packet processor includes a plurality of logical blocks, each logical block receiving a first packet data associated with a first packet at time T, and a time t> 0 An input is provided for receiving second packet data associated with the second packet at T + t. Each logical block further includes a storage device for storing the first packet data and the second packet data, and a sub-processor coupled to the storage device. The sub-processor alternately performs processing of the first packet data and processing of the second packet data.

In yet another embodiment of the present invention, a packet processor includes a plurality of logical blocks, each logical block including a first packet data associated with a first packet and a second packet associated with a second packet. 2 includes an input section for receiving the packet data. Each logical block further includes a storage device for storing the first packet data and the second packet data, and a sub-processor coupled to the storage device. The sub-processor is
The processing is switched from the processing of the first packet data to the processing of the second packet data, and at the same time, the processing result for the first packet data is waited.

In yet another embodiment of the present invention, a pipelined processor includes a plurality of logical blocks.
The first logical block performs a first operation based on a first processing instruction associated with the first packet, and transfers the first processing instruction to a second logical block for performing a second operation. I do. The first logical block is a potential stumbling block when processing the first processing instruction.
If (tall) is expected, a second processing instruction associated with the second packet is received. The first logic block performs the first operation based on the second processing instruction in parallel with the second operation based on the first processing instruction.

Therefore, it should be highly appreciated that the present invention enables efficient use of the packet processing capability of the packet processor. By exchanging packets being processed within a particular stage, it is possible for an earlier processed packet to overtake another packet that is still being processed. In addition, if an outage occurs when processing the current packet, by exchanging packets to process the next packet, it is possible to make full use of the processor and simultaneously wait for the processing result, And / or eliminate the negative risk of misprediction.

[0013] These and other features, aspects, and advantages of the present invention will become more fully understood when considered in conjunction with the following detailed description, the appended claims, and the accompanying drawings.

[0014]

FIG. 1 is a block diagram of a packet switching controller for classifying and routing incoming packet flows. The packet switching controller
It preferably includes a packet processor 12 coupled with various resources according to one embodiment of the present invention. The packet processor 12 is an application specific IC (ASIC: appl).
communication specific integrated circuit), but can also be implemented in any known hardware, firmware, or both.

The packet processor 12 preferably includes a plurality of processors operating independently of each other in a serial pipeline system. The independent operation of the sub-processor allows parallel processing of different packet data at different stages of the pipeline. Further, each sub-processor is also internally pipelined to allow for the current processing of multiple instructions associated with one or more packets within each stage.

The various resources associated with processor 12 include one or more lookup engines 14, police engines 16, and / or any other resources 18 to assist in processing and routing incoming packet flows. Other resources 18 include quality of service (Q
oS (quality of service) can include, but is not limited to, classification engines, access control lists, and the like.

[0017] Processor 12 may include Ethernet frames, ATM cells, TCP / IP and / or UDP / IP packets, and other layers 2 (data link / MAC layers), 3 (network layers) or 4 layers. It is preferable to receive an inbound packet that can include (transport layer) data units. Processor 12 preferably creates a frame context for each input frame by storing all or some of the information associated with the frame, such as specific memory components, eg, frame memory, protocol memory, and register memory. The frame memory preferably contains the packet header information. The protocol memory preferably stores a protocol table containing one or more pointers to the protocols contained in the frame header memory. The register memory preferably stores any additional information about the frames required for processing.

Processor 12 preferably processes the context at each stage of the pipeline, where the sub-processors at a particular stage perform operations for the context, change the context as needed, and The context is transferred to the next stage in order to perform the operation in the sub-processor. At any given stage of the pipeline, the sub-processors preferably exchange various different frame contexts in processing the context. In one embodiment of the invention, frame contexts are processed in a round-robin fashion, i.e., constantly cycling between all contexts. The number of contexts is preferably equal to the number of pipeline stages of the sub-processor plus the number required to transfer data to and from the sub-processor. According to this embodiment, if processing of the current context has been completed at the expiration of the context processing time,
Even if the processing time assigned to the entire stage has not expired, it is preferably removed from the circulation and output to the next stage. That is, because each stage of the pipeline is non-blocking, a context that requires a relatively short processing time can overtake a context that requires a relatively long processing time at that stage of the pipeline.

According to another embodiment of the invention, the exchange of frame contexts is based on detecting a potential outage during the processing of the current context. For example, a stall may occur when processing a conditional branch instruction in a context or an external memory access. When such a potential processing outage occurs, the sub-processor preferably switches contexts to the next context frame that is ready for processing. The next available context frame is also processed until a potential processing outage occurs.

FIG. 2 is a more detailed functional block diagram of processor 12 including various pipeline stages 20a-20c according to one embodiment of the present invention. Each pipeline stage 20a-20c preferably comprises a stage sub-processor 22a-22c and a stage buffer 2
Preferably, it is a logical block in the processor 12 including 4a to 24c. The stage sub-processor is preferably a microprocessor engine configured to perform certain processing operations on the frame context, change the context as needed, and transfer the context to the next stage in the pipeline. . For example, processing operations such as classification, address lookup, packet policing, packet transfer, and program editing can be performed at individual stages of the pipeline.

The stage buffer is preferably configured to hold the frame context while one or more resources 12, 16, or 18 are processing information generated for the context. Once the result is received from the resource, the sub-processor removes the context from the stage buffer and transfers it to the next stage.

Various stages 20a-2 of the pipeline
0c preferably run independently of each other to allow for parallel processing of frame contexts at various stages. According to one embodiment of the invention, each stage is non-blocking. Specifically, since each of the sub-processors 22a to 24c processes a plurality of frame contexts at a time, a frame requiring only a relatively short processing time can overtake a frame requiring a relatively long processing time. Becomes possible. That is, if processing is completed early, the sub-processor need not wait for the expiration of the processing time assigned to that stage before transferring the context to the next stage.

FIG. 3 is a functional diagram of a particular stage 30 of the pipeline according to one embodiment of the present invention. The particular stage 30 can be similar to the stages 20a-20c of FIG. The context from the previous stage is received at a particular stage 30 and stored in a stage buffer 32, which may be similar to stage buffers 24a-24c.

Preferably, the message-in buffer 34 receives one or more messages from one of the resources 14, 16 or 18 with processing results generated for the context. The one or more results are queued in a message-in buffer 34, which is preferably implemented as a FIFO buffer. The input message handler 36 dequeues the message and retrieves the associated context from the stage buffer 32.
The input message handler updates its frame context and copies it to the context pool 38. The frame context is marked as available for further processing.

A stage sub-processor 40, which may be similar to sub-processor 22a of FIG. According to one embodiment of the present invention, the contexts of the context pool 38 are processed in a round robin manner. According to this embodiment, the sub-processor 40 includes, for example, 1
Process each context during the assigned context processing time, such as a clock cycle, and after the expiration of the assigned context processing time, exchange contexts to process the next available context in the context pool Is preferred. Preferably, the assigned context processing time is shorter than the overall processing time assigned to a particular stage 30. If the processing of the context is completed by the end of the allocated processing time, the context is preferably transferred to the next stage.

In another embodiment of the invention, the sub-processor processes the context until it encounters an instruction that may cause a stall, such as a conditional branch instruction or an external memory access. At this point, instead of waiting for a result to be returned, the subprocessor performs a context swap and processes the next instruction in the next available context in the context pool.

Preferably, the internal pipelined architecture of stage sub-processor 40 allows for the parallel processing of various instructions that process context within each stage. When processing instructions in a particular context, the sub-processor may, for example, fetch instructions,
Performs multiple operations such as decoding and executing instructions and memory access. Each operation is preferably executed in each stage of the pipeline system internal to the sub-processor 40.

While processing a particular context, sub-processor 40 sends out several message commands. The message commands are preferably queued in a message command buffer 42, which is preferably implemented as a FIFO buffer. Preferably, the message builder 44 retrieves the message command from the message command buffer 42 and processes it to create an output message for that context. For example, outgoing messages may include source / destination addresses to look up in the routing table,
Alternatively, a police ID for policing a packet may be included.

The message builder is preferably a coprocessor that processes message commands in parallel with the sub-processor. The output message is preferably FI
It is preferably enqueued in a message out buffer 46 implemented as a FO buffer. The output message is transmitted to an external resource 14, 16, or 18 and waits for a result from the resource. When the processing of the context of the current stage is completed, the context is removed from the context pool 38, transferred to the next stage, and stored in the next stage buffer. If there is no stage buffer in the next stage, the context is preferably copied directly to the context pool 38.

FIG. 4 is a flowchart for processing a context according to one embodiment of the present invention. The process starts, and at step 50, the input message handler 36
Determines whether context should be added to the context pool. If the response is positive, the context is added to the context pool 38 at step 52. At step 54, stage sub-processor 40 selects the next context in the context pool. Step 5
At 6, the selected context is processed for a fixed amount of time allocated for context processing, such as, for example, one clock cycle.

At step 58, it is determined whether the processing of the context has been completed. If the response is positive, at step 60, the context is removed from the context pool and output to the next stage at step 62, allowing the context to overtake other contexts with longer processing times. If the processing of the context is not completed, as determined in step 58, the next context is selected for processing, but the current context is not removed from the cycle.

FIG. 5 is a flowchart for processing a context according to another embodiment of the present invention. The process starts and at step 51 the input message handler 36 determines whether to add a context to the context pool. If the response is positive, the context is added to the context pool 38 in step 53. At step 55, stage sub-processor 40 selects the next available context in the context pool. At step 57, the sub-processor determines whether a potential processing outage occurs. If the response is positive, the sub-processors swap contexts and select the next available context in the context pool to process.

However, if a potential processing outage does not occur at step 57, the subprocessor processes its context until either processing is completed or a potential processing outage is encountered. I do. When the processing of the context is completed at the time of the determination of step 61,
In step 63, the context is deleted from the context pool, and in step 65, it is output to the next stage.

FIG. 6 is a flowchart of the operation performed when processing a specific instruction of a context according to an embodiment of the present invention. In step 70, the stage sub-processor performs an instruction fetch operation. At step 72, the instruction is decrypted and executed at step 74. Step 76
Preferably, the memory access is performed for writing back the result of the execution. If the instruction is a conditional branch instruction, the result of the instruction is preferably a true or false value that determines the next instruction to be fetched, interpreted and executed.

FIG. 7 is a diagram of the processing operation illustrated in FIG. 5 when a plurality of contexts are applied according to the embodiment illustrated in FIG. At clock cycle 1, in the first stage of the internal pipeline, the sub-processor processes instruction I of context 1 by performing an instruction fetch operation. If an instruction is identified as an instruction that introduces a potential outage at this internal stage, the next context flag is generated to swap contexts. Identification of potential outages may be possible by encoding such information directly into the instructions. For example, the instruction causing the potential stall may include a stall bit set to "1".

At clock 2, the subprocessor transfers instruction 1 to the instruction interpretation stage of the internal pipeline. At the same time, the instruction fetch stage of the processor becomes available for fetching new instructions. However, because the next context flag is set, the subprocessor fetches the next available context in the cycle, ie, instruction J of context 2, instead of fetching the next instruction in context 1. Instruction J in the illustrated example does not cause a potential stall. Therefore, context 2
Instructions continue to be fetched and inserted into the processing chain of the sub-processor until a potential stall is detected.

At clock cycle 5, a potential stall is detected when processing instruction J + 3 in context 2. As a result, an exchange context flag is generated,
The instruction in the next available context in the cycle is fetched in clock cycle 6. In the illustrated example, instruction K from context 3 is fetched for processing. At clock cycle 8, the sub-processor decodes instruction K + 2 from context 3 causing another stall. This causes a context exchange to the next available context during cycle 9, which in this example is context 1. The result of instruction I is then available, so that the next instruction can be processed for Context 1 without the negative side of mispredictions or other immediate outages.

Although the invention has been described in certain specific embodiments, it will not be difficult for those skilled in the art to devise variations without departing from the scope and spirit of the invention.
Therefore, it is to be understood that the invention may be practiced other than as specifically described. Therefore, the present embodiments of the invention are to be considered in all respects as illustrative and not restrictive, and the scope of the present invention is not limited to the foregoing description, but to the following claims and claims It should be taken to be indicated by the equivalent.

[Brief description of the drawings]

FIG. 1 is a block diagram of a packet switching controller having a packet processor for classifying and routing incoming packet flows.

FIG. 2 is a more detailed functional block diagram of a packet processor including various pipeline stages according to one embodiment of the present invention.

FIG. 3 is a functional diagram of a particular stage of a pipeline according to one embodiment of the present invention.

FIG. 4 is a flowchart for processing a context according to one embodiment of the present invention.

FIG. 5 is a flowchart for processing a context according to another embodiment of the present invention;

FIG. 6 is a flowchart of operations performed by a stage processor when processing a specific instruction of a context according to the embodiment illustrated in FIG. 5;

FIG. 7 is a diagram of pipelined operation when processing multiple contexts according to the embodiment illustrated in FIG.

[Explanation of symbols]

12 Processor 14 Lookup Engine (Resource) 16 Police Engine (Resource) 18 Other Resources (Resource) 20a, 20b, 20c, 30 Stage 22a, 22b, 22c, 40 Stage Subprocessor 24a, 24b, 24c, 32 Stage Buffer 34 Message In Buffer 36 Input Message Handler 38 Context Pool 42 Message Command Buffer 44 Message Builder 46 Message Out Buffer

Continuing the front page (72) Inventor Gjerold Wheeler United States, Washington 99216, Spokane, East Fourth Avenue 12608 Third Avenue 16521 F-term (reference) 5K030 GA01 HA08 KA01 LE04

Claims (22)

[Claims] A first logical block for performing one or more processing operations on the packet data; and a first logical block for responding to the packet data output from the first logical block. A packet processor comprising a plurality of logical blocks including one or more second logical blocks for performing one or more processing operations,
Or at least one of the second logical blocks is at time T
Before outputting the packet data to said at least one logical block in response to the packet data input at
A packet processor that outputs packet data to the at least one logical block in response to the packet data input at time T + t where t> 0. 2. The at least one of the first and second logical blocks alternately performs processing of the packet data input at time T + t and processing of the packet data input at time T. 2. The packet processor according to 1. 3. A first logical block for performing one or more processing operations on the packet data, and a first logical block on the packet data in response to the packet data output from the first logical block. A packet processor comprising a plurality of logical blocks including one or more second logical blocks for performing one or more processing operations,
Or a packet processor that receives packet data at time T + t where t> 0 before at least one of the second logical blocks outputs the packet data received at time T. 4. The method according to claim 3, wherein the at least one of the first and second logical blocks alternately performs processing of the packet data received at time T + t and processing of the packet data received at time T. The packet processor as described. 5. A packet processor including a plurality of logical blocks, each logical block receiving a first packet data associated with a first packet at time T, and a second packet data at time T + t where t> 0. An input for receiving second packet data associated with the packet of the following, a storage device for storing the first packet data and the second packet data, and a sub-processor coupled to the storage device, wherein the sub-processor comprises: , Processing of the first packet data and the second
And a sub-processor that alternately performs the processing of the packet data and outputs the second packet data to the next logical block before outputting the first packet data. 6. The input unit receives the third packet data associated with the third packet at time T + t ′ where t ′> t before outputting the first or second packet data. A packet processor according to claim 1. 7. A packet processor including a plurality of logical blocks, wherein each logical block stores first packet data associated with a first packet and second packet data associated with a second packet. An input unit for receiving; a storage device for storing first and second packet data; and a sub-processor coupled to the storage device, wherein the sub-processor is configured to perform processing from the first packet data to a second A packet processor that switches to packet data processing and simultaneously waits for a processing result of the first packet data. 8. The packet processor according to claim 7, wherein the processing result is a result of a conditional branch instruction. 9. A pipeline processor having a plurality of logical blocks, wherein the first processor performs a first operation based on a first processing instruction associated with a first packet, and performs a first processing instruction on the first processing instruction. A first logical block for transferring to a second logical block to perform the second operation, said first logical block anticipating a potential stall in processing the first processing instruction. Receiving a second processing instruction associated with a second packet,
Is a pipelined processor that performs a first operation based on a second processing instruction in parallel with a second operation based on the first processing instruction. 10. The first logic block receives a third processing instruction associated with the first packet if a potential outage is not anticipated in processing the first processing instruction. The pipeline type processor according to claim 9, wherein 11. The pipelined processor of claim 9, wherein the potential stall is caused by a conditional branch instruction. 12. A first logical block for performing one or more processing operations on packet data, and a first logical block for responding to the packet data output from the first logical block. And a second logical block for performing one or more processing operations, the method comprising: processing a packet in a packet processor, the method comprising: Receiving the first packet data; receiving the second packet data at a time T + t where t>0; and processing the second packet data. Before outputting the fourth packet data to the second logical block in response to the first packet data input at the time T, the time T + Method comprising the steps of: in response to a second packet data input and outputs a third packet data to the second logical blocks. 13. The method of claim 12, further comprising the step of alternately processing the second packet data input at time T + t and processing the first packet data input at time T. 14. A first logical block operable to perform one or more processing operations on packet data, and a first logical block responsive to the packet data output from the first logical block, and A second logical block for performing one or more processing operations on the packet in a packet processor, wherein at time T the first logical block is the first logical block. Receiving the first packet data to the second logical block; and outputting the first packet data received at time T to the second logical block, t> 0 Receiving the second packet data at a time T + t of the first logical block. 15. The method of claim 14, further comprising alternately processing the second packet data received at time T + t and processing the first packet data received at time T. 16. A method for processing a packet in a packet processor including a first logical block and a second logical block, the method comprising: a first processor associated with a first packet at a time T; Receiving the packet data in the first logical block; receiving the second packet data associated with the second packet in the first logical block at time T + t where t>0; A method comprising: alternating between processing and processing of the second packet data; and outputting the second packet data to the second logical block before outputting the first packet data. 17. The method according to claim 16, further comprising the step of receiving third packet data associated with the third packet at time T + t ′ where t ′> t before outputting the first or second packet data. The method described in. 18. A method for processing a packet in a packet processor including a first logical block and a second logical block, the method comprising: a first logical block associated with the first packet in the first logical block. Receiving the first packet data; receiving the second packet data associated with the second packet in the first logical block; processing the first packet data; Switching from the processing of the first packet data to the processing of the second packet data, and simultaneously waiting for a processing result of the first packet data. 19. The method according to claim 18, wherein the processing result is a result of a conditional branch instruction. 20. A method for processing a packet in a pipelined processor having a plurality of logical blocks, the method comprising: a first processing instruction associated with a first packet in a first logical block. Performing a first operation on the basis of: transferring a first processing instruction to a second logical block to perform a second operation; Receiving a second processing instruction associated with a second packet in a first logical block if an outage is expected, wherein the first logical block is based on a first processing instruction based on the first processing instruction. Performing a first operation based on a second processing instruction in parallel with the second operation. 21. The method further comprises receiving a third processing instruction associated with the first packet in the first logical block if a potential outage is not anticipated in processing the first processing instruction. The method according to claim 20. 22. The method of claim 20, wherein the potential stall is caused by a conditional branch instruction.