Method and system for virtual output queue allocation
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- MARVELL ASIA PTE LTD
- Filing Date
- 2026-01-23
- Publication Date
- 2026-08-05
Smart Images

Figure 2026127056000001_ABST
Abstract
Description
Background Art
[0001] [Related Applications] This application claims the benefit of U.S. Provisional Application No. 63 / 749,027, filed on January 24, 2025. The entire teachings of the above application are incorporated herein by reference.
[0002] In computer operating and processing systems, data is often sent from one location to another, and a system or process receiving the data may be receiving data from multiple sources at a given time. Further, a source sending data may be able to send data at different data rates. This can be a problem when attempting to aggregate data received from multiple input queues into a single output queue. Embodiments disclosed herein provide an advancement in aggregating output content in multiple queueing systems.
Summary of the Invention
[0003] One embodiment is directed to a system for aggregating output content in a multiple queueing system. Such a system may include a plurality of input queues configured to receive data packets, each received data packet including a plurality of data chunks, the plurality of data chunks for each data packet defining a completed data packet when received in its entirety. Such an embodiment may also include an output buffer configured to maintain a list including each entry of the completed data packets received in each of the plurality of input queues; and control logic configured to read the completed data packets received in at least one of the plurality of input queues based on the entries in the output buffer list.
[0004] According to one embodiment, each entry of a completed data packet listed in the output buffer may include at least one of the following: an indication of the location of the entry in the output buffer, an indication of the source, and the length of the completed data packet. In such an embodiment, the system may be further configured to determine the length of the completed data packet by further configuring the system to determine the total number of chunks in the data packet based on at least one of the first chunk of the plurality of chunks and the last chunk of the plurality of chunks. Furthermore, in such an embodiment, the indication of the location in the output buffer may be based on the time when each input queue of the plurality of input queues received the last chunk of the plurality of data chunks for the data packet.
[0005] According to one embodiment, the output buffer may be further configured to provide the control logic with information about the data packet, such as queue position, packet size, and / or source.
[0006] In one embodiment, in response to the output buffer containing at least one entry for each of the completed data packets, the control logic may be further configured to read the completed data packets corresponding to each entry from at least one of the plurality of input queues and to send the read completed data packets to at least one output queue. In such an embodiment, in response to the read completed data packets being sent as a whole to at least one output queue, the system may delete the respective entries in the output buffer.
[0007] In another embodiment, the final chunk of a given received data packet may include an indication that the data packet was received as a whole. For example, the final data chunk in a data packet may include an indication that it is the end of packet (EOP).
[0008] One embodiment includes a memory configured to hold completed data packets received in the plurality of input queues.
[0009] According to one embodiment, the plurality of input queues is a first set of input queues corresponding to a first type of data channel, the output buffer is a first output buffer corresponding to the first type of channel, and the control logic is a first control logic corresponding to the first type of channel. Such an embodiment also comprises a second set of plurality of input queues corresponding to a second type of channel, a second output buffer corresponding to the second type of channel, and a second control logic corresponding to the second type of channel. Such an embodiment may further comprise an output controller coupled to the first control logic and the second control logic, the output controller configured to orchestrate the transmission of data from the first control logic and the second control logic to the output queues, respectively.
[0010] Another embodiment relates to a method for aggregating output content. The method may comprise the steps of receiving each data packet in each of a plurality of input queues, each received data packet comprising a plurality of data chunks, the plurality of data chunks for each data packet, when received as a whole, define a completed data packet. The method further comprises the steps of maintaining in an output buffer a list containing entries for each of the completed data packets received in each of the plurality of input queues, and in control logic reading the completed data packets received in at least one of the plurality of input queues based on the entries in the output buffer list.
[0011] Another embodiment relates to means for aggregating output content in a multi-queuing system. The method comprises means for receiving data packets in each of a plurality of input queues, each received data packet comprising a plurality of data chunks, the plurality of data chunks for each data packet, when received as a whole, define a completed data packet. The embodiment further comprises means for maintaining in an output buffer a list containing entries for each of the completed data packets received in each of the plurality of input queues; and in control logic means for reading the completed data packets from at least one of the plurality of input queues that have been received, based on the entries in the output buffer list.
[0012] It should be noted that embodiments of methods, systems, and means may be configured to implement any embodiment or combination of embodiments described herein. [Brief explanation of the drawing]
[0013] The foregoing will become clear from the following more specific description of the exemplary embodiments shown in the accompanying drawings, where similar reference numerals refer to the same parts throughout different drawings. The drawings are not necessarily to scale, and instead the emphasis is on illustrating embodiments.
[0014] [Figure 1] This is a workflow diagram illustrating the aggregation of output content in a multi-queuing system according to one embodiment.
[0015] [Figure 2] This is a method for aggregating output content in a multi-queuing system according to one embodiment, and a flow diagram of the components associated with said method.
[0016] [Figure 3] This diagram illustrates the aggregation of output content in a multi-queuing system utilizing an output controller, according to one embodiment.
[0017] [Figure 4] This is a schematic diagram of an exemplary system for aggregating content from multiple multi-input queues according to one embodiment. [Modes for carrying out the invention]
[0018] The following describes exemplary embodiments.
[0019] In a multi-queuing system, there may be a requirement to aggregate the content of multiple input queues located on a single memory into a single output queue, such as a carrier output queue. In such a system, a first subset of the input queues may be configured to receive data packets at a given data rate, and a second subset of the input queues may be configured to receive data packets at a given data rate different from the data rate of the first subset. For example, a given channel stored in memory may be a flexible Ethernet® (flex-e) channel, and a separate channel stored in a separate memory may be a low-bitrate (LB) channel. Embodiments provide a method for aggregating output content received in multiple input queues into a single output queue at a common data rate. If desired, this data rate may differ from the data rates of any of the input queues.
[0020] In a lossless system, that is, a system that retains all information from input to output, the data rate of the output channel should be greater than or equal to the sum of the input queue rates. If the data rate of the output channel is not greater than or equal to the sum of the input queue rates, data may be waiting and accumulating in the input queue while the output queue attempts to catch up, which can become a losing battle.
[0021] In existing systems, which may be referred to herein as "regular mode," the content and data structure of output queues are constructed by copying data in whole from input queues to output queues, or by copying data pointers. In addition, regular mode systems may generate additional output queues for aggregated channels and read data from these generated additional output queues. This legacy approach requires greater power consumption because the data payload must be copied in whole; requires a larger memory footprint because more memory is needed to store the copied data; and suffers from performance losses due to the requirement to access memory to retrieve data.
[0022] Embodiments disclosed herein provide improvements to queuing systems with multiple input queues, i.e., multi-queuing systems, by aggregating channel traffic without copying, moving, or modifying the original data received in the multi-input queues. Embodiments enable the aggregation of data packets received from multiple different sources at various data rates into a single aggregated output queue.
[0023] The embodiment adds an output buffer (refer to 130 in FIG. 1) in parallel with the memory (refer to 140 in FIG. 1), where the output buffer includes a temporary list of completed data packets received in each of the input queues. For example, the output buffer may be a first-in-first-out (FIFO) buffer and may be substantially an output FIFO, i.e., an OFIFO (output-FIFO). In an embodiment, the OFIFO buffer may also include information of the original source queue (i.e., a given input queue), each queue position, and the length of the data packet. The embodiment may also provide a dedicated read-only queue control logic (RO Q-Control) (refer to 150 in FIG. 1) that transmits the completed data packets stored in the memory at the rate of the output queue (refer to 170 in FIG. 1) based on the instructions received by the OFIFO.
[0024] In an embodiment, for each input queue, the input queue control logic (Q-Control) may transmit the data packet to a common payload memory associated with a given channel (i.e., there may be a first payload memory associated with, for example, flex-e and a second payload memory associated with, for example, LB). Further, when Q-Control identifies that the data packet has been received in its entirety, Q-Control may transmit information regarding the completed data packet to the output buffer (refer to 130 in FIG. 1). Such information may include the packet length and each position in the output buffer queue.
[0025] According to one embodiment, when the OFIFO buffer is not empty and there are available active slots in the output queue, RO Q-Control may start reading the data packet received in the payload memory from the original input queue and transmitting the data packet to the output queue. As a result, a situation may occur where the input queue has two identifiers (ID), one for writing (i.e., the original) and one for reading (i.e., the virtual). With this configuration, it may be possible to read and write data without moving the data. For example, each input queue may include two IDs. The first ID may be for the input queue, i.e., for the write operation, and the first ID is unique to the input queue. The second ID may be a virtual ID used for the read operation, and the virtual ID may be shared among the input queues. Therefore, the same data structure (e.g., input queue) may include two different IDs assigned during the system configuration.
[0026] Subsequently, the output queue (refer to 170 in FIG. 1) may continue to read the data packet until the entire data packet is read. When the entire packet is read, the output buffer is "popped" (i.e., the top entry is removed from the buffer, and the next level entry is then promoted to the top entry, where the top entry is the next candidate for transmission to the output queue), and the data packet associated with the next queue position may be transmitted to the output queue. Substantially, Q-Control operates in a store and forward operation mode.
[0027] Therefore, the embodiment substantially remaps the channels without changing the original packet structure. The data packets may be received at different data rates by the input queue, but are output by the system at a common data rate.
[0028] Furthermore, because there is no need to duplicate data by copying or moving it from the input queue to memory, the embodiment saves storage space by not requiring additional memory and saves time by not requiring data to be copied. Thus, the embodiment provides time and memory savings, and as a result, improves performance.
[0029] Figure 1 is a workflow diagram of system 100 for aggregating output content in a multi-queuing system according to one embodiment. Such an embodiment may include multiple input queues. For example, one embodiment may include input queue one (IQ-1) 101, input queue two (IQ-2) 111, and input queue three (IQ-3) 121. Although only three input queues 101, 111, and 121 are illustrated in method 100, it should be understood that method 100 can utilize any number of input queues, as illustrated in input queue "n" (IQ-n) 190.
[0030] The grouping 160 of the components in Figure 1 is further referenced herein in relation to Figure 3.
[0031] A given input queue, for example IQ-1 101, may receive multiple data chunks 103a-n at a given data rate. The data chunks 103a-n, when received as a whole by IQ-1 101, define a completed data packet 104. A given input queue control (Q-Control), for example Q-Control 102 for IQ-1 101, may store the received data packet 104 payload in payload memory, for example payload memory / buffer 140. When Q-Control 102 receives the data packet 104 as a whole, if, for example, chunk 103n indicates that chunk 103n is a packet termination (EOP), Q-Control 102 may write the entry for the completed data packet 104 received by IQ-1 101 to output buffer 130 (i.e., OFIFO). Each of the input queues IQ-1 101, IQ-2 111, IQ-3 21 through IQ-n 191 operates similarly. For example, IQ-2 111 may receive multiple data chunks 113a-n at a given data rate. The data chunks 113a-n define a completed data packet 114 when received as a whole by IQ-2 111. Q-Control 112 may store the data packet 114 payload in payload memory / buffer 140. When Q-Control 112 receives the data packet 114 as a whole, Q-Control 12 may write the entry for the completed data packet 114 received by IQ-2 111 to output buffer 130. Subsequently, IQ-3 121 may receive multiple data chunks 123a-n at a given data rate. Data chunks 123a-n define a completed data packet 124 when received as a whole by IQ-3 121. Q-Control 122 may store the data packet 124 payload in payload memory / buffer 140. When Q-Control 122 receives the data packet 124 as a whole, Q-Control 122 may write the entry for the completed data packet 124 received by IQ-3 121 to output buffer 130.
[0032] According to one embodiment, the output buffer 130 maintains a list of entries for each of the completed data packets (104, 114, 124) received by each of the multiple input queues (101, 111, 121). The output buffer 130 includes information about the queue position 131, the source 132 (e.g., which input queue the instruction is from), and the packet length 133. When each input queue (101, 111, 121) receives its respective completed data packet (104, 114, 124), its respective control logic (102, 112, 122) communicates to the output buffer 130 that it has received the completed packet and also provides the output buffer 130 with an instruction for the data packet length (e.g., size) 133. These entries are placed in the output buffer 130 in a first-in, first-out manner. For example, if IQ-1 101 receives its completed data packet 104 at t=1, where t is an arbitrary time unit, and IQ-2 111 receives its completed data packet 114 at t>1, then the indication for data packet 104 will be placed in a higher queue position 131 in the output buffer 130, regardless of its respective packet length 133. It should be understood that the value provided for packet length 133 is an arbitrary placeholder.
[0033] According to one embodiment, the read-only queue control (RO Q-Control) 150 may receive a command from the output buffer 130 to be sent to the output queue 170 indicating that it is the order of a given packet (i.e., the packet having the next queue position) (for example, an instruction that the output buffer is not empty). The RO Q-Control 150 may then identify a given packet in the payload memory 140 and send the packet from the payload memory 140 to the output queue 170.
[0034] In a lossless system, the depth of the output buffer 130 may have an associated depth equal to the maximum number of data packets that can be stored in the data buffer (e.g., 104). Such a configuration may be advantageous when each data packet is a shared data bus (SDB) packet.
[0035] According to one embodiment, RO Q-Control (e.g., 150) may include a prefetch buffer. The prefetch buffer may be used to minimize or eliminate latency in the payload memory 140 by preparing the next available data packet to be sent before it is requested. For example, if the prefetch buffer has available space, it may be refilled with information about completed data packets.
[0036] Figure 2 is a flow diagram of method 200 for aggregating output content in a multi-queuing system. Method 200 begins in step 201 with receiving each data packet (see 102, 112, 122 in Figure 1) in each of several input queues (see 101, 111, 121 in Figure 1); each received data packet contains several data chunks (see, for example, 103a-n in Figure 1), and the several data chunks for each data packet, when received as a whole, define a completed data packet (see, for example, 104 in Figure 1). Then, in step 202, method 200 continues with maintaining a list in an output buffer (e.g., an OFIFO buffer) (see 130 in Figure 1) containing each entry of the completed data packets received in each of the several input queues. Next, in step 203, method 200 reads completed data packets received in at least one of multiple input queues based on entries in the output buffer list, in control logic (see, for example, 150 in Figure 1).
[0037] In some embodiments of Method 200, each entry of a completed data packet listed in the output buffer may include at least one of the following: an indication of the position of the entry in the output buffer (see 131 in Figure 1) and an indication of the length of the completed data packet (see 133 in Figure 1). Such an embodiment of Method 200 may further include a step of determining the length of each completed data packet by determining the total number of chunks in each data packet (see, for example, 105a-n in Figure 1) based on at least one of a first chunk of a plurality of chunks and a final chunk of a plurality of chunks. For example, the first chunk may include an indication of the size of the data packet, and the embodiment may count the number of chunks received until that indication is reached. In some embodiments, the final data chunk of a plurality of chunks of a given received data packet may include an indication that the data chunk is the final data chunk in the packet, thereby indicating that the data packet has now been received as a whole.
[0038] In method 120, the indication of the position of each entry in the output buffer for completed data packets may be based on the time when each of the multiple input queues received the final chunk of each of the multiple data chunks for each data packet. For example, entries are listed in the output buffer in a first-in, first-out (FIFO) manner. When an input queue receives an indication that the final data chunk for a given data packet has been received, i.e., an indication that the data packet has been received as a whole, each entry for each data packet may be written to the output buffer. The entries in the output buffer are queued relative to the time when each input queue received the data packet as a whole, and for example, entries are listed in a first-in, first-out manner. In some embodiments, information from the output buffer, such as the position of entries in the queue, as well as their packet lengths and input queue numbers, may be provided to RO Q-Control.
[0039] In some embodiments, in response that the output buffer contains at least one entry for each of the completed data packets, Method 200 may also include a step by control logic (i.e., RO Q-Control) to read the completed data packets corresponding to each entry from at least one of a plurality of input queues and send the completed data packets to at least one output queue. In such one embodiment, in response that the completed data packets as a whole have been sent to at least one output queue, Method 200 may then delete the respective entries in the output buffer.
[0040] Some embodiments of Method 200 may further include a memory (see 140 in Figure 1) configured to hold completed data packets received in a plurality of input queues. According to one embodiment, the memory may be any method of data storage.
[0041] According to one embodiment of Method 200, the plurality of input queues may be a first set of input queues corresponding to a first type of data channel (e.g., flex-e), the output buffer may be a first output buffer corresponding to a first type of channel, and the control logic may be a first control logic corresponding to a first type of channel. In such an embodiment, Method 200 may further comprise a second set of plurality of input queues corresponding to a second type of channel (e.g., LB), a second output buffer corresponding to a second type of channel, and a second control logic corresponding to a second type of channel. In such an embodiment, the output controller may be coupled to both the first and second control logics, and the output controller may be configured to orchestrate the transmission of data from the first and second control logics to the output queues, respectively. For example, the output controller may provide instructions to each of the control logics indicating the order in which they should transmit data to the output queue. In this way, the output controller orchestrates the data transmitted to the output queue.
[0042] As disclosed below in relation to diagram 300 in Figure 3, according to one embodiment, one or more input queues among a plurality of input queues may be associated with a first type channel, for example, a Flexible Ethernet® (flex-e) channel (see 160 in Figure 3), and one or more input queues among a plurality of input queues may be associated with a second type channel (see 160 in Figure 3), for example, a Low Bit Rate (LB) channel. The first type channel and the second type channel may receive and transmit data at different rates. In such an embodiment, there may be respective payload memories / buffers (e.g., 140) for the first type channel and respective payload memories / buffers for the second type channel. There may also be respective output buffers (i.e., OFIFOs) for the first type channel and respective output buffers for the second type channel. In addition, there may be respective RO Q-Controls (e.g., 150) for the first type channel and respective RO Q-Controls for the second type channel. In one such embodiment, there may be an output queue 170 for data from a first type of channel and an output queue 370 for data from a second type of channel.
[0043] Such an embodiment may further include an output controller (see 310 in Figure 3) that communicates with the respective RO Q-Controls for the first type channel and the second type channel. The output controller 310 may be configured to provide instructions to a given RO Q-Control (i.e., either the RO Q-Control associated with the first channel type or the RO Q-Control associated with the second channel type) indicating that it is the order in which the given RO Q-Control should send data packets to the output queue 170. Such instructions may be based on a calendar ID associated with a completed data packet received by a given Q-Control (e.g., first ID) and a calendar ID associated with the output controller (e.g., second ID). For example, if there is a match between the calendar ID associated with the Q-Control and the calendar ID associated with the output controller, the data is sent to the respective output queue. The output controller may be configured to provide instructions every clock cycle, substantially alternating between output from the first channel and output from the second channel.
[0044] Figure 3 is a diagram 300 illustrating the aggregation of output content in a multi-queuing system according to one embodiment. In Figure 3, the grouping of component 160 in Figure 1 may be associated with a plurality of input channels associated with a first channel type, e.g., flex-e (e.g., 101, 111, 121 in Figure 1). The grouping of component 360 may be similar to the grouping of component 160 in substantially all embodiments, except that the plurality of input channels associated with the grouping of component 360 may be associated with a second channel type, e.g., LB. The output controller 310 may be configured to communicate with the respective RO Q-Controls associated with 160 and 360. In each clock cycle, the output controller 310 may send instructions to the RO Q-Control associated with either 160 or 360 to send a given data packet to the respective output queue 170 associated with the first channel type 160, or to the respective output queue 370 associated with the second channel type 360. It should be understood that while writes to the output buffer associated with the first channel type and writes to the output buffer associated with the second channel type may occur simultaneously, only one can drive data at a time. In this way, the embodiment aggregates content from multiple input queues at multiple data rates into a single output queue.
[0045] Figure 4 is a schematic diagram of an exemplary system 400 for aggregating content from multiple multi-input queues according to one embodiment. System 400 includes multiple input queues 401a-n associated with a first channel type, e.g., flex-e, and multiple channels 403a-n associated with a second channel type, e.g., LB. Although only two channel types are illustrated and described, it should be understood that the embodiment is sufficient to be implemented with any number of input channels and any number of channel types. Each of the multiple input queues 401a-n and 403a-n also has associated RO Q-Controls, 402 and 404, respectively. System 400 also includes a data buffer associated with a first type memory 405 and a data buffer associated with a second type memory 406. Both data buffers 405 and 406 may include their respective memories and their respective memory control logic. Furthermore, system 400 may include an output buffer 408, i.e., OFIFO, associated with the first type of data, and an output buffer 409 associated with the second type of data. System 400 also includes an output queue 407 for first type (e.g., flex-e) data and an output queue 410 for second type (e.g., LB) data for sending data from System 400 to the outside.
[0046] The embodiments may support both “regular mode” and store-and-forward mode, and may be configured to implement one, the other, or both simultaneously. However, during store-and-forward mode, the control logic operation may differ from that of “regular mode” (legacy methods and systems). In store-and-forward mode, a given data packet must be received in whole and fully stored in the buffer (see 140 in Figure 1) before information about the data packet is written to the output buffer and the payload can be sent to the output queue. In one such embodiment, each input Q-Control logic may count the number of completed data packets in its queue buffer and increment a counter for each counted completed data packet. According to one embodiment, there may be a first counter for the queue size in packets and a second counter for the queue size in chunks. In store-and-forward mode, the counter associated with a packet must be greater than “0” to initiate reading from the queue, whereas during “regular mode”, it may be sufficient for the counter associated with a chunk to not be empty to initiate sending a data packet.
[0047] An additional difference between the embodiment and the legacy system is that, in the embodiment, multiple Q-Control units may share the same carrier channel (e.g., flex-e or LB), but only one carrier channel can drive data at a time. Therefore, to reduce the number of channel buffers required, the embodiment uses a dedicated RO Q-Control to perform read operations and data prefetching. Subsequently, when the output buffer is not empty, the RO Q-Control begins reading data from the prefetch buffer whenever there is a calendar ID match between the data and the output controller, and then sends the data to the output queue. The RO Q-Control continues reading data and sending the data to the output queue until the data packet is read in its entirety. After the data packet has been read in its entirety, each entry in the output buffer is "popped," and the next data packet may become a candidate for transmission to the output queue.
[0048] One embodiment may include loopback operation. Loopback operation also operates in a store-and-forward configuration and utilizes a dedicated carrier channel (e.g., flex-e or LB) to send traffic from shared memory to the outside. However, in the loopback embodiment, the outgoing loopback traffic carrier channel may be different from the incoming loopback traffic channel, i.e., channel remapping may exist. Channel remapping may be performed, for example, on a flex-e channel. Channel remapping may be performed when the output selection RO Q-Control is read. The RO Q-Control is read when the calendar channel ID is equal to the configured loopback carrier channel ID. Furthermore, while the loopback carrier channel bitrate is predefined, the incoming loopback traffic bitrate is not predefined and may rise to the maximum bitrate allowed by the hardware, which may result in a memory overflow. In the event of a memory overflow, loopback packets may be discarded.
[0049] While exemplary embodiments have been specifically illustrated and described, it will be understood by those skilled in the art that various modifications can be made in form and detail without departing from the scope of embodiments included in the appended claims.
Claims
1. Multiple input queues configured to receive data packets, each received data packet containing multiple data chunks, and these multiple data chunks for each data packet, when received as a whole, define a completed data packet; An output buffer configured to maintain a list containing each entry of a completed data packet received in each of the plurality of input queues; and Based on the entries in the list of output buffers, control logic is configured to read the completed data packets received in at least one of the plurality of input queues. A system for aggregating output content in a multi-queuing system, equipped with the necessary features.
2. The system according to claim 1, wherein each entry of a completed data packet listed in the output buffer includes at least one of the following: an indication of the location of the respective entry in the output buffer, an indication of the source, and the length of the respective completed data packet.
3. The system according to claim 2, wherein the system is further configured to determine the length of each completed data packet, by determining the total number of chunks in each data packet based on at least one of the first chunk among the plurality of data chunks and the final chunk among the plurality of data chunks.
4. The system according to claim 2, wherein the indication of the position in the output buffer is based on the time at which each of the plurality of input queues received the final chunk of the plurality of data chunks for its respective data packet.
5. The system according to claim 1, wherein the output buffer is further configured to provide information about the data packet to the control logic.
6. The system according to claim 1, further comprising the configuration that, in response to the output buffer containing at least one entry of a completed data packet, the control logic reads the completed data packet corresponding to each entry from at least one of the plurality of input queues and transmits the read completed data packet to at least one output queue.
7. The system according to claim 6, wherein, in response to the read completed data packet being sent as a whole to the at least one output queue, the system is further configured to delete the respective entries in the output buffer.
8. The system according to claim 1, wherein the final chunk of the plurality of data chunks of a given received data packet includes an instruction that the data packet was received as a whole.
9. The system according to claim 1, further comprising a memory configured to hold completed data packets received in the plurality of input queues.
10. The plurality of input queues are a first set of input queues corresponding to a first type of data channel, the output buffer is a first output buffer corresponding to the first type of channel, the control logic is a first control logic corresponding to the first type of channel, and the system is: A second set of multiple input queues corresponding to a second type channel, a second output buffer corresponding to the second type channel, and a second control logic corresponding to the second type channel. The system according to claim 1, further comprising:
11. The system according to claim 10, further comprising: an output controller coupled to the first control logic and also coupled to the second control logic, the output controller configured to orchestrate the transmission of data from the first control logic and the second control logic to an output queue, respectively.
12. At the stage of receiving each data packet in each of the multiple input queues, each received data packet contains multiple data chunks, and these multiple data chunks for each data packet, when received as a whole, define a completed data packet; A step in which the output buffer maintains a list containing entries for each of the completed data packets received in each of the plurality of input queues; and In the control logic, a step of reading the completed data packet received in at least one of the plurality of input queues based on the entries in the list of output buffers. A method for aggregating output content, which includes the following features.
13. The method according to claim 12, wherein each entry of a completed data packet listed in the output buffer includes at least one of the following: an indication of the location of the respective entry in the output buffer, an indication of the source, and the length of the respective completed data packet.
14. The method according to claim 13, further comprising the step of determining the length of each completed data packet by determining the total number of chunks in each data packet based on the first chunk of the plurality of data chunks and the last chunk of the plurality of data chunks.
15. The method according to claim 13, wherein the indication of the position in the output buffer is based on the time at which each of the plurality of input queues received the last chunk of the plurality of data chunks for its respective data packet.
16. The method according to claim 12, further comprising the step of providing information about the data packet to the control logic via the output buffer.
17. The method according to claim 12, wherein, in response that the output buffer contains at least one entry of a completed data packet, the method further comprises the step of the control logic reading the completed data packet corresponding to the respective entry from at least one of the plurality of input queues and transmitting the completed data packet to at least one output queue.
18. The method according to claim 17, further comprising the step of deleting the respective entries in the output buffer in response that the completed data packet has been sent as a whole to the at least one output queue.
19. The method according to claim 12, wherein the final chunk of the plurality of data chunks of a given received data packet includes an indication that the data packet was received as a whole.
20. The method according to claim 12, further comprising a memory configured to hold completed data packets received in the plurality of input queues.
21. The plurality of input queues is a first set of input queues corresponding to a first type of data channel, the output buffer is a first output buffer corresponding to the first type of channel, the control logic is a first control logic corresponding to the first type of channel, and the method is: The steps include: configuring a second set of multiple input queues corresponding to a second type channel; configuring a second output buffer corresponding to the second type channel; and configuring a second control logic corresponding to the second type channel. The method according to claim 12, further comprising:
22. The method according to claim 21, further comprising the step of automating the transmission of data from the first control logic and the second control logic to an output queue by an output controller coupled to the first control logic and the second control logic, respectively.
23. Means for receiving each data packet in each of a plurality of input queues, each received data packet containing multiple data chunks, and the multiple data chunks for each data packet, when received as a whole, define a completed data packet; Means for maintaining in the output buffer a list containing entries for each of the completed data packets received in each of the plurality of input queues; and In the control logic, means for reading the completed data packet from at least one of the received input queues based on the entries in the list of output buffers. A means for aggregating output content in a multi-queuing system, comprising the above.