Multi-traffic class tracker arbitration with focus and prioritized release

Abstract

A direct memory access (DMA) engine receives instructions corresponding to a message packet and indicative of a traffic class identifier (ID). The engine stores an entry of the instructions in a tracker, a respective tracker entry including the traffic class ID and an indicator of whether the respective entry requires processing, whether transfer of a DMA payload is complete, and whether the DMA payload is being actively transferred. The engine arbitrates between entries by determining a current mask indicating entries currently excluded from selection, updating the current mask in response to detecting a remaining tracker entry requiring processing, having sufficient available output queue credit for the traffic class ID, and not currently being masked, and identifying a winning tracker entry based on the current mask and the indicators of the entries. In response to a priority being satisfied, the system forwards information associated with the winning tracker entry.

Description

Background Technology Technical Field

[0001] A network interface card (NIC) may include a direct memory access (DMA) engine, which can include a multi-entry tracker to manage parallel processing of enhanced DMA operations, such as "scatter / collect" operations. The DMA engine processes instructions by creating tracker entries, and each instruction can be associated with a traffic class. A tracker arbitrator can arbitrate between tracker entries based on two objectives: traffic class independence, where each traffic class has a guaranteed minimum throughput independent of other traffic classes; and balanced priority within each traffic class, where a traffic class with more tracker entries can receive higher priority than a traffic class with fewer tracker entries. One current arbitration scheme is a two-level scheme that first arbitrates between entries within each traffic class, and then arbitrates between traffic classes. While this scheme satisfies traffic class independence, it does not always achieve balanced priority. Another arbitration scheme is the flat round-robin scheme, which achieves balanced priority but does not guarantee traffic class independence. Attached Figure Description

[0002] Figure 1A A schematic diagram of an architecture for facilitating arbitration of multi-flow category trackers with focused and prioritized releases, according to one aspect of this application, is shown.

[0003] Figure 1B An aspect of this application is shown. Figure 1A An enlarged view of a portion of the architecture.

[0004] Figure 2 A schematic diagram of a tracker bid mask unit according to one aspect of this application is depicted, including updating the progressive mask and generating a masked bid vector.

[0005] Figure 3A A flowchart is presented, illustrating a method for facilitating arbitration of multi-traffic category trackers with focused and prioritized deallocation, according to one aspect of this application.

[0006] Figure 3B The flowchart illustrates a method for facilitating the selection of a winning tracker entry through arbitration among tracker entries.

[0007] Figure 4A A flowchart illustrating a method for facilitating the updating of a progressive mask and generating a mask bid vector according to one aspect of this application is presented.

[0008] Figure 4BA flowchart illustrating a method for facilitating the updating of a progressive mask and generating a mask bid vector according to one aspect of this application is presented.

[0009] Figure 5 A computer system for facilitating arbitration of multi-flow category trackers with focused and prioritized releases, according to one aspect of this application, is shown.

[0010] Figure 6 A computer-readable medium is shown that facilitates arbitration of multi-flow category trackers with focused and prioritized releases according to one aspect of this application.

[0011] In the diagram, the same reference numerals refer to the same graphic elements. Detailed Implementation

[0012] The following description is provided to enable those skilled in the art to make and use these aspects and examples, and is provided in the context of a particular application and its requirements. Various modifications to the disclosed aspects will be apparent to those skilled in the art, and the general principles defined herein can be applied to other aspects and applications without departing from the spirit and scope of this disclosure. Therefore, the aspects described herein are not limited to those shown, but should be given the widest scope consistent with the principles and features disclosed herein.

[0013] The aforementioned aspect provides a hybrid arbitration scheme for selecting tracker entries processed in the DMA engine. This hybrid scheme enables traffic class independence and balanced priority.

[0014] The DMA engine in the NIC can be used to accelerate the transfer of “message” payloads to and from host memory. For example, it can generate a series of basic DMA instructions that describe individual reads from or writes to host memory. A “message” can be a piece of information transmitted over the network as one or more packets (e.g., an Ethernet frame using Transmission Control Protocol / Internet Protocol (TCP / IP) packets, a proprietary transport packet, etc.).

[0015] A DMA engine can include a multi-entry tracker (e.g., a 256-entry tracker) to manage parallel processing of enhanced DMA operations. The DMA engine processes DMA instructions by creating tracker entries, and each instruction can be associated with a traffic class. A tracker arbitrator can arbitrate between tracker entries based on two objectives: traffic class independence, where each traffic class has a guaranteed minimum throughput independent of other traffic classes; and balanced priority within each traffic class, where traffic classes with more tracker entries can receive higher priority than those with fewer tracker entries. One current arbitration scheme is a two-level scheme that first arbitrates between tracker entries within each traffic class, and then arbitrates between traffic classes. While this scheme satisfies traffic class independence, it does not achieve balanced priority. Another arbitration scheme is a flat round-robin scheme, which achieves balanced priority but does not guarantee traffic class independence.

[0016] The described aspect provides a hybrid arbitration scheme that achieves traffic class independence and balanced priority by using a tracker and a tracker arbitrator in the DMA engine processing incoming instructions. Large messages can be transmitted over the network as a series of packets, each corresponding to and requiring its own high-level DMA operation. Each packet of the message may correspond to an input DMA instruction that the DMA engine can accept, and each input DMA instruction may require multiple rounds of processing by the DMA engine. A round of processing typically involves issuing output instructions that define the low-level DMA operation to be performed. A round of processing may include one or more of the following: issuing a read to obtain an input / output vector (IOVEC) entry or to start a context from host memory; issuing a read or write of the DMA payload; transferring the final context of the DMA operation to a tracker entry that processes subsequent operations on the same message; storing the final context in a cache for final disposal; and degrading the context from a hot context cache to a cold context cache or evicting the context (e.g., releasing associated resources).

[0017] Each DMA instruction can carry a traffic category code (e.g., a traffic category identifier (ID)), and each traffic category can have a dedicated output queue and associated output queue credits. An output instruction belonging to a specific traffic category can only be placed into the corresponding output queue for that specific traffic category if the output queue has sufficient available output queue credits. The tracker in the DMA engine can assign a tracker entry for each incoming DMA instruction, and the tracker arbitrator can select the winning tracker entry by arbitrating among the tracker entries based on the operations described herein. As combined below... Figure 1AAs described above, a tracker can feed a single processing pipeline. Therefore, arbitration by the arbitrator between tracker entries can provide time-slice access to multiple traffic categories of the processing pipeline.

[0018] In addition to the traffic category ID, each DMA instruction can also carry a message identifier (“Message ID” or “MsgID”), which associates instructions within the same overall message. Based on the MsgID, the tracker can create a linked list managing tracker entries for instructions with the same message, allowing instructions to be processed sequentially. The DMA engine can use the MsgID (and packet offset) to transfer context from one instruction to the next within the same message. In some cases, the DMA engine can cache the context before the next instruction arrives to request it. When a message is complete (evaluated and determined at a higher level by components outside the DMA engine), the DMA engine can receive a “Deallocate_MsgID” command, which can carry the MsgID of the completed message.

[0019] Upon receiving a Deallocate_MsgID command, the DMA engine can perform operations to ensure that the MsgID can be reused. For example, for a given MsgID contained in the Deallocate_MsgID command, any active tracker entry containing that given MsgID must complete processing and enter idle mode. Since the message is determined to be complete, it can be assumed that such a tracker entry has completed the payload transfer process. However, while the tracker entry may have completed the payload transfer process, it may still be actively processing the prefetching of IVOEC entries. This process may reside internally within the DMA engine and is therefore not visible to components outside the DMA engine. When a tracker entry in the "external operation complete but internal operation pending" state receives a Deallocate_MsgID command, the DMA engine can mark the tracker entry with a status bit indicating that the given MsgID has been released. Setting this status bit allows the DMA engine to complete its internal operations (e.g., collecting remaining IVOEC entry fetches) but avoids performing any other operations (e.g., caching context).

[0020] In addition to marking the status bit of the "Internal Operation Pending" tracker entry when the Deallocate_MsgID command is received, the DMA engine can also release resources associated with a given MsgID, for example, by removing or evicting any context associated with a given MsgID from the cold context cache and releasing other resources associated with that MsgID.

[0021] The tracker arbitrator can generate a qualified bit vector based on various inputs, including whether a tracker entry has not yet started or has completed a DMA payload transfer (handled by the general tracker arbitration mask unit), and whether a tracker entry is actively transferring a DMA payload (handled by the "soft priority" tracker arbitration mask unit), as described below. Figure 1B and Figure 2 The arbitrator can select the winning tracker entry by maintaining a current "progressive" mask, which represents the entries currently excluded from the winning list. The arbitrator can also progressively update the current mask in a hybrid manner, combining polling-like techniques with additional logic based on traffic categories to ensure traffic category independence. For example, if no tracker entries need to be processed in a given traffic category, and there are no unmasked tracker entries in a given tracker class, the arbitrator can clear the bits in the progressive mask corresponding to the tracker entries for that given tracker category, as described below. Figure 2 , 4A As stated in 4B.

