Patent Application
20110194450
1. Field of the Invention
The invention relates to a method and apparatus for high performance switching in local area communications networks. In particular, the invention relates to a buffer management and flow control mechanism that utilizes priority groups in the handling of packets in the network device, so that flows of data and types of data can be managed in ways that allow for all resources to be efficiently utilized.
2. Description of the Related Art
A switching system may include one or more network devices, such as an Ethernet switching chip, each of which includes several modules that are used to process information that is transmitted through the device. Specifically, the device may include at least one ingress module, a Memory Management Unit (MMU) and at least one egress module. The ingress module may include switching functionality for determining to which destination port a packet should be directed. The MMU is used for storing packet information and performing resource checks. The egress module may be used for performing packet modification and for transmitting the packet to at least one appropriate destination port. One of the ports on the device may be a CPU port that enables the device to send and receive information to and from external switching/routing control entities or CPUs. Some devices also include a CPU processing module through which the device interfaces with external CPU ports.
In the processing of datagrams, such as packets, certain packets may receive preferential treatment when compared to other packets. As such, certain packets may be assigned a higher Quality of Service (QoS), such that those packets are given preferred treatment. This preferred treatment may be given, for example, to packets where time sensitive receipt of those packets is important. In many prior art systems, many QoS states are assigned, so that varying degrees of handling and prioritization can be provided. However, even if a small amount of bandwidth is allocated to a particular QoS state and is not used, that bandwidth is “wasted,” in that it could be utilized by other resources. Thus, there is a need in the prior art for systems that allow for dynamic management of buffers and thresholds to allow for efficient utilization of all resources of a network device.
For the present invention to be easily understood and readily practiced, various embodiments will now be described, for purposes of illustration and not limitation, in conjunction with the following figures:
The present invention is directed to many embodiments that provide many useful features with respect to buffer management and thresholding. These features are briefly discussed below and in greater detail in the sections that follow. These features include the grouping of Quality of Service Priorities into Priority Groups (PGs) and guarantees of minimum bandwidth for each Priority Group, and each port. The buffer management and flow control mechanism also includes dynamic sharing of buffer space on a per-port and per-priority group basis, per-priority group and per-priority flow control and guarantees buffer space allocation (per-priority group headroom) on a per-input port/PG basis to guarantee lossless behavior. A reserved “global headroom” buffer space is used on a first-come, first served basis to allow non-lossless traffic to complete a partially received packet. This allows for the network device to behave in a fairer manner for large and small packet sizes. User-controllable modes allow the user to select the intra-packet discard policy when a threshold is reached and a new mechanism to guarantee a minimum buffer allocation on a per-output port/queue basis which still makes maximum use of the buffer for multicast packets.
Device 100 can also include a number of ports to send and receive data, such as Port 0 to PortX, 108A-108X, and Port X+1 to Port Y, 109A-109X. The ports can be separated and are serviced by different ingress and egress port modules to support the dual-pipeline structure. One or more internal fabric high speed ports, for example a highspeed port, or more external Ethernet ports may be configured from the above-discussed ports. The network device can also include a CPU port 110 and a CPU processing module 11 to communicate with an external CPU. High speed ports are used to interconnect various network devices in a system and thus form an internal switching fabric for transporting packets between external source ports and one or more external destination ports. As such, high speed ports are not externally visible outside of a system that includes multiple interconnected network devices. CPU port 110 can be used to send and receive packets to and from external switching/routing control entities or CPUs. Device 100 interfaces with external/off-chip CPUs through a CPU processing module 111, which interfaces with a PCI bus that connects device 100 to an external CPU.
Network traffic also enters and exits device 100 through external ports 108A-108X and 109A-109X. Specifically, traffic in device 100 is routed from an external source port to one or more unique destination ports. In one embodiment of the invention, device 100 supports physical Ethernet ports and logical (trunk) ports. A physical Ethernet port is a physical port on device 100 that is globally identified by a global port identifier. In an embodiment, the global port identifier includes a module identifier and a local port number that uniquely identifies device 100 and a specific physical port. The trunk ports are a set of physical external Ethernet ports that act as a single link layer port. Each trunk port is assigned a global trunk group identifier (TGID). According to an embodiment, device 100 can support up to 128 trunk ports, with up to 8 members per trunk port, and up to 29 external physical ports.
Once a packet enters device 100 on a source port 109A-109X or 108A-108X, the packet is transmitted to one of the ingress modules 102A or 102B for processing. Packets may enter device 100 from a XBOD or a GBOD. The XBOD is a block that has one 10GE/12G MAC and supports packets from high speed ports and the GBOD is a block that has 12 10/100/1G MAC and supports packets from other ports.
The architecture of the network device provides for the ability to process data received quickly and also allows for a flexibility of processing. A part of this flexibility comes from the pipeline structure that is used to process packets once they are received. Data from the packet and attributes of that packet move through the modules of the network device, discussed above, in a pipeline structure. Each stage in the pipeline structure requires a set number of clock cycles and the packets are processed in order. Therefore, the packet is parsed, table lookups are performed, a decision routing process is performed and the packet is modified, before being sent out on an egress port. Each stage in the pipeline performs its function so that the overall function of the network device is achieved.
Arbiter 202 collects packet data and control information from MMU 104 and read/write requests to registers and memories from the CPU and synchronizes the packet data and control information from MMU 104 and writes the requests from the CPU in a holding register. Based on the request type from the CPU, arbiter 202 generates pipeline register and memory access instructions and hardware table initialization instructions. After arbiter 202 collects packet data, CPU requests and hardware table initialization messages, it generates an appropriate instruction. According to an embodiment, arbiter 202 generates a Start Cell Packet instruction, an End Cell of Packet instruction, a Middle Cell of Packet instruction, a Start-End Cell of Packet instruction, a Register Read Operation instruction, a Register Write Operation instruction, a Memory Read Operation instruction, a Memory Write Operation instruction, a Memory Reset Write Operation instruction, a Memory Reset Write All Operation instruction and a No Operation instruction. Egress pipeline resources associated Start Cell Packet instructions and Start-End Cell of Packet instructions are given the highest priority by arbiter 204. End Cell of Packet instructions, Middle Cell of Packet instructions, Register Read Operation instructions, Register Write Operation instructions, Memory Read Operation instructions and Memory Write Operation instruction receive the second highest priority from arbiter 204. Memory Reset Write Operation instructions and Memory Reset Write All Operation instructions receive the third highest priority from arbiter 204. No Operation instructions receive the lowest priority from arbiter 204.
After receiving an instruction from arbiter 204, the parser 206 parses packet data associated with the Start Cell of Packet instruction and the Start-End Cell of Packet instruction using the control information and a configuration register transmitted from arbiter 206. According to an embodiment, the packet data is parsed to obtained L4 and L3 fields which appear in the first 148 bytes of the packet. Table lookup stage 208 then receives all packet fields and register values from parser 206.
As discussed above, the network device can, according to certain embodiments, use two sets of IP/EP pipelines to support 20 ports of 10GE (or 16 ports of 12G highspeed) as shown in
Each buffer handles 10 input ports and 10 output ports, making the bandwidth requirement for each memory unit 100 Gbps, bi-directional, according to certain embodiments.
The Admission control, including thresholds, and enqueueing occur at each cross-point buffer and are independent of the other crosspoint buffers. Therefore, separate cell buffer counts and queues are provided at each crosspoint. This means that each output port will own two physical queues for each logical queue implemented. The two physical queues have packets that are of the same class to the same output port, but from different sets of input ports. The output port and queue scheduling should to be done on a unified basis for each port. Each port scheduler should see the physical queues at each of two crosspoint buffers, but only needs a scheduling database (min/max values) on a per logical queue basis. One difference from prior art network devices is the addition of 2 extra queues at each highspeed output port, named the SC and QM queues. The CONTROL opcode can be used to map packets in the SC queue when in a specific mode. Legacy packets that are E2EFC or E2ECC packets (as determined by the DMAC address) will be mapped into the QM queue of the egress highspeed port when in the specific mode.
The MMU uses the XQ queuing structure with 2 k XQ's per port (29 ports), in one embodiment. The XQ's are very different for the GE, HG (i.e. highspeed port), and CPU ports. Much of the header information that is required to format outgoing packets on the HG ports is held in the HG's XQ. This is because the network device may have 4 HG ports with 2 k XQ entries each, or a total of 8 k HG XQ's, and there are 16 k cells. With all ports potentially HG ports, according to one embodiment, much of the data in the HG XQ's is moved the Packet Header table (indexed by cell address). The functional part of the XQ is broken up into two separate memories: pktLink and pktHDR. Most of the packet information is not contained in the pktHDR which is shared by all ports and queues. The pktLink is used to link one packet to the next to form a linked-list queue. The only portion that is not shared between ports is the pktLink table, so that multicast packets can be linked anywhere in the queue for different ports. This allows all CoS queues within a port to share all of the pktLink entries for that port. Also, the pktLink size is changed to be 4 k per port (the same as the number of cells). With a complete set of packet links (4 k) per port, more of the memory can be flexibly used, enabling maximum utilization with the dynamic threshold scheme. This obviates the need for thresholds on a packet basis. All thresholds are only based on cell counters per queue and per port. Also, there is no need for a first_cell pointer in the XQ entry since the address of the pktLink entry is the same as the first_cell address.
The scheduling mechanism for each port schedules between the eight best effort queues. This is illustrated in
The ingress control and data flow process is illustrated in
An example of the sequence of events for egress is illustrated in
After the output queue thresholds and input port thresholds are calculated for an incoming cell, the admission control block makes a final decision on whether or not to accept the cell into the data buffer. Input for this decision comes from several places that can cause cells to be discarded, including the output-queue thresholds, the input-port thresholds, and the buffer full condition (from CFAP). The top-level admission flow is shown in
As illustrated in
The following inputs are used to make the final accept/discard decision: ip_discard, op_discard, buffer_full, new_cell_adrs_valid, pbi.purge, and ASF_done. ip_discard is used to determine when to drop for input port thresholds and op_discard is used to determine when to drop for output port thresholds, buffer_full is used when no cell is available from CFAP, memory is full, and any incoming cell will be discarded. When asserted, it stays on until the reset value is reached (has hysteresis). This is actually asserted before the CFAP runs out of cell addresses (the hold-back amount). new_cell_adrs_valid is sent from CFAP, this is usually asserted every cycle. The cell address can be valid even if buffer_full is asserted. If there is really no new cell address available or the CFAP has a parity error, then this signal will not be asserted, which means there is no place to write the current cell from the PBI. The incoming cell will be discarded. This signal has no hysteresis. For pbi.purge, the IP has determined that the packet should be purged (from the PBI bus). For ASF_done, the input from the output thresholds that packet is being enqueued early with this cell for ASF.
As stated above, after the output queue thresholds and input port thresholds are calculated for an incoming cell, the admission control block (ADM) 910 makes a final decision on whether or not to accept the cell into the data buffer. The cell free address pool (CFAP) 920 is implemented as an array of free cell pointers in order to determine available memory slots in the memory buffer 930.
The queuing block 940 links cells together into packets and links the packets together to form one or more port queues. Further, the queuing block handles most of the control information from the IP on the PBI and also generates all of the control fields for each packet and cell when sending data to the EP. When packets/cells are scheduled for transmission the queuing block retrieves the cell pointer and updates all of the queuing structures. The queuing block also determines if “packet replications” are necessary for the packet i.e, whether the traffic is multicast/broadcast traffic, and also determines when each cell can be returned to the free cell pool for re-use after all ports that need the cell have transmitted it. According to an exemplary embodiment of the present invention the queuing block 940 further includes a cell copy count pool (CCP) 945.
The CCP 945 keeps track of how many copies of each cell have been sent out of the MMU. Further, the CCP keeps track of the number of ports that need to transmit a cell before it can be returned to the CFAP. The functions of the CCP include collecting information from dequeue about cells being sent out, providing the threshold block (THD) with cell length information, providing the CFAP with indication when a cell needs to be freed up provide access to CCP memory and parity/ECC, interrupt handling.
Since modifying the CCP count is a read-modify-write operation that should occur in the output pipeline, there is no free cycle to write the initial value when a cell arrives (in the input pipeline). Therefore, a second value, the port_count, is determined when a cell/packet arrives and is written by the input pipeline and only read by the output pipeline. The port_count value is not actually stored, but can be derived value from the port_bitmaps in the pktHDR1. The CCP memory is initialized to all zeros for all cells. So when the first port transmits a cell, it reads ‘0’ from the CCP, but writes (port_count−1). When the last port reads the CCP, it will read ‘1’, writes ‘0’, and returns the cell to the free pool.
An example of how the CCP operates is further illustrated in
Further, at this time according to certain embodiments of the invention, the CCP transmits and indication to the CFAP that this cell can be recycled.
If the CCP is implemented according to the illustrated embodiments, conflicts or “hazards” may exist under certain conditions, some of which hare described below.
For, example, the register files have a Read-Modify-Write latency of 3 clock cycles. In order to avoid any spacing problem or hazards due to the latency, access to the same port, per class-of-service (cos) bucket need to be spaced by 3 to 4 clock cycles.
Further, the CCP RAM according to certain embodiments is implemented with 2 entries per address. Therefore, a hazard may occur between two entries of the same physical address. Still further, since according to this exemplary embodiment, the CCP may receive 2 cells returns per cycle from dequeue. Thus, hazards may occur between cells returned by each EP.
In order to detect and prevent the above mentioned hazards, as well as other hazard conditions, the CCP according to certain embodiment further includes hazard detection logic. A block diagram of the hazard detection pipeline that includes hazard detection logic is illustrated in
The hazard detection logic (HDL), detects hazard conditions including, but not limited to, the above examples and ensures the access to the same physical RAM location are spaced apart by at least 3 clock cycles. This is performed, for example by merging requests to the same location. Specifically, in the event that a hazard condition is detected cell requests to the same location are “merged”, by decrementing the copy count by more than 1.
After the CCP determines that either there are no hazard conditions or that the hazard conditions have been detected and avoided, the CCP transmits hazard-free pointers to the CFAP. After the hazard-free pointers are sent, the CCP RAM is read.
The valid (vld) signals indicate that the cell indicated in the release_ptr signal has been sent out. Since all copies of the cell have been sent out, the cell can now be freed up from the central buffer pool (CBF)/CFAP.
As discussed above, the CCP indicates when a cell is dequeued. Thus, the CCP includes input signals that indicate that 1) a copy of the cell has been sent out on DEQ0/1 (deq0/deq1_to_ccp_valid) and cell info for the information concerning the cell that was sent out on DEQ0/1 (deq0/deq1_ccp_info). The vld signals are asserted when a copy of the cell has been sent out by deq. The valid signal is asserted only once for all replications of he cell on a particular port. However, the vld signal is asserted once for each output port a cell goes out on. Further, according to certain embodiments of the invention and as shown in
The CCP further outputs cell length information to the THD module. The MMU splits the info fields into individual components needed by the THD module. The signal that indicates that a cell has been dequeued is asserted when a copy of the cell has been sent out of the MMU by the DEQ module. It is asserted only once for all of the replications on a particular port. However, it is asserted once each for output port a cell goes on. A signal that indicates that the last copy of a cell is sent in the same cycle as the dequeued signal, but only if one additional condition is satisfied. In addition, to a cell being sent out of the MMU, the cell also needs to have gone out of the last output port. For unicast packets i.e., packets that are directed to only one egress port, this signal is the same as the cell dequeued signal. For multicast packets this signal strobes only once per cell, whereas the cell_dequeued signal strobes N times per cell, where N is the total number of ports in the egress port bitmap.
Returning the
As discussed above, after the hazard-free pointers are sent to the CFAP, the CCP RAM is read. The read data is obtained 3 clock cycles later, according to this example. The CCP then calculates the value to be written into RAM based on the following algorithm. According to certain embodiments of the present invention, the CCP logic module performs these calculations.
If when the cell entry read (ram_rd_val) equals 0, then the value written into RAM equals (cell copy count—a decrement value);
Else, the value written into RAM equals the value read from the RAM (ram_rd_val)—the decrement value.
The decrement value is the total number of decrement requests which is one or greater. The value is equal to the number of hazards detected within the last 5 stages of cell pointers. As discussed above, according to an exemplary embodiment of the present invention there are two “pipes. Therefore, in this example, the decrement value has a maximum value of ten (10).
According to certain embodiments of the present invention the CCP module computes Error Checking and Correction (ECC) bits for the stored data. The CCPs ECC module has the capability to correct single-bit errors and detect double-bit errors. The number of errors are counted and the memory address of the error location is logged for software usage. Further, the CCP module provides host read/write access to the CCP memory for debug. The ECC algorithm uses an extra parity bit to add double-bit error detection feature to the standard single-bit error correction capability of the ECC. The ECC detection/correction logic consists of error syndrome generation, single bit error correction and double-bit error detection and can be pipelined to meet the timing requirements of the design.
One of average skill in the art will also recognize that the functional building blocks, and other illustrative blocks, modules and components herein, can be implemented as illustrated or by discrete components, application specific integrated circuits, processors executing appropriate software and the like or any combination thereof.
Moreover, although described in detail for purposes of clarity and understanding by way of the aforementioned embodiments, the present invention is not limited to such embodiments. It will be obvious to one of average skill in the art that various changes and modifications may be practiced within the spirit and scope of the invention, as limited only by the scope of the appended claims.
This application is a continuation of application Ser. No. 11/583,155, filed on Oct. 19, 2006, now issued as U.S. Pat. No. ______, which claims the benefit of U.S. Provisional Patent Application Ser. No. 60/735,213, filed on Nov. 10, 2005. The subject matter of these earlier filed applications is hereby incorporated by reference.
| Number | Date | Country | |
|---|---|---|---|
| 60735213 | Nov 2005 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 11583155 | Oct 2006 | US |
| Child | 13091338 | US |