[0022] The tracker arbiter can also apply a priority order to tracker entries, where: tracker entries that have completed DMA payload transfer have the highest priority to be processed using the final context, which consists of (forwarding, cold buffering, or eviction); the Deallocate_MsgID command has the second highest processing priority; and all other tracker entries have the lowest processing priority.

[0023] For example, if applicable, the tracker arbitrator can select (e.g., process and forward) tracker entries that have completed DMA payload transfer and prefetching of all IOWEC entries (referred to as tracker entries in the "BIDC" state) with the highest priority. For a tracker entry in the BIDC state, all processing associated with that tracker entry has occurred, placing the tracker entry in the BIDC state. Tracker entries in the BIDC state may leave behind residual final context, which must be processed, for example, by: transferring the final context to a subsequent instruction of the same message; storing it in a cold context buffer; or evicting it from a hot or cold context buffer via a processing pipeline, as in the following combination. Figure 1A As described above, when the tracker arbitrator selects a tracker entry in the BIDC state as the winning tracker entry and processes the remaining context, the tracker can place that tracker entry into an idle state, making it available for reallocation.

[0024] The tracker arbitrator can apply the next level of priority to process the Deallocate_MsgID command. The DMA engine can receive the Deallocate_MsgID command, which can be queued in the Deallocate_MsgID queue. After winning the arbitration, the command can be piped through the engine and attempts to flush the context from the context cache. However, some tracker entries associated with that MsgID may be in the BIDC state and are still waiting to send their final context or store it in the context cache for final disposal. If the Deallocate_MsgID command is processed before the BIDC tracker entry stores its final context in the cache (i.e., if the BIDC tracker entry wins the arbitration after the Deallocate_MsgID command or at a lower priority than the Deallocate_MsgID command), then the BIDC tracker entry can store more context in the cold cache associated with the MsgID processed in the Deallocate_MsgID command. This could lead to the unnecessary storage of the final context of the BIDC tracker entry without any subsequent expectation or possibility of deleting that context based on the corresponding and processed Deallocate_MsgID command.

[0025] The arbiter addresses potential inefficiencies in selecting inputs for processing by prioritizing BIDC tracker entries above the Deallocate_MsgID command. Furthermore, the arbiter can place the Deallocate_MsgID command with a higher priority than all other tracker entries. Enforcing this priority will be described below in conjunction with the multiplexer and NOR component in Figure 1.

[0026] Therefore, the described aspects can support multiple rounds of processing per DMA instruction to achieve the first goal of traffic class independence by progressively updating the mask in a polling-like manner that also takes into account traffic class, as combined below. Figure 2The described aspects can also achieve the second objective of balanced priority by providing the highest level of priority to tracker entries that have completed DMA payload transfers (e.g., in BIDC state), a second level of priority to Deallocate_MsgID commands, and a third level of priority to all other entries, including providing “soft priority” (as described herein) to tracker entries that are actively transferring DMA. The first and second levels of priority are absolute, meaning that: 1) if any tracker entry is in BIDC state, no other tracker entry or Deallocate_MsgID command can win arbitration; and 2) if no tracker entry is in BIDC state and Deallocate_MsgID commands are queued, then Deallocate_MsgID commands will win arbitration. The third level of priority can include “soft priority”: if no tracker entry is in BIDC state and no Deallocate_MsgID commands are queued, all tracker entries that need to be processed are eligible to win arbitration, but tracker entries marked as “soft priority” (i.e., tracker entries actively transferring DMA payloads) will win arbitration more frequently than other entries.

[0027] Figure 1A Figure 100 illustrates an architecture according to one aspect of this application that facilitates arbitration of multi-flow category trackers with focus and prioritized release. Figure 100 depicts a DMA engine 100 (also referred to as the "engine") and includes various components external to the engine. The engine 100 may be part of circuitry or logic within a NIC capable of performing the operations described herein. Engine 100 may include: a tracker 102 that maintains a data structure of, for example, 256 entries; a tracker arbitrator 120 that handles the scheduling of tracker entries to process incoming instructions to the engine; a DMA engine pipeline 108 (also referred to as the "engine pipeline") that collects information from various units or components inside and outside the engine; an IVOEC / context fast-forward ("context FF") buffer 104 (ICB) that stores data retrieved from host memory; a descriptor / bytemask table 112 that has entries defining scatter / aggregate operations, including non-bytemask descriptor memory and bytemask descriptor memory; a hot / cold context cache 114 that caches contexts based on associated access or storage times; a data type processor (DTP) 110 that receives input (e.g., from engine pipeline 108) and sends outputs indicating, for example, DMA instructions; an eviction queue 116 that stores contexts from the hot / cold context cache 114 that will be processed as part of evictions from the cache; and a queue arbitrator 106 that handles scheduling to process from the DTP. The data output from queues 110 and 116 is processed.

[0028] During operation, engine 100 may receive instructions 150, which may include information defining high-level scatter / aggregate operations, such as: base host memory address; total payload length; and references to entries in descriptor table 112. For each input instruction, engine 100 may ultimately produce multiple instruction outputs, each describing a single DMA read or write. Engine 100 may also produce DMA read instructions to retrieve data from host memory on its own behalf, for example, to retrieve data to be stored in ICB 104.

[0029] Upon receiving instruction 150, tracker 102 can assign tracker entries and store the information from the instruction along with the initial high-level processing state in the tracker entries. Tracker 102 can track the received instructions, and each entry of the tracker (e.g., each of 256 entries) can manage the overall scatter / aggregate operation corresponding to the instruction. Tracker arbitrator 120 can schedule instructions for processing by performing various operations based on inputs from tracker 102 (e.g., inputs 151, 152, 153, and 154 described below), credit-based flow control associated with the output queues of each traffic category of the engine (e.g., input 161), and commands to release resources associated with message IDs (e.g., outputs 159 and 160). Based on these inputs, tracker arbitrator 120 can arbitrate among tracker entries to select a winning tracker entry to process and can output information associated with the winning tracker entry (via communication 178). The operation of tracker arbitrator 120 can allow engine 100 to manage many concurrent collection / scatter operations in a time-sliced ​​manner. The following combines... Figure 1B Describe the details of tracker arbitrator 120.

[0030] A round of processing can begin with the selection of a tracker entry (i.e., winning the arbitration). Engine pipeline 108 can obtain the winning tracker entry number and lookup instructions (via communication 178) from the corresponding tracker entry. Engine pipeline can also collect information from other components in engine 100. For example, based on the descriptor reference provided in the instructions, engine pipeline 108 can obtain the descriptor from descriptor table 112 (via communication 180). Based on the tracker entry number or MsgID value, engine pipeline can obtain the current context (if available) from hot / cold context cache 114 (via communication 181). Based on the information in the context, engine pipeline can obtain data (e.g., IOWEC entry or context FF data) from ICB 104 (via communication 182) (if available).

[0031] Engine pipeline 108 may include multiple pipeline queues for accumulating collected information. A tracker entry cannot win arbitration unless there is sufficient available space in these pipeline queues. Engine pipeline 108 may send pipeline queue credits (via communication 179) as input to tracker arbitrator 120 (as combined below). Figure 1B (The use of the term).

[0032] Engine pipeline 108 can send collected information as input to DTP 110 (e.g., via communications 183, 184, and 185). DTP 110 can process the information received in one or more cycles and can generate and send as output: tracker status updates to tracker 112 (via communication 188, e.g., entry_update 188); information to be sent to ICB 104 via queue arbitrator 106 (via communication 189); sending new (hot) contexts to hot / cold context cache 114 (via communication 191); and DMA read / write instructions processed and transferred by components outside engine 100 (via communication 190). Cache 114 can send data to be evicted from its storage to evict queue 116 (via communication 187), and evict queue 116 can store contexts to be processed for eviction and send them to queue arbitrator 106 (via communication 192). Queue arbiter 106 can handle scheduling to process data output from DTP 110 (received via communication 189) and expulsion queue 116 (received via communication 192). Based on this scheduling, queue arbiter 106 can send commands (via communication 193) to store information in ICB 104 or to delete information from ICB 104.

[0033] Table 1 below provides a description of the variables used in the operation of the tracker arbiter 120, including the inputs, outputs, and intermediate values ​​used within the tracker arbiter 120:

[0034]

[0035]

[0036] Table 1

[0037] Figure 1AEngine 100 in the image depicts a tracker arbitrator 120 at a high level. Tracker arbitrator 120 may include multiple components, including at least: a general tracker arbitrator mask (“Trk_Arb_Msk”) 126; a soft-priority tracker arbitrator mask (“Trk_Arb_Msk”) 130; and a multiplexer (“mux”) 142. As described above, tracker arbitrator 120 may receive at least six inputs: a bid_tc vector 151; a bid_ld vector 152; a BIDC vector 153; an apri vector 154; a tr_cr_avail value (representing the output queue credit for each traffic class (TC)) 161; and a command 159 or information 160 associated with a command to release resources associated with a message ID. Some of these inputs may be combined with other information ( Figure 1A Not shown in the image; as shown below regarding Figure 1B The above) are processed together to obtain the inputs of the general Trk_Arb_Msk 126 and the soft-priority Trk_Arb_Msk 130. For example, the general Trk_Arb_Msk 126 can take bid_tc 151, bid 165, bid_vld 152, bidc 153 and tr_cr_avait as inputs and can generate or output bidm 168, which is a version of a partially masked bid vector (as combined below). Figure 2 Similarly, the soft-priority Trk_Arb_Msk130 can take bid_tc 151, bidp 166, bid_vldp 167, bidc 153, and tr_cr_avait as input, and can generate or output bidmp 169, which is a version of a partially masked bidp vector (as described below). Figure 2 The above).

[0038] Multiplexer 142 can receive selected tracker entry 171 as input based on the operations performed on vectors bidm 168 and bidmp 169 (as described below). Figure 1BThe multiplexer 142 can also receive input information associated with a command to release resources associated with a message ID (represented as Deallocate_MsgID information 159 / 160, e.g., an indicator 160 indicating whether the command 159 or Deallocate_MsgID queue 118 is empty). The multiplexer 142 can select inputs based on predetermined priorities, e.g., tracker entries that have completed DMA payload transfers have the highest priority to be processed and forwarded; Deallocate_MsgID commands have the second highest priority to be processed; and all other tracker entries have the lowest priority to be processed and forwarded. This will be discussed in conjunction with... Figure 1B The selection of inputs by the multiplexer 142 is further described.

[0039] Figure 1B An aspect of this application is shown. Figure 1A Figure 101 provides a detailed representation of a portion of the architecture. Figure 101 depicts tracker 102, tracker arbitrator 120, and Deallocate_MsgID queue 118. Tracker arbitrator 120 can receive input from tracker 102, including: bid_tc vector 151; bid_ld vector 152; bidc vector 153; apri vector 154; entry_alloc 155; and the result 157 of entry_lockup request 156. The flow of bid_tc vector 151 can be represented by a bold dashed pattern; the flow of bid_vld vector 152 can be represented by a bold dashed pattern; the flow of bidc vector 153 can be represented by a bold solid line pattern; and the flow of apri vector 154 (and other flows) can be represented by a non-bold solid line pattern.

[0040] In addition, the tracker arbitrator 120 can receive from components outside the engine: tr_cr_avail value (indicating the output queue credit for each traffic category) 161; pipeline queue credit 179; and Deallocate_MsgID command 159 or indicator 160 indicating whether the Deallocate_MsgID queue 118 is empty.

[0041] The tracker arbiter 120 can generate several qualified bit vectors. The Rdy_Gen block 122 can take the following as input: tr_cr_avail 161 (representing the output queue credit for each traffic category); miq_empty 160 (indicating whether the Deallocate_MsgID queue is empty); pipeline queue credit 179; bid_tc 151; and bidc 153. Based on these inputs, the Rdy_Gen block 122 can generate a bid_Rdy vector 162, which indicates the tracker entry that can be processed when all its necessary resources are available (including the output queue credit 161 and pipeline queue credit 179). If any bidc 153 bit is set, bid_rdy simply indicates that the tracker entry is ready in the BIDC state. Otherwise, if the Deallocate_MsgID queue 118 is not empty (e.g., miq_empty represents a value of 1), bid_rdy can be set to zero, which enforces the priority described herein.

[0042] AND block 124 can generate bid vector 165 based on the AND of bid_rdy 162 and bid_ld 152, where bid 165 indicates a tracker entry that needs to be processed and has the resources required for processing. AND block 128 can generate bidp vector 166 based on the AND of bid 165 and apri 154, where bidp 165 represents a soft-priority version of a tracker entry that needs to be processed, has the resources required for processing, and is actively transferring a DMA payload. AND block 134 can generate bid_vldp vector 167 based on the AND of bid_vld 152 and apri 154, where bid_vldp vector 167 indicates a tracker entry that is ready to be processed and is actively processing a DMA payload. Based on bidc vector 153, unary OR (“uOR”) block 132 can generate the indicator any_bidc 163, indicating whether any tracker entry is in the BIDC state.

[0043] Subsequently, two versions of Trk_Arb_Msk can be used to generate masked bid vectors for identifying winning tracker entries. The generic Trk_Arb_Msk 126 can take bid_tc 151, bid 165, bid_vld 152, bidc 153, and tr_cr_avail 161 as input and can generate or output a bidm vector 168, which is a version of the partially masked bid vector (e.g., bid 165) (as combined below). Figure 2Similarly, the soft-priority Trk_Arb_Msk 130 can take bid_tc 151, bidp 166, bid_vldp 167, bidc 153, and tr_cr_avail 161 as input and can generate or output bitmp 169, which is a version of the partially masked bidp vector (e.g., bidp 166) (as combined below). Figure 2 The above).

[0044] The 50 / 50 arbitrator 138 can take bidm 168 and bidmp 169 as inputs and select one of the vectors based on a simple 50 / 50 arbitration scheme. For example, the 50 / 50 arbitrator 138 can choose between two bit-per-tracker-entry vectors so that the result can be fed into a priority multiplexer circuit that can perform priority encoding and tracker entry lookup in parallel. The resulting vector selected by the 50 / 50 arbitrator 138 can be referred to as bidmm 170. The Find_First block 140 can perform priority encoding on the bidmm vector 170 so that the lowest-numbered tracker entry is identified as the currently winning tracker entry. In some respects, the Find_First block 140 can perform separate priority encoding on each of bidm 168 and bidmp 169 to obtain two Find_First results, and the 50 / 50 arbitrator 138 can choose between these two Find_First results.

[0045] Find_First block 140 can send the number of the winning tracker entry to multiplexer 142 (via communication 171). Find_First block 140 can also send an entry_lokup request 156 to tracker 102, and the corresponding entry_lookup 157 (e.g., a lookup instruction from tracker 102) can be returned as input to multiplexer 142 (via communication 157). Find_First block 140 can also send other information (via communication 173) to update mask (“Upd_mask”) block 136.

[0046] In addition to receiving other information from Find_First block 140 via communication 173, Upd_Mask block 136 can also take bid_vldp 167 and entry_alloc 155 as input. Upd_Mask block 136 can send information related to updating the current mask to soft priority Trk_Arb_Msk 130 (such as Upd_*175). The value of upd_* can represent: whether the mask needs to be updated; the winning tracker entry in the current period; the traffic class ID of the winning tracker entry; and the status of the winning tracker entry (as combined below). Figure 2 (as described above). Furthermore, Upd_Mask block 136 can send a signal (e.g., "clr" signal 177) to soft-priority Trk_Arb_Msk 130 to clear the entire updated mask. The "clr" input (176) of general Trk_Arb_Msk 126 is unused and bound to "0".

[0047] The NOT OR (“NOR”) 144 block can take any_bidc 163 and the indicator miq_empty 160 as inputs. NOR 144 determines whether no tracker entry is in the BIDC state and whether miq_empty indicates that the Deallocate_MsgID queue 118 is not empty. If true, the result is sent to multiplexer 142 (via communication 172) and instructs multiplexer 141 to process the Deallocate_MsgID command 159. The logic of NOR 144 provides an example of implementing and enforcing the priorities of BIDC tracker entries, the Deallocate_MsgID command, and other tracker entries. That is, based on NOR 144, multiplexer 142 can select inputs based on predetermined priorities, for example: tracker entries that have completed DMA payload transfers have the highest priority to be processed and forwarded; the Deallocate_MsgID command has the second highest priority to be processed; and all other tracker entries have the lowest priority to be processed and forwarded.

[0048] Finally, after multiplexer 142 performs its selection, multiplexer 142 can provide final output 178 from tracker arbitrator 120. Final output 178 may include the winning tracker entry number and a lookup instruction corresponding to the winning tracker entry.

[0049] Figure 2 Figure 200 depicts a tracker bid mask unit (i.e., Trk_Arb_Msk) according to one aspect of this application, including updating the step mask and generating a mask bid vector.

[0050] Table 2 below provides a description of the variables used in the general Trk_Arb_Msk 126 and soft-priority Trk_Arb_Msk 130 operations, including inputs, outputs, and intermediate values:

[0051]

[0052] Table 2

[0053] The tracker bid mask unit depicted in Figure 200 can represent two instances: the general-purpose Trk_Arb_Msk 126 and the soft-priority Trk_Arb_Msk 130. The difference lies in the use of the bid and bid_vld inputs, as described below. The tracker bid mask unit can receive the following input: tr_cr_avail 260 (similar to...) Figure 1A and 1B tr_cr_vail161); bid_vld 262 (depending on the Trk_Arb_Msk instance, it can be bid_fld or bid_vldp, for example, similar to Figure 1A and 1B (bid_vld 152 and bid_vldp167); bid_tc 264 (similar to...) Figure 1A and 1B (bid_tc151); bid 290 (depending on the Trk_Arb_Msk instance, can be bid or bidp, e.g., similar to...) Figure 1A and 1B (bid 165 and bidp166); and bidc 292 (similar to...) Figure 1A and 1B (bidc 153). Furthermore, the tracker bid mask unit can receive several upd_* values ​​as input, including: upd_vld 280; upd_idx 282; upd_tc 284; and upd_stt 286 (similar to...). Figure 1B The upd_* values ​​are 174 and 175. The tracker bid mask unit can also receive the clr_msk 288 signal as input to clear the entire updated mask (similar to...). Figure 1B The “clr” signal 176 received as input to the general Trk_Arb_msk 126 and the “clr” signal 177 received as input to the soft priority Trk_Arb_msk 130.

[0054] The tracker bid masking unit can first determine the unmasked bid with available output queue credits based on the inputs tr_cr_avail 260, bid_vld 262, and the current mask mskn_q 272 (as shown by the pseudocode (PC) 212 in element 210). The result of PC 212 can be the bit vector bidvca 266, which indicates the qualified tracker entries that need to be processed, have sufficient available output queue credits, and are currently not masked. PC 212 is represented as follows:

[0055]

[0056] The tracker bid mask unit can also determine the valid bid vector for each traffic category based on the inputs bid_vld 262 and bid_tc 264 (as shown by PC 222 in element 220). The result of PC 222 can be a two-dimensional array bidvptc 268 of traffic category-specific vectors, where the corresponding traffic category-specific vectors indicate the tracker entries to be processed for the corresponding traffic category. PC 222 is represented as follows:

[0057]

[0058] Next, the tracker bid mask unit can determine the updated mask (i.e., the updated stepwise mask) based on the inputs bidvca 266, bidvptc 268, bid_vld 262, bid_tc 264, the current mask mskn_q 272, upd_* values ​​280-286, and clr_msk signal 288 (as shown by pseudocodes 232, 234, 236, and 238 in element 230). PC 232-238 are represented as follows:

[0059]

[0060] The tracker bid mask unit can set the updated mask mskn_q as the current mask mskn (if any) (as shown in pseudocode 232). In response to determining that a condition is met (as shown in pseudocode 234), the tracker bid mask unit can update the mask in the corresponding period for the corresponding bit of the mask. This condition may include: determining that the current mask needs to be updated based on the selected winning tracker entry; determining that the transfer of the DMA payload associated with the winning tracker entry is incomplete; determining that the position of the corresponding bit in the mask is less than or equal to the position or number associated with the winning tracker entry; and determining that the position of the corresponding bit in the mask corresponding to the tracker entry indicates a traffic category ID that is the same as the traffic category ID of the winning tracker entry, and that the position of the corresponding bit in the mask corresponds to at least one of the tracker entries that do not currently need to be processed.

[0061] The tracker bid masking unit can then determine whether any or all bits of the mask should be cleared. If there are no tracker entries that need to be processed and are not masked in the corresponding traffic category, the tracker bid masking unit can partially clear the mask by clearing any bits corresponding to the tracker entry associated with the corresponding traffic category (as shown in pseudocode 236). In some aspects, if the tracker bid masking unit receives a command or signal to clear the entire mask, the tracker bid masking unit can clear the entire mask (as shown in pseudocode 238).

[0062] The tracker bid mask unit can store the updated mask mskn 270 in the step mask register 240, where mskn 27 can be used as the current mask mskn_q 272 in the next cycle.

[0063] Subsequently, the tracker bid mask unit can generate a mask bid vector based on the input bid 290, bidc 292, and the current mask mskn_q272 (as shown by PC 252 in element 250). PC 252 is represented as follows:

[0064]

[0065] The result of PC 252 can be a bidm vector 294, which indicates the tracker entry that needs to be processed and can be processed, and is either (i) currently not masked; or (ii) in a BIDC state. Depending on the Trk_Arb_Msk instance, the resulting bidm vector 294 can be either bidm or bidmp (e.g., similar to...). Figure 1A and 1B (bidm168 and bidmp169). The bidm vector 294 can be sent as input to the 50 / 50 arbitrator 138 and received by it for further processing, as mentioned above. Figure 1B As stated above.

[0066] Figure 3A A flowchart 300 according to one aspect of this application is shown, illustrating a method for facilitating arbitration of multi-traffic category trackers with focused and prioritized releases. During operation, the system receives instructions (operation 302) corresponding to message packets and indicating traffic category identifiers (IDs) via a direct memory access (DMA) engine. For example, engine 100 may receive instruction 150, which corresponds to a message packet and indicates a traffic category ID, as described above regarding... Figure 1A and 1B As stated above.

[0067] The system stores instruction entries in a tracker data structure that includes entries corresponding to the instructions. Each entry includes the traffic category ID of the corresponding entry, whether the entry needs processing, whether the DMA payload transfer associated with the corresponding entry has been completed, and an indicator of whether the corresponding entry is actively transferring the DMA payload (operation 304). The tracker data structure can hold, for example, 256 entries. (See above regarding...) Figure 1A and 1B The bid_tc vector 151 may include a traffic category code (e.g., traffic category ID) for each entry. The bid_vld vector 152 may include one bit per entry indicating whether the corresponding tracker entry needs to be processed. The bidc vector 153 may include one bit per entry indicating whether the corresponding tracker entry is in a BIDC state (i.e., the transfer of the DMA payload associated with the corresponding entry is complete). The apri vector 154 may include one bit per entry indicating whether the corresponding tracker entry is actively transferring the DMA payload. Table 1 above provides a description of the variables used to describe system operation, including, for example, inputs, outputs, and intermediate values ​​used within the tracker arbitrator 120.

[0068] The system arbitrates among the entries by performing several operations (represented by element 306, which includes operations 308, 310, and 312), selecting the winning tracker entry from the entries. (The above is combined with...) Figure 1A , 1B Figures 2 and 2 provide a detailed description of the tracker arbiter 120 and tracker bid mask units (including the general Trk_Arb_Msk 126 and the soft priority Trk_Arb_Msk 130) depicted in Figure 200.

[0069] The system determines the current mask, which indicates the entries currently excluded from being selected as the winning tracker entry (operation 308). For example, based on... Figure 2 The pseudocode 232 of element 230 in the tracker bid mask unit can determine the current mask mskn_q 272 based on the progressively updated mask mskn 270.

[0070] In response to the detection of a first condition, the system periodically updates the current mask. The first condition includes the need for processing, sufficient available output queue credits with traffic category IDs, and the remaining tracker entries that are not currently masked (operation 310). For example, the tracker bid masking unit can detect this first condition using its various inputs (including bid_vld 262, bid_tc 264, current mask mskn_q 272, and upd_* values ​​280-286) (as shown by pseudocode 234 in element 230).

[0071] The system identifies the winning tracker entry based on the current mask and the entry's indicator (Operation 312). For example, as mentioned above... Figure 2 The tracker bid mask unit can generate a mask bid vector bidm 294 based on the current mask mskn_q 272 and the above input (i.e., the entry indicator).

[0072] In response to a predetermined priority being met, the system forwards information associated with the winning tracker entry (operation 314). The system can determine the winning tracker entry based on the operations of the 50 / 50 arbitrator 138 on the result vectors bidm 168 and bidmp 169 from the general Trk_Arb_Msk 126 and soft-priority Trk_Arb_Msk 130, respectively. (As described above...) Figure 1B The system can also determine the winning tracker entry based on the operation of Find_First block 140 and multiplexer 142. Multiplexer 142 can provide output 178 as the final output of tracker arbitrator 120, which includes the winning tracker entry number and a lookup instruction corresponding to the winning tracker entry (e.g., via...). Figure 1B (Communications 171 and 157). Furthermore, predetermined priorities can be executed based on the operation of NOR 144 and multiplexer 142 in response to input from Deallocate_MsgID queue 118, including Deallocate_MsgID command 159 and indicator 160 miq_empty, as described above regarding... Figure 1B The operation has returned.

[0073] Figure 3B A flowchart 320 is presented illustrating a method for facilitating the selection of a winning tracker entry by arbitrating among tracker entries according to one aspect of this application. The system can arbitrate among the entries by performing operations 322-330, and the system can identify the winning tracker entry by performing operations 332 and 334.

[0074] The system generates a first vector based on the tracker entries that need to be processed and are ready for processing (operation 322). For example, as mentioned above... Figure 1B The AND block 124 can generate a bid vector 165 (i.e., the “first vector”) based on the AND of bid_rdy 162 and bid_ld 152, where bid 165 represents a tracker entry that needs to be processed and has the resources required for processing.

[0075] The system generates a second vector (operation 324) based on tracker entries that need to be processed and are actively transferring DMA payloads. For example, AND block 134 can generate a bid_vldp vector 167 (i.e., the "second vector") based on the AND of bid_vld 152 and apri 154, where the bid_vldp vector 167 indicates tracker entries that are ready to be processed and are actively processing DMA payloads, as described above regarding... Figure 1B As stated above.

[0076] The system generates a third vector based on the first vector and the tracker entry that is actively transferring DMA payloads (operation 326). For example, as mentioned above... Figure 1B The AND block 128 can generate a bidp vector 166 (i.e., a “third vector”) based on the AND of bid 165 and apri 154, where bidp 165 represents a soft-priority version of a tracker entry that needs to be processed, has the resources required for processing, and is actively transferring a DMA payload.

[0077] The system generates a fourth vector based on the detection of the first condition (operation 328). For example, Figure 2 The pseudocode 212 of element 210 can produce bidvca 266 (i.e., the "fourth vector"), which indicates a qualified tracker entry that needs to be processed, has sufficient available output queue credits, and is currently not masked (i.e., the "first condition").

[0078] The system generates a set of fifth vectors based on the corresponding traffic category ID and the tracker entry that needs to be processed (Operation 330). For example, Figure 2 The pseudocode 222 of element 220 can produce bidvptc 268 (i.e., the "fifth vector set"), which can be a two-dimensional array of traffic category-specific vectors, where the corresponding traffic category-specific vectors indicate the tracker entries that need to be processed for the corresponding traffic category.

[0079] The system identifies the winning tracker entry by generating a sixth vector based on the current mask, a first vector (e.g., bid), a third vector (e.g., bidp), and whether the transfer of the DMA payload associated with the corresponding entry has been completed (operation 332). For example, as... Figure 2As shown in pseudocode 252 in element 250, the tracker bid masking unit can generate a mask bid vector based on the inputs bid 290, bidc 292, and the current mask mskn_q. The result of pseudocode 252 can be a bidm vector 294 (“sixth vector”), which indicates a tracker entry that needs to be processed and can be processed and satisfies either: (i) it is currently not masked; or (ii) it is in a BIDC state. That is, the generation of bidm can be based on the current mask mskn_q 272, bid 290 (which, depending on the instance of Trk_Arb_Msk, can be bid 165 as the “first vector” or bidp 166 as the “third vector”), and bidc 292 (i.e., whether the transfer of the DMA payload associated with the corresponding entry has been completed).

[0080] The system also identifies the winning tracker entry by recognizing the tracker entry with the lowest number in the sixth vector as the currently winning tracker entry (operation 334). For example, as mentioned above... Figure 1B As described above, after the 50 / 50 arbitrator 138 selects one of the generated mask bid vectors bidm 168 and bidmp 169 (the result of which is renamed bidmm 170), the Find_First block 140 can perform priority encoding to identify the lowest-numbered tracker entry as the currently winning tracker entry (i.e., the rightmost tracker entry in bidmm 170). The operation returns.

[0081] Figure 4A A flowchart 400 according to one aspect of this application is shown, illustrating a method for facilitating the updating of a progressive mask and generating a mask bid vector. The system generates a vector indicating tracker entries that need to be processed, have sufficient available output queue credits, and are currently not masked (operation 402). For example, as described above regarding... Figure 2 The pseudocode 212 in element 210 can generate a bidvca vector 266 based on inputs including tr_cr_avail 260 and bid_vld 262. This vector indicates tracker entries that need to be processed, have sufficient available output queue credits, and are not currently masked.

[0082] The system generates a two-dimensional array of traffic category-specific vectors, where each traffic category-specific vector indicates the tracker entry to be processed for that traffic category (operation 404). Pseudocode 222 in element 220 can generate a bidvptc vector 268 based on bid_vld262 and bid_tc 264. This vector is a two-dimensional array of valid bid vectors for each traffic category, as described above. Figure 2 As stated above.

[0083] The system sets the updated mask as the current mask (if any) (operation 406). For example, the updated mask mskn 270 can be updated incrementally and stored in the incremental mask register 240 to be used as the current mask mskn_q 272 for the next cycle, where the updated mask msbn is set to the value of the current mask msk_q, as shown in pseudocode 232 in element 230.

[0084] In response to determining that a condition is met, the system updates the mask for the corresponding bit within the corresponding period, wherein the condition includes: determining that the current mask needs to be updated based on the selected winning tracker entry; determining that the transfer of the DMA payload associated with the winning tracker entry is incomplete; determining that the position of the corresponding bit in the mask is less than or equal to the position or number associated with the winning tracker entry; and determining that at least one of the following is true: (i) the position of the corresponding bit in the mask corresponding to the tracker entry indicates a traffic category ID that is the same as the traffic category ID of the winning tracker entry, and (ii) the position of the corresponding bit in the mask corresponds to a tracker entry that does not currently need to be processed (operation 408). Determining that the condition is met may include using inputs bidvca 266, bid_vld 262, bidvptc 268, bid_tc 264, mskn_q 272 and upd_* values ​​280-286, such as Figure 2 As shown.

[0085] If the condition is met (decision 410), the system updates the mask in the corresponding period by setting the corresponding bits of the mask (operation 412) and determines whether there are any remaining bits in the mask to be processed (decision 414). For example, the system can "mask" the corresponding bit by setting the value of the corresponding bit to the value "1".

[0086] If the condition is not met (Decision 410), and if there are remaining bits in the mask to process (Decision 414), the operation returns to operation 408. If the condition is not met (Decision 410) and if there are no remaining bits in the mask to process (Decision 414), the operation proceeds to operation 408. Figure 4B Continue at label A.

[0087] Figure 4B A flowchart 420 according to one aspect of this application is shown, illustrating a method that facilitates updating a progressive mask and generating a mask bid vector. Although Figure 4B Decisions 422 and 430 are described in a specific order, but these decisions can also occur in the reverse order, for example, as follows: Figure 2 The pseudocodes 236 and 238 in element 230 are shown.

[0088] If the system receives a command to clear the entire mask (decision 422), the system clears the entire update mask (operation 424). For example, if Figure 2 If the Trk_Arb_Msk instance depicted receives the clr_Msk signal 288 indicating that the entire mask should be cleared, then the pseudocode 238 in element 230 can "clear" the mask by setting the value of each bit in the current mask mskn to zero.

[0089] The system stores the updated mask in the step mask register to be used as the current mask for the next cycle (operation 426), such as... Figure 2 The communication between the MSKN 270 and the step mask register 240 is shown. The step mask register 240 can store one or more versions of the step mask based on multiple processing cycles.

[0090] If the system does not receive a command to clear the entire mask (decision 422), and if there is no tracker entry in the corresponding traffic category that needs to be processed and is not masked (decision 430), the system partially clears the updated mask by clearing any bits corresponding to the tracker entry associated with the corresponding traffic category (operation 432). For example, the system can "clear" a bit by setting the corresponding bit to zero. Therefore, the system does not clear any bits corresponding to tracker entries in a given traffic category that still need to be processed or masked. Instead, the system iterates through the traffic categories indicated by bidvptc 268, and for a given traffic category, if there is no tracker entry in the given traffic category that needs to be processed and is not masked, it only clears the bits in the current mask corresponding to the given traffic category, as described above regarding... Figure 2 The pseudocode 236 in element 230 is described.

[0091] If any remaining traffic categories need to be processed (decision 434), the operation returns to decision 430. If no remaining traffic categories need to be processed (decision 434), the operation continues at operation 426 (i.e., the updated mask is stored in the step mask register).

[0092] If there are no tracker entries that need to be processed and are not masked in the corresponding traffic category (i.e., if there are tracker entries that need to be processed or are masked in the corresponding traffic category) (decision 430), the operation continues in operation 426 (i.e., the updated mask is stored in the step mask register).

[0093] Following operation 426, the system generates a mask bid vector based on the following: the current mask; whether the tracker entry is at least one of the following: needs to be processed, ready to be processed, or actively transferred DMA payload; and whether the transfer of the DMA payload for the corresponding entry has been completed (operation 428). For example, Figure 2The pseudocode 252 in element 250 can produce the masked bid vector bidm294 (depending on the instance of Trk_Arb_Msk, it can be bidm or bidmp).

[0094] The system performs a 50 / 50 arbitration (operation 440) on the mask bid vectors output from the general tracker bid mask unit and the soft priority tracker bid mask unit to select the mask bid vector to be processed. For example, the general Trk_Arb_Msk 126 can generate the bidm vector 168, and the soft priority Trk_Arb_Msk 130 can generate the bidmp vector 169. The 50 / 50 arbitrator 138 can perform a 50 / 50 arbitration on the two mask bid vectors by selecting either of the two mask bid vectors (i.e., bidm and bidmp) using a half-and-half ratio, for example, selecting bidm for half the time and bidmp for the other half. The resulting selected mask bid vector can be called bidmm (e.g., ...). Figure 1B (bidmm 170).

[0095] The system performs priority encoding on the selected mask bid vector (e.g., Find_First) to identify the tracker entry with the lowest number whose corresponding bit in the mask bid vector is "1" as the winning tracker entry (operation 442). For example, Find_First block 140 can identify the rightmost or lowest numbered tracker entry with a "1" in the corresponding bit of the mask bid vector as the winning tracker entry, thereby generating Figure 1B Inputs 171 and 157 of the multiplexer 142.

[0096] The system selects between the inputs of the multiplexer based on a predetermined priority (operation 444). For example, in Figure 1B In this context, multiplexer 142 can perform operations based on vectors bidm 168 and bidmp 169 (as described below). Figure 1B The selected tracker entry 171 is received as input via information associated with the winning or selected tracker entry through entry_lookup 156 / 157. The multiplexer 142 may also receive information associated with a command to release the resource associated with the MsgID as input (e.g., command 159 or indicator 160 indicating whether the Deallocate_MsgID queue 118 is empty). Based on the above... Figure 1BThe operation of NOR 144 and multiplexer 142 is described. Multiplexer 142 can select inputs based on predetermined priorities, for example: tracker entries that have completed DMA payload transfer have the highest priority to be processed and forwarded; the Deallocate MsgID command has the second highest processing priority; and all other tracker entries have the lowest priority to be processed and forwarded. The operation returns.

[0097] Figure 5 A computer system 500 according to one aspect of this application is illustrated, which facilitates multi-traffic category tracker arbitration using focus and priority release. The computer system 500 includes a processor 502, a memory 504, and a storage device 506. The memory 504 may include volatile memory (e.g., random access memory (RAM)) that serves as managed memory and can be used to store one or more memory pools. Furthermore, the computer system 500 may be coupled to peripheral I / O user devices 510 (e.g., a display device 511, a keyboard 512, and a pointing device 513). The storage device 506 includes a non-transitory computer-readable storage medium and stores an operating system 516, instructions 518, and data 530. The computer system 500 may be a network device 500 having at least one processing resource (e.g., 502) and circuitry (including modules, units, components, etc., such as 506, in hardware, software, or a combination of hardware and software) to perform the methods, operations, calculations, determinations, and functions described herein. In network device 500, circuitry or storage devices may store instructions, including instructions for performing the operations described herein, which, when executed by at least one processing resource (e.g., 502), are also included. Computer system 500 may include... Figure 5 The number of entities or instructions shown may be fewer or more.

[0098] Instruction 518 may include instructions that, when executed by computer system 500, cause computer system 500 to perform the methods and / or processes described in this disclosure. Specifically, instruction 518 may include instruction 520 for receiving instructions corresponding to message packets and indicating traffic category identifiers (IDs), as described above. Figure 1A and 1B Instruction 150 and Figure 3A As described in operation 302.

[0099] Instruction 518 may also include instruction 522, for storing an entry of the instruction in a tracker data structure, the tracker data structure including an entry corresponding to the instruction, wherein the corresponding entry includes the traffic category ID of the corresponding entry, whether the corresponding entry needs to be processed, whether the transfer of the DMA payload associated with the corresponding entry has been completed, and an indicator of whether the corresponding entry is actively transferring the DMA payload, as described above regarding... Figure 1A and 1B Tracker Arbitrator 120 Figure 2 The tracker bid mask unit in Figure 200 and Figure 3A As described in operation 304.

[0100] Instruction 518 may also include instructions for selecting a winning tracker entry from entries by arbitrating among entries based on instructions 524, 526, and 528. Instruction 518 may include instruction 524 for determining a current mask indicating entries currently excluded from being selected as the winning tracker entry, as described above regarding... Figure 2 The generated vectors bidvca 266 and bidvptc 268, the progressive masking update of elements 230 and pseudocodes 232-238, and pseudocode 252 in element 250, and Figure 3A As described in operation 308.

[0101] Instruction 518 may include instruction 526 for periodically updating the current mask in response to detecting a first condition, wherein the first condition includes the need for processing, sufficient available output queue credits with traffic category IDs, and remaining tracker entries that are not currently masked, as described above. Figure 2 The above refers to elements 210, 220, 230, and 250. Figure 3A Operation 310 describes in detail how to update the current mask periodically.

[0102] Instruction 518 may also include instruction 528 for identifying the winning tracker entry based on the entry's indicator and the current mask, as described above. Figure 2 The operations preceding pseudocode 252 in element 250 and Figure 2 As described in operation 312.

[0103] Instruction 518 may also include instruction 530, for forwarding information related to the winning tracker entry in response to a predetermined priority being met, as described above regarding... Figure 1A and 1B The NOR 144, multiplexer 142, and output 178 are included. Figure 3A As described in operation 314.

[0104] Instruction 518 may include more than Figure 5 The instructions shown are further instructions. For example, instruction 518 may include instructions for performing the above-described instructions. Figure 1A , 1B Instructions related to operations involving variables, inputs, outputs, results, communication, pseudocode, and modules / units as described in section 2; Figure 3A , 3B Operations of flowcharts in 4A and 4B; and Figure 6 CRM 600.

[0105] Data 530 may include any data required as input, or any data generated as output by the methods, operations, communications and / or processes described in this disclosure. Specifically, data 530 may store at least the following information: messages; instructions; message IDs; traffic category IDs; entries; tracker entries; tracker data structures; vectors; bit vectors; a two-dimensional array of vectors or bit vectors for each traffic category; indicators; indicators indicating whether a corresponding entry needs to be processed; indicators indicating whether the transfer of the DMA payload associated with the corresponding entry is complete; indicators indicating whether the corresponding entry is actively transferring the DMA payload; the winning tracker entry; the current mask; the updated mask; indicators of entries excluded from being selected as the winning tracker entry; indicators indicating that the output queue credits are sufficient or available; indicators indicating that the pipeline queue credits are sufficient or available; indicators indicating whether the corresponding entry is currently masked; a vector based on one or more indicators; the lowest-numbered tracker entry; a signal to clear the entire mask; a signal to determine how to partially clear the mask; an indicator indicating whether the mask needs to be updated; an indicator of the winning tracker entry in the current period; an indicator of the traffic category ID of the winning tracker entry; and a status indicator of the winning tracker entry.

[0106] Figure 6 A computer-readable medium (CRM) 600 according to one aspect of this application is shown, which utilizes focus and priority release to facilitate multi-flow category tracker arbitration. The CRM 600 may be a non-transitory computer-readable medium or device storing instructions that, when executed by a computer or processor, enable the computer or processor to perform a method, including the methods and operations described herein.

[0107] The CRM 600 can store instructions 610 to receive instructions corresponding to message packets and indicate traffic category identifiers (IDs), as mentioned above. Figure 1A and 1B Instruction 150 and Figure 3A As described in operation 302.

[0108] The CRM 600 can also store instructions 620 to store instruction entries in a tracker data structure. This tracker data structure includes entries corresponding to the instructions, where each entry includes the traffic category ID of the corresponding entry, whether the corresponding entry needs processing, whether the DMA payload transfer associated with the corresponding entry has been completed, and an indicator of whether the corresponding entry is actively transferring the DMA payload, as described above. Figure 1A and 1B Tracker Arbitrator 120 Figure 2The tracker bid mask unit in Figure 200 and Figure 3A As described in operation 304.

[0109] The CRM 600 can also store instruction 630 to select a winning tracker entry from entries by arbitrating among them, as mentioned above. Figure 3A Element 306 is described.

[0110] Instruction 630 may include instruction 632 for determining the current mask, which indicates the entry currently excluded from being selected as the winning tracker entry, as described above regarding... Figure 2 The generated vectors bidvca 266 and bidvptc 268, the progressive masking update of elements 230 and pseudocodes 232-238, and pseudocode 252 in element 250, and Figure 3A As described in operation 308.

[0111] Instruction 630 may include instruction 634 for periodically updating the current mask in response to detecting a first condition, the first condition including the need for processing, sufficient available output queue credits with traffic category IDs, and remaining tracker entries that are not currently masked, as described above. Figure 2 The above refers to elements 210, 220, 230, and 250. Figure 3A Operation 310 describes in detail the periodic update of the current mask.

[0112] Instruction 630 may also include instruction 636 for identifying the winning tracker entry based on the current mask and the entry's indicator, as described above regarding... Figure 2 The operations preceding pseudocode 252 in element 250 and Figure 2 As described in operation 312.

[0113] CRM 600 can also store instructions 640 for forwarding information related to the winning tracker entry in response to a predetermined priority, as described above. Figure 1A and 1B The NOR 144, multiplexer 142, and output 178 are included. Figure 3A As described in operation 314.

[0114] CRM 600 can include more Figure 6 The instructions shown are more than just those shown. For example, the CRM 600 can also store instructions for performing the above-mentioned commands. Figure 1A , 1B And operations related to variables, inputs, outputs, results, communication, pseudocode, and modules / units in section 2; Figure 3A , 3B Instructions for operating flowcharts in 4A and 4B; and Figure 5Computer systems (or network devices).

[0115] In general, the disclosed aspects provide a method, network device, and non-transitory computer-readable storage medium that facilitate multi-traffic category tracker arbitration with focused and prioritized releases. In one aspect, the system receives instructions corresponding to message packets and indicating traffic category identifiers (IDs) via a direct memory access (DMA) engine. The system stores entries of the instructions in a tracker data structure including entries corresponding to the instructions, each entry including the traffic category ID of the corresponding entry, and indicators indicating whether the corresponding entry needs processing, whether the transfer of the DMA payload associated with the corresponding entry has been completed, and whether the corresponding entry is actively transferring the DMA payload. The system selects a winning tracker entry from the entries by arbitrating among them, comprising: determining a current mask indicating entries currently excluded from being selected as winning tracker entries; periodically updating the current mask in response to detecting a first condition, the first condition including remaining tracker entries that need processing, have sufficient available output queue credits for the traffic category ID, and are currently not masked; and identifying the winning tracker entry based on the current mask and the entry's indicator. In response to meeting a predetermined priority, the system forwards information associated with the winning tracker entry.

[0116] In a variation of this approach, the system arbitrates between entries by performing at least the following operations: The system generates a first vector (e.g., bid 165) based on tracker entries that require processing and are ready for processing. The system generates a second vector (e.g., bid_vldp167) based on tracker entries that require processing and are actively transferring DMA payloads. The system generates a third vector (e.g., bidp166) based on the first vector and tracker entries actively transferring DMA payloads. The system generates a fourth vector (e.g., bidvca 266) based on the detection of a first condition. The system generates a set of fifth vectors (e.g., bidvptc 268) based on tracker entries indicating the corresponding traffic category ID and requiring processing.

[0117] In another variation of this approach, the system identifies the winning tracker entry by performing at least the following operations: The system generates a sixth vector (e.g., bidm) based on the current mask, the first vector, the third vector, and whether the transfer of the DMA payload associated with the corresponding entry has been completed. The system identifies the tracker entry with the lowest number in the sixth vector as the current winning tracker entry.

[0118] In another variation, the system updates the current mask for each bit of the mask within a corresponding period by performing at least the following operations: The system determines that the current mask needs to be updated based on the selected winning tracker entry. The system determines that the transfer of the DMA payload associated with the winning tracker entry is incomplete. The system determines that the position of the corresponding bit in the mask is less than or equal to the position or number associated with the winning tracker entry. The system determines at least one of the following: the position of the corresponding bit in the mask corresponding to the tracker entry indicates a traffic category identifier that is the same as the traffic category ID of the winning tracker entry; or the position of the corresponding bit in the mask corresponds to a tracker entry that does not currently need to be processed.

[0119] In another variant, the system updates the current mask for each bit of the mask in the corresponding period, which includes clearing the current mask by clearing the entire current mask in response to a command to clear the current mask received from an external component.

[0120] In another variant, the system updates the current mask for each bit of the mask within the corresponding period by performing partial clearing of the current mask for each traffic category: determining that there are no tracker entries associated with the corresponding traffic category that need to be processed and are not masked; and clearing any bits in the current mask corresponding to tracker entries associated with the corresponding traffic category.

[0121] In another variant, the system updates the current mask in the corresponding period for each bit of the mask based on at least one of the following: whether the mask needs to be updated; the winning tracker entry in the current period; the traffic category ID of the winning tracker entry; or the status of the winning tracker entry.

[0122] In another variant, the received instruction also indicates a message identifier (ID). The corresponding entry in the tracker data structure also includes an indicator of whether the corresponding entry is marked as released. The system receives a command to release the resource associated with the first message ID. The system releases the resource associated with the first message ID through the following steps: in response to identifying any active tracker entry with an instruction containing the first message ID, marking the state of the corresponding active tracker entry as released without caching any context; removing any context associated with the message ID from the cache; and releasing the resource associated with the message ID.

[0123] In another variant, the system maintains multiple output queues, each corresponding to a specific traffic category ID, and each output queue is associated with an output queue credit. If there is insufficient output queue credit for a given output queue, the system avoids placing packets associated with instructions indicating the traffic category ID into that output queue.

[0124] In another variation, before forwarding the information associated with the winning tracker entry, the system selects among the multiplexer inputs based on predetermined priorities by performing the following operations: The system selects the tracker entry whose DMA payload transfer is complete with first priority. The system selects the command to release the message ID with second priority. The system selects all other tracker entries selected based on arbitration with third priority. First priority is higher than second priority, and second priority is higher than third priority. For other tracker entries with third priority, the tracker entry that actively transfers the DMA payload is selected more frequently than the rest of the other tracker entries with third priority.

[0125] In another variant, the forwarding information associated with the winning tracker entry includes: the number of the winning tracker entry; and instructions obtained from retrieving the winning tracker entry from the tracker data structure.

[0126] On the other hand, a computer system or network device is provided, including at least one processing resource and a storage device (e.g., circuitry) for storing instructions. When executed by the at least one processing resource, the instructions include instructions for receiving instructions corresponding to message packets and indicating traffic category identifiers (IDs). The instructions are also used to store entries of the instructions in a tracker data structure, the tracker data structure including entries corresponding to the instructions, wherein each entry includes a traffic category ID of the corresponding entry, and indicators indicating whether the corresponding entry needs to be processed, whether the transfer of a DMA payload associated with the corresponding entry has been completed, and whether the corresponding entry is actively transferring a DMA payload. The instructions are also used to select a winning tracker entry from the entries by arbitration among the entries, comprising: determining a current mask indicating entries currently excluded from being selected as winning tracker entries; periodically updating the current mask in response to detecting a first condition, wherein the first condition includes remaining tracker entries that need to be processed, have sufficient available output queue credits for the traffic category ID, and are currently not masked; and identifying the winning tracker entry based on the current mask and the entry's indicator. The instruction is also used to forward information associated with the winning tracker entry in response to a predetermined priority being met.

[0127] In one variation of this, the instructions for identifying the winning tracker entry are further used to generate a vector based on the current mask, tracker entries that need to be processed and are ready to be processed, tracker entries that need to be processed and are actively transferring DMA payloads, and whether the DMA payload transfer with the corresponding entry has been completed. The instructions are also used to identify the tracker entry with the lowest number in the vector as the current winning tracker entry.

[0128] Computer systems or network devices may include content processing systems that include the aforementioned instructions and instructions for performing the operations described herein, including those related to... Figure 1A , 1B And operations related to variables, inputs, outputs, results, communication, pseudocode, and modules / units in section 2; Figure 3A , 3B Operations of flowcharts in 4A and 4B; and Figure 6 CRM 600.

[0129] On the other hand, a non-transitory computer-readable storage medium (CRM) is provided, which stores instructions that, when executed by a computer, cause the computer to receive instructions corresponding to message packets and indicating traffic category identifiers (IDs). The instructions are also used to store entries of the instructions in a tracker data structure including entries corresponding to the instructions, wherein the corresponding entry includes the traffic category ID of the corresponding entry and indicators indicating whether the corresponding entry needs to be processed, whether the transfer of the DMA payload associated with the corresponding entry has been completed, and whether the corresponding entry is actively transferring the DMA payload. The instructions are also used to select a winning tracker entry from the entries by arbitration among the entries, comprising: determining a current mask indicating entries currently excluded from being selected as winning tracker entries; periodically updating the current mask in response to detecting a first condition, the first condition including remaining tracker entries that need to be processed, have sufficient available output queue credits for the traffic category ID, and are currently not masked; and identifying the winning tracker entry based on the current mask and the entry's indicator. The instructions are also used to forward information associated with the winning tracker entry in response to satisfying a predetermined priority.

[0130] CRM can also store data used to perform the above and Figure 1A , 1B Instructions related to operations involving variables, inputs, outputs, results, communication, pseudocode, and modules / units as described in section 2; Figure 3A , 3B Operations of flowcharts in 4A and 4B; and Figure 5 Computer systems (network devices).

[0131] The foregoing descriptions are for illustrative and descriptive purposes only. They are not intended to be exhaustive or to limit the aspects described herein to the disclosed forms. Therefore, those skilled in the art will appreciate many modifications and variations. Furthermore, the foregoing disclosure is not intended to limit the aspects described herein. The scope of the aspects described herein is defined by the appended claims.

Claims

1. A computer-implemented method, comprising: The Direct Memory Access (DMA) engine receives instructions corresponding to the message packets and indicating the traffic category identifier (ID); The entries for the instructions are stored in a tracker data structure that includes entries corresponding to the instructions. The corresponding entries include the traffic category ID of the corresponding entry, whether the corresponding entry needs to be processed, whether the transfer of the DMA payload associated with the corresponding entry has been completed, and an indicator of whether the corresponding entry is actively transferring the DMA payload. A winning tracker entry is selected from the entries by arbitrating among them, which includes: Determine the current mask, which indicates the entry currently excluded from being selected as the winning tracker entry; In response to the detection of a first condition, the current mask is updated periodically, the first condition including the need for processing, sufficient available output queue credits for the traffic category ID, and remaining tracker entries that are not currently masked; and The winning tracker entry is identified based on the current mask and the entry's indicator; and In response to meeting a predetermined priority, information associated with the winning tracker entry is forwarded.

2. The method of claim 1, wherein arbitration between the items further comprises: Generate a first vector based on the tracker entries that need to be processed and are ready to be processed; A second vector is generated based on the tracker entries that need to be processed and are actively transferring DMA payloads; A third vector is generated based on the first vector and the tracker entry that is actively transmitting the DMA payload; A fourth vector is generated based on the detection of the first condition; as well as Generate a set of fifth vectors, each based on a tracker entry that indicates the corresponding traffic category ID and needs to be processed.

3. The method of claim 2, wherein identifying the winning tracker entry comprises: A sixth vector is generated based on whether the current mask, the first vector, the third vector, and the DMA payload associated with the corresponding entry have been transferred. as well as The tracker entry with the lowest number in the sixth vector is identified as the current winning tracker entry.

4. The method according to claim 1, wherein, Updating the current mask for each bit of the mask in the corresponding period includes: Based on the selected winning tracker entry, it is determined that the current mask needs to be updated; It was determined that the transfer of the DMA payload associated with the winning tracker entry was incomplete; Determine that the position of the corresponding bit in the mask is less than or equal to the position or number associated with the winning tracker entry; and Determine at least one of the following: The position of the corresponding bit in the mask corresponding to the tracker entry indicates the same traffic category ID as the traffic category ID of the winning tracker entry; or The position of the corresponding bit in the mask corresponds to a tracker entry that does not currently need to be processed.

5. The method of claim 1, wherein updating the current mask for each bit of the mask in a corresponding period further comprises: In response to receiving a command to clear the current mask from an external component, the current mask is cleared by clearing the entire current mask.

6. The method of claim 1, wherein updating the current mask for each bit of the mask in a corresponding period further comprises: For each traffic category, perform partial clearing of the current mask using the following steps: Determine that there are no tracker entries associated with the corresponding traffic category that need to be processed and are not masked; and Remove any bits in the current mask that correspond to the tracker entry associated with the corresponding traffic category.

7. The method according to claim 1, wherein, The current mask is updated in the corresponding period based on at least one of the following: for each bit of the mask: Does the mask need to be updated? The winning tracker entry in the current period; The traffic category ID of the winning tracker entry; or The status of the winning tracker entry.

8. The method according to claim 1, in, The received instruction also indicates the message identifier (ID); The corresponding entry in the tracker data structure also includes an indicator indicating whether the corresponding entry is marked as released; and The method further includes: Receive a command to release the resource associated with the first message ID; and Release the resource associated with the first message ID by following these steps: In response to identifying any activity tracker entry with an instruction containing the first message ID, the state of the corresponding activity tracker entry is marked as released without caching any context; Remove any context associated with the message ID from the cache; and Release the resources associated with the message ID.

9. The method according to claim 1, further comprising: Maintain multiple output queues, each corresponding to a traffic category ID, and each output queue is associated with an output queue credit. as well as In response to insufficient output queue credit for the corresponding output queue, avoid placing packets associated with the instruction indicating the traffic category ID into the corresponding output queue.

10. The method of claim 1, wherein before forwarding the information associated with the winning tracker entry, the method further comprises: The multiplexer inputs are selected based on the predetermined priority through the following steps: Select the tracker entry whose DMA payload transfer is completed with the highest priority; Select the command to release the message ID with the second priority; as well as All other tracker entries selected based on arbitration are chosen with the third priority. Wherein the first priority is higher than the second priority, and wherein the second priority is higher than the third priority, and Among the other tracker entries in the third priority category, the tracker entries that actively transmit DMA payloads are selected more frequently than the rest of the other tracker entries in the third priority category.

11. The method according to claim 1, wherein, The forwarding information associated with the winning tracker entry includes: The number corresponding to the winning tracker entry; and The instruction obtained by searching for the winning tracker entry in the tracker data structure.

12. A network device, comprising: At least one processing resource; and A storage device that stores instructions, which, when executed by the at least one processing resource, include instructions for the following operations: Receive instructions that correspond to the message packets and indicate the traffic category identifier (ID); The entries for the instructions are stored in a tracker data structure that includes entries corresponding to the instructions. The corresponding entry includes the traffic category ID of the corresponding entry, whether the corresponding entry needs to be processed, whether the transmission of the DMA payload associated with the corresponding entry has been completed, and an indicator of whether the corresponding entry is actively transmitting the DMA payload. A winning tracker entry is selected from the entries by arbitrating among them, which includes: Determine the current mask, which indicates the entry currently excluded from being selected as the winning tracker entry; In response to the detection of a first condition, the current mask is updated periodically, the first condition including the need for processing, sufficient available output queue credits for the traffic category ID, and remaining tracker entries that are not currently masked; and The winning tracker entry is identified based on the current mask and the entry's indicator; and In response to meeting a predetermined priority, information associated with the winning tracker entry is forwarded.

13. The network device according to claim 12, wherein, Identifying the winning tracker entry includes: A vector is generated based on the current mask, tracker entries that need to be processed and are ready to be processed, tracker entries that need to be processed and are actively transferring DMA payloads, and whether the DMA payload transfer associated with the corresponding entry has been completed; and The tracker entry with the lowest number in the vector is identified as the current winning tracker entry.

14. The network device according to claim 12, wherein, Updating the current mask in the corresponding period for each bit of the mask includes: Based on the selected winning tracker entry, it is determined that the current mask needs to be updated; It was determined that the transfer of the DMA payload associated with the winning tracker entry was incomplete; Determine that the position of the corresponding bit in the mask is less than or equal to the position or number associated with the winning tracker entry; and Determine at least one of the following: The position of the corresponding bit in the mask corresponding to the tracker entry indicates the same traffic category ID as the traffic category ID of the winning tracker entry; or The position of the corresponding bit in the mask corresponds to a tracker entry that does not currently need to be processed.

15. The network device of claim 12, wherein updating the current mask for each bit of the mask in a corresponding period further comprises: For each traffic category, perform partial clearing of the current mask using the following steps: Determine that there are no tracker entries associated with the corresponding traffic category that need to be processed and are not masked; and Remove any bits in the current mask that correspond to the tracker entry associated with the corresponding traffic category.

16. The network device according to claim 12, Its features are, The received instruction also indicates a message identifier (ID); The corresponding entry in the tracker data structure also includes an indicator indicating whether the corresponding entry is marked as released; and The instructions mentioned therein are also used for: Receive a command to release the resource associated with the first message ID; and Release the resource associated with the first message ID by following these steps: In response to identifying any activity tracker entry with an instruction containing the first message ID, the state of the corresponding activity tracker entry is marked as released without caching any context; Remove any context associated with the message ID from the cache; and Release the resources associated with the message ID.

17. The network device of claim 12, wherein before forwarding the information associated with the winning tracker entry, the instruction is further configured to: The multiplexer inputs are selected based on the predetermined priority through the following steps: Select the tracker entry whose DMA payload transfer is completed with the highest priority; Select the command for releasing the message ID with the second priority; and All other tracker entries selected based on arbitration are chosen with the third priority. Wherein the first priority is higher than the second priority, and the second priority is higher than the third priority, and Among the other tracker entries in the third priority category, the tracker entries that actively transmit DMA payloads are selected more frequently than the rest of the other tracker entries in the third priority category.

18. A non-transitory computer-readable medium storing instructions, the instructions being used to: At least one processing resource; and A storage device that stores instructions, which, when executed by the at least one processing resource, include instructions for the following operations: Receive instructions that correspond to the message packets and indicate the traffic category identifier (ID); The entries for the instructions are stored in a tracker data structure that includes entries corresponding to the instructions. in, The corresponding entry includes the traffic category ID of the corresponding entry, whether the corresponding entry needs to be processed, whether the DMA payload associated with the corresponding entry has been transferred, and an indicator of whether the corresponding entry is actively transferring the DMA payload. A winning tracker entry is selected from the entries by arbitrating among them, which includes: Determine the current mask, which indicates the entry currently excluded from being selected as the winning tracker entry; In response to the detection of a first condition, the current mask is updated periodically, the first condition including the need for processing, sufficient available output queue credits for the traffic category ID, and remaining tracker entries that are not currently masked; and The winning tracker entry is identified based on the current mask and the entry's indicator; and In response to meeting a predetermined priority, information associated with the winning tracker entry is forwarded.

19. The non-transitory computer-readable medium of claim 18, wherein identifying the winning tracker entry comprises: A vector is generated based on the current mask, tracker entries that need to be processed and are ready to be processed, tracker entries that need to be processed and are actively transferring DMA payloads, and whether the DMA payload transfer associated with the corresponding entry has been completed; and The tracker entry with the lowest number in the vector is identified as the current winning tracker entry.

20. The non-transitory computer-readable medium of claim 18, wherein updating the current mask for each bit of the mask in a corresponding period further comprises: For each traffic category, partial clearing of the current mask is performed through the following steps: determining that there are no tracker entries associated with the corresponding traffic category that need to be processed and are not masked; as well as Remove any bits in the current mask that correspond to the tracker entry associated with the corresponding traffic category.

Images