Programmable Traffic Management Engine

Abstract

Examples herein describe a programmable traffic management engine that includes both programmable and non-programmable hardware components. The non-programmable hardware components are used to generate features, which can then be used to implement different traffic management algorithms. Depending on which traffic management algorithm the PTM engine is configured to implement, the PTM engine may use a subset (or all) of the features to execute the algorithm. The programmable hardware components within the PTM engine are programmable (e.g., customizable) by a user to implement a selected algorithm using some or all of the features provided by the non-programmable hardware components.

Description

[Technical Field]

[0001] Embodiments of the present disclosure generally relate to a programmable traffic management engine that includes hardware components that can be programmed to perform different traffic management services (eg, packet scheduling, shaping, and policing). [Background technology]

[0002] Data centers provide infrastructure containing thousands of servers to accommodate many concurrent tenants running a wide variety of services, such as web serving, web indexing, batch analytics, storage services, machine learning applications, video streaming, and financial services. These applications or services typically have different characteristics and throughput / latency requirements. To provide quality of service (QoS), fairly share resources, and improve network utilization, data centers require traffic management services, such as packet scheduling, shaping, and policing, to regulate network resources for tenants.

[0003] However, these traffic management services are currently provided by software applications running on central processing units (CPUs) within servers, which leads to high CPU utilization and reduces the CPU processing power available for other tasks. This increases the cost of operating data center services and reduces QoS in terms of fairness, traffic latency, and throughput, especially for high-speed line-speed (40 Gbps to 100 Gbps) cloud architectures. Implementing some of these traffic management services in hardware would reduce the CPU burden, but current off-the-shelf high-speed network interface cards (NICs) do not implement any traffic management services. While line-speed switches support some traffic management services, they typically offer a very limited set of scheduling algorithms, including starvation round-robin and strict priority to application-specific integrated circuits (ASICs). Line-speed switches lack programmability and customization because network operators cannot modify or replace the existing algorithms provided in these switches. Summary of the Invention

[0004] Techniques are described for implementing a programmable traffic management (PTM) engine. One example is an integrated circuit disposed within a chip that includes a non-programmable hardware component configured to generate a predetermined number of features for use as input to execute a network scheduling algorithm and a programmable hardware component configured to execute a different type of network scheduling algorithm, wherein, during operation, the programmable hardware component is configured to execute the network scheduling algorithm using at least one of the predetermined number of features provided by the non-programmable hardware component, and the integrated circuit is disposed entirely within the chip.

[0005] One example described herein is a method that includes providing a network scheduling algorithm implemented by a PTM engine that includes non-programmable hardware components and programmable hardware components, identifying features to be used as inputs to the network scheduling algorithm, configuring the non-programmable hardware components to provide the features to the programmable hardware components, and configuring the programmable hardware components to execute the network scheduling algorithm using the features. [Brief explanation of the drawings]

[0006] So that the above features briefly summarized above can be understood in detail, a more particular description can be had by reference to exemplary implementations, some of which are illustrated in the accompanying drawings. It should be noted, however, that the accompanying drawings illustrate only typical exemplary implementations and therefore should not be considered limiting of the scope thereof. [Figure 1]1 is a block diagram of a communication system having a programmable traffic management engine, according to an example. [Figure 2] 1 illustrates a programmable traffic management engine, according to an example. [Figure 3] 1 illustrates a packet classifier within a programmable traffic management engine, according to an example. [Figure 4] 1 illustrates a queue manager within a programmable traffic management engine, according to an example. [Figure 5] 1 illustrates a queue dispatcher within a programmable traffic management engine, according to an example. [Figure 6] 1 illustrates a shaper within a programmable traffic management engine, according to an example. [Figure 7] 1 is a table of exemplary dispatch time algorithms that may be supported by features generated by a programmable traffic management engine, according to an example. [Figure 8] 1 is a table of exemplary round robin algorithms that may be supported by features generated by a programmable traffic management engine, according to an example. [Figure 9] 1 is a flowchart for programming or replacing a DT or RR algorithm in a PTM engine, according to an example. [Figure 10] 1 is a flowchart for configuring a PTM engine, according to an example.

[0007] For ease of understanding, wherever possible, identical reference numbers have been used to indicate identical elements common to the figures. It is contemplated that elements of one example may be beneficially incorporated in other examples. DETAILED DESCRIPTION OF THE INVENTION

[0008] Various features are described below with reference to the drawings. It should be noted that the drawings may or may not be drawn to scale, and that elements of similar structure or function are represented by similar reference numerals throughout the drawings. It should be noted that the drawings are intended only to facilitate the description of features. They are not intended as an exhaustive description or as limitations on the scope of the claims. Furthermore, the illustrated example need not have all aspects or advantages shown. An aspect or advantage described in connection with a particular example is not necessarily limited to that example and may be implemented in any other example, even if not so illustrated or explicitly described.

[0009] This description describes a programmable traffic management (PTM) engine for high-speed line-rate architectures to address the above challenges. The benefits of the PTM engine are at least twofold: (i) it provides a flexible traffic management offloading framework that can be easily deployed on high-speed line-rate programmable platforms such as NICs (including smartNICs), switches, and middleboxes, and (ii) it abstracts packet scheduling algorithms, allowing developers to program and customize algorithms with high-level specifications, such as register transfer level (RTL) design using C / C++ or Verilog / VHDL, in the proposed traffic management architecture. The PTM engine simplifies the development of customized traffic management on hardware, allowing developers to focus more on designing customized network scheduling algorithms.

[0010] In one embodiment, the PTM engine includes both programmable and non-programmable hardware components. The non-programmable (or shared) hardware components are used to generate a number of features that can be used to implement different traffic management algorithms, such as departure time (DT) and round robin (RR) algorithms. Depending on which traffic management algorithm the PTM engine is configured to run, the PTM engine may use a subset (or all) of the features to implement the algorithm.

[0011] The programmable hardware components within the PTM engine are programmable (e.g., customizable) by a user to implement selected algorithms using some or all of the features provided by the non-programmable hardware components. The programmable hardware components may include programmable logic or domain-specific engines that can be programmed by a user using C / C++ or RTL to implement the desired algorithm. In this way, a user can select, modify, and customize the PTM engine to implement any known or future network traffic algorithm, as long as the algorithm relies on the features provided. The PTM engine has the flexibility of a pure software traffic management service with the advantage of implementing the service entirely in hardware, thereby reducing the burden on the CPU in the server.

[0012] FIG. 1 is a block diagram of a communication system 100 having a PTM engine 135, according to one example. The communication system 100 includes a host 105 (e.g., a computing system such as a standalone server, a blade server, a laptop, etc.) connected to a network 180 (e.g., the Internet or a local area network (LAN)). The host 105 includes a processor 110, a memory 115, and a NIC 125. The processor 110 represents any number of processing elements (e.g., CPUs) having any number of processing cores. The memory 115 (also referred to as host memory) can include volatile and non-volatile memory elements. In this example, the memory 115 stores a PTM driver 120 (e.g., a software application running on the processor 110) that allows a user to configure the PTM engine 135. Using, for example, C / C++, Python, or P4, the PTM driver 120 allows a user to access a matching table 315, switch between implemented DT and RR algorithms, and update parameters such as quantum and timeout within the PTM engine 135. Details for programming the PTM engine 135 are described in detail below.

[0013] The NIC 125 includes an integrated circuit (IC) 130, which may be an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or a system on a chip (SoC) including hardened circuitry, programmable logic, or a combination thereof. Additionally, while the IC 130 is shown as being within the NIC 125, in other embodiments, the IC may be external to the NIC 125 and serve as an interface between the processor 110 / memory 115 and the NIC 125. Additionally, rather than the IC 130 (and the PTM engine 135 embodied therein) being within the host 105, the IC 130 may be used within switches and middleboxes.

[0014] IC 130 illustrates that PTM engine 135 includes non-programmable hardware component 140 and programmable hardware component 165. Non-programmable hardware component 140 is shared by all network scheduling algorithms that may be implemented by PTM engine 135. In other words, non-programmable hardware component 140 is used regardless of the particular network scheduling algorithm that PTM engine 135 is currently programmed to implement. Thus, if PTM engine 135 is programmed to implement a different network scheduling algorithm, the non-programmable hardware component is reused. However, as described below, some of the features provided by non-programmable hardware component 140 may not be used by a particular algorithm. That is, a selected algorithm may require only a subset of the features provided by non-programmable hardware component 140.

[0015] In this example, non-programmable hardware components 140 include a packet classifier 145, a queue manager 150, a queue dispatcher 155, and a shaper 160 implemented in circuitry within IC 130. Details of the components are described in more detail in the following figures.

[0016] The programmable hardware component 165 includes circuitry within the IC 130 and the PTM engine 135 that is configurable using the PTM driver 120. In this example, the programmable hardware component 165 has components for implementing two different types of network scheduling algorithms: a DT algorithm using the DT module 170 and an RR algorithm using the RR module 175. For example, the DT module 170 and the RR module 175 may be implemented using programmable logic (e.g., as part of an FPGA or SoC) or a domain-specific engine (e.g., as part of an ASIC). In either case, the DT module 170 or the RR module 175 leverages features provided by the non-programmable hardware component 140 to implement the desired network scheduling algorithm. The selection of the DT module or the RR module is configured via the PTM driver 120. While this disclosure describes programmable modules for the DT and RR algorithms, other types of modules for other types of network scheduling algorithms are possible.

[0017] Figure 2 illustrates, according to one example, a detailed version of the PTM engine 135 introduced in Figure 1. As mentioned above, the PTM engine 135 has non-programmable hardware components that are common (shared) and reusable parts of the PTM engine across different network scheduling algorithms, while the programmable hardware components are programmable to implement the network scheduling algorithm selected by the designer.

[0018] The non-programmable hardware components (also referred to as the shell of the PTM engine 135) include a packet classifier 145 that is used to extract the flow ID of a given network packet as a key and look up the weight and rate associated with the key; a queue manager 150 that tracks the availability of queue resources and the aggregate weight of active queues; a queue dispatcher 155 that buffers packets and metadata and determines the transmission order of each flow; and a shaper 160 that controls the transmission rate of each flow for bandwidth throttling.

[0019] In one embodiment, the interfaces between these non-programmable hardware components and programmable hardware components (e.g., the DT module 170 and the RR module 175) are fixed. DT-related traffic scheduling algorithms, such as weighted fair queuing and strict priority, are implemented in the DT module 170, while RR algorithms, such as deficit round robin and weighted round robin algorithms, and their variants, are performed by the RR module 175. The PTM engine 135 also interfaces with a control plane 205, which is used by the PTM driver 120 to configure components within the PTM engine 135. This configuration can be done locally from the host or remotely from an external server over encrypted or unencrypted channels via communication protocols such as remote procedure call (RPC), P4Runtime, or simple network management protocol (SNMP). The architecture of the PTM engine 135 provides designers with the flexibility to customize and program various network scheduling algorithms using either high-level or low-level descriptions in the DT module 170 and the RR module 175.

[0020] When a packet arrives at the PTM, the packet classifier (PC) module derives the flow ID (fid) as the key of the packet through syntax analysis. By searching its preconfigured flow table using the derived key, the packet classifier 145 provides the corresponding table values including the weight and rate of the request. The flow table contains a set of mappings (fid -> <weight, rate>) that can be configured locally or remotely by the control plane 205. The packet classifier 145 also calculates the length of the packet and constructs control data (i.e., metadata) including <fid, weight, rate, packet length> as the output to the queue manager 150.

[0021] The queue manager 150 checks whether the fid received from the packet classifier 145 matches an existing record <fid, qid>, where qid is the unique queue ID assigned to the network flow of the received packet. If there is no matching record, this indicates that the flow is a new entry, a new qid for this flow is assigned, and the mapping <fid, qid> is registered in the queue manager 150. In addition, the queue manager 150 can update the weight of each newly assigned queue and track the aggregated weight of the active queues. When there are no packets arriving at a queue for a certain period (i.e., when the flow becomes inactive), the corresponding qid assigned to that flow is reclaimed and the qid (and the corresponding queue) can be assigned to a different flow. The input data of the DT module 170 is constructed in the queue manager 150 to calculate the DT of the packet. The queue manager 150 generates the control data and metadata provided to the queue dispatcher 155 for further processing.

[0022] Packet data and its metadata are stored in the packet queue and metadata queue of queue dispatcher 155, respectively. Queue dispatcher 155 may drop packets and their metadata if there is no assigned qid (due to no available queue resources) or if the allocated queue is full. In the example shown in FIG. 2, there are two dispatching modes supported in this module: DT mode and RR mode, which can be configured by the user or developer. In DT mode, queue dispatcher 155 outputs the qid with the smallest DT value, while in RR mode, it sends the qids of each non-empty queue in circular order. Queue dispatcher 155 transmits the output qid along with the packet length and rate of the flow, forms control data, and transmits metadata to shaper 160 for rate control.

[0023] Traffic regulation in shaper 160 is based on a token bucket. The token size is increased at a given rate extracted from metadata provided by queue dispatcher 155. In one embodiment, shaper 160 sends a packet out only if its packet length is less than its token size.

[0024] 3-6 provide detailed descriptions of the packet classifier 145, queue manager 150, queue dispatcher 155, and shaper 160 introduced in FIG.

[0025] 3 illustrates a packet classifier 145 within a PTM engine, according to one example. The packet classifier 145 is used to classify packets into flows and obtain configuration data, such as the weight and rate of demand for each flow. The packet classifier 145 includes a parsing module 305 and a matching module 310 that includes a table 315. The table 315 can be designed using hashing, trie-based methods, binary / ternary content addressable memory (BCAM / TCAM), and other flow / traffic classification methods. The packet classifier 145 can be designed using high-level synthesis tools, such as P4, C / C++, or RTL, such as Verilog / VHDL.

[0026] When a packet arrives at the packet classifier 145, the parsing module 305 extracts information from the packet to construct a fid, which is used as a key to search the table 315. The fid (or key) can be constructed by any data in the packet, such as the source / destination IP address, IP number, source / destination port, and payload. Using the derived fid / key, the matching module 310 consults the table 315 for the weight and rate stored in the table entry value corresponding to the fid / key. In one embodiment, the weight defines the priority of the packet's corresponding flow, while the rate is used to determine the flow's output (transmit or receive) rate. If the fid does not match, the matching module 310 may use default values. That is, a user may configure the table to have weights and rates for only a subset of flows that can be processed by the PTM engine (that the user wants to treat differently from other flows). If a packet is received that does not match an entry in the table, the packet is assigned default weight and rate values.

[0027] Both the weights and rates are configured by the user via a config_tb interface and a control plane (not shown) to add entries in table 315. The config_tb interface can be implemented using, for example, an Advanced eXtensible Interface-Lite (AXI-Lite) interface.

[0028] In addition to identifying the weight and rate for each packet, the packet classifier 145 calculates the packet length (pktlen) of each packet and the control data (i.e.,

[0029]

number

[0030] FIG. 4 illustrates a queue manager 150 within a PTM engine, according to one example. The queue manager 150 tracks the availability of queue resources and the aggregate weights of active queues and includes a weight manager module 405 and a queue manager module 425. The queue manager module 425 maintains queue resources by assigning unique qids to new flows and claiming assigned qids for expired / inactive flows. The weight manager 405 accumulates the weight of each active queue and records the weight of each queue. The queue manager module 425 allows the PTM engine to support a number of flows far greater than the physical queue resources. That is, only a subset of the possible flows may be actively sending packets to the PTM engine in a given time window. These active flows may be assigned qids, while flows that are not actively generating packets may not. The queue manager module 425 can evaluate flows constantly or at intervals to determine when a previously active flow has now become inactive or expired (e.g., the PTM engine has not received packets corresponding to the flow for a predetermined period of time). The queue manager module 425 can then reassign qids to different flows. In this way, the number of queues used to service flows can be reduced.

[0031] The queue manager 150 also has a timer counter to record a system-wide virtual time (VT) that can be used to calculate departure times (DT) in connected modules.

[0032] The queue manager module 425 includes three components: a queue allocator 435, an idle pool 430, and a pre_DT queue 440. It receives control data (

[0033]

number

[0034] The pre_DT queue 440 is used to store the DT of the leading element in each active queue calculated from the DT module (not shown in FIG. 4). The pre_DT queue 440 provides a request / update interface to the DT module for communication. This interface can be implemented using a random access memory (RAM) read / write interface.

[0035] The weight manager module 405 consists of three components: a weight queue 410, a weight controller 415, and a weight accumulator 420. The weight queue 410 records the weight of each active queue, i.e., the queue whose qid is assigned to the flow. When obtaining a qid and a weight from other components, the weight controller 415 can first check whether the weight queue 410 has data for the queue by sending a read request. If there is a record in the weight queue 410 and the returned data does not match the weight received from the queue manager module 425, the weight controller 415 issues a write request to update the weight queue 410 and activates the weight accumulator 420 to recalculate the aggregated weight of all active queues. The aggregated weight is used in the DT module.

[0036] To communicate with the DT module, the queue manager 150 provides a DT_role_in interface, a DT_role_out interface, and a memory access (pre_DT) interface. In one embodiment, the DT_role_in interface and the DT_role_out interface have the same data structure including <qid, pktlen, VT, DT, weight, weight_sum, new_flow, qids_all_occupied>, where new_flow indicates that the flow is a new entry and qids_all_occupied is a flag indicating that the queue resources are not available.

[0037] The queue manager 150 outputs control data (i.e.,

[0038] [Number] ) which includes <qid, DT, pktlen, rate, qids_all_occupied> to the downstream queue dispatcher.

[0039] 5 illustrates the queue dispatcher 155 in the PTM engine, according to an example. The queue dispatcher 155 determines the transmission order of packets belonging to different flows and is composed of three components: a metadata queue 505, a packet queue 515, and a DT comparator 510. The queue dispatcher 155 receives packet data and control data (

[0040]

number

[0041] The queue dispatcher 155 of Figure 5 includes hardware to support two dispatching modes: DT mode and RR mode. Developers can select which of these modes is currently active using the control interface config_rr. In one embodiment, only one of these modes (and the corresponding DT / RR module) is active in the PTM engine at any given time. In DT mode, the queue dispatcher 155 outputs the qid with the smallest DT value, while in RR mode, the queue dispatcher 155 sends the qids of each non-empty queue in circular order. The control output of the queue dispatcher 155 to the shaper (i.e.,

[0042]

number

[0043] When operating in DT mode, the metadata queue 505 stores the first metadata element (dts top ) and instructs the DT comparator 510 to obtain the qid with the minimum DT value.

[0044]

number

[0045] When operating in RR mode, the qids of non-empty queues are selected in a circular order according to a round-robin scheduling algorithm implemented in the RR module 175. The rest of the operation of the queue dispatcher 155 is the same as when operating in DT mode.

[0046] To communicate with the RR module 175, the queue dispatcher 155 provides an RR_role_in interface and an RR_role_out interface. The RR_role_in interface contains the VLD, qid, weight, pktlen, and rate, while the RR_role_out interface contains the qid, pktlen, and rate. The control interface config_rr is i is used to configure the DT / RR mode and the quantum value of the queue. This control interface can be implemented using an AXI-Lite interface. The quantum value can be utilized to develop various RR scheduling algorithms in the RR module 175, such as deficit round robin and deficit weighted round robin.

[0047] 6 illustrates a shaper 160 within a PTM engine, according to one example. The shaper 160 controls the sending rate of each flow for bandwidth throttling and includes a rdy_FIFO 605, a token bucket 615 (i.e., a token bucket cluster), and an arbiter 620. The rdy_FIFO 605 buffers metadata received from the queue dispatcher 155. The order of receipt of data in the rdy_FIFO 605 indicates the outcome of the packet scheduling algorithm in the DT module or the RR module. As shown, the qid is used as a selection signal for a multiplexer (mux) 610 to select which of the token buckets 615 should receive the pktlen and rate of the corresponding packet being output by the FIFO 605.

[0048] In one embodiment, each of the token buckets 615 corresponds to one of the packet queues 515 of FIG. 5. The token buckets 615 regulate the packet data of a flow to perform network policing and shaping. Tokens represent units of bytes that depend on the width of the data bus for different line speed systems. The depth of each token bucket 615 indicates the maximum number of tokens that can be stored, while the size indicates the currently available tokens in the bucket 615. In one embodiment, tokens are added to the bucket 615 at a fixed rate, which can be set by a user in the packet classifier.

[0049] The token bucket 615 that received the data receives the first element from the rdy_FIFO 605 via the mux 610.<pktlen’、qid’、レート’> First, get the current rate setting, Rate qid’ If the two rates have the same value, this indicates that the packet belongs to an old flow that was previously configured. pktlen' is the available token size, size qid’If so, the corresponding token bucket 615 releases qid' to the arbiter 620. In other words, the token bucket 615 has more tokens in its bucket than the length of the packet. Otherwise, the token bucket 615 releases qid' to the arbiter 620. qid’ The token bucket 615 blocks qid' until it reaches less than the packet length. That is, the token bucket 615 waits until more tokens are added at a predetermined rate. When the bucket 615 has more tokens than the packet length, the qid' is forwarded to the arbiter 620.

[0050] Rate' is the rate qid’ If different from , the token bucket 615 replaces the rate with rate' and sets the size qid’ to 0. Because several token buckets 615 can simultaneously release qids to the arbiter 620, this leads to congestion as packets of different flows share the same data bus. To solve this congestion problem, all qids with a ready status are buffered in the arbiter 620. If multiple qids are received, the arbiter 620 selects one of the qids (and corresponding packet) for transmission. In one embodiment, the arbiter 620 selects the qids in a circular order and uses a pop to indicate which packet queue 515 in the queue dispatcher 155 of FIG. 5 can transmit the packet. qid That is, the shaper 160 generates a pop signal. qid A signal is sent to the queue dispatcher 155 to let it know which packet queue 515 should be transmitted using the shared data bus.

[0051] In one embodiment, if a token bucket 615 allocated to a flow remains idle for a predetermined period of time, its available token size can be reset according to a token timeout set by the user. The token timeout value can be configured through a control interface config_sp, which can be implemented using an AXI-Lite interface.

[0052] As mentioned above, the PTM engine allows developers to customize the network scheduling algorithm. The DT module 170 and RR module 175 in FIG. 2 can be designed on an FPGA (e.g., using HLS with high-level specifications such as CIC++ or RTL with Verilog / VHDL) or can interface with a coprocessor such as a RISC (Reduced-Instruction-Set-Computer) core. The DT module 170 can be used to develop the algorithms required to calculate the departure time or priority of each packet / flow, while the RR module 175 can be utilized to design many round-robin variations that are not related to departure time. By leveraging the DT module 170 and RR module 175, developers can focus on developing the network scheduling algorithm instead of time-consuming system integration.

[0053] Both DT-based and RR-based algorithms can be abstracted and defined as a function of a set of features that are input to the algorithm. FIG. 7 is a table of exemplary DT algorithms that can be supported by features generated by a PTM engine, according to one example. The features in table 700 include queue ID (qid), packet length (pklen), virtual time (VT), previous departure time (pre_DT), weight, and aggregated weight (weight_sum). Using these features, developers can design and implement a large set of DT-related algorithms, including but not limited to the algorithms listed in table 700. To support programmability and customization of the PTM engine, the DT module 170 interface can receive qid, pktlen, VT, DT, weight, weight_sum, new_flow, and qids_all_occupied. The DT module 170 can also communicate with the pre_DT queue 440 of FIG. 4 to record the calculated departure times of packets of a flow. The interface for the DT module 170 may be implemented using a RAM read / write interface.

[0054] 8 is a table 800 of exemplary round robin algorithms that can be supported by features generated by a PTM engine, according to one example. Table 800 shows the required features (or inputs) of three representative RR-related algorithms. The features include qid, weight, pktlen, and quanta. These features can be used to express many round robin algorithm variants, including, but not limited to, Round Robin (RR), Weighted Round Robin (WRR), Deficit Round Robin (DRR), Deficit Round Robin with priority (DRR+ and DRR++), and Modified Deficit Round Robin (MDRR).

[0055] To support various round robin algorithms and provide customization in the PTM, the interface of the RR module 175 of Figure 2 can receive or generate the characteristics listed in Table 800. The interface of the RR module 175 can receive vld, qid, weight, pktlen, and rate as inputs, while outputting qid, pktlen, and rate. The vld signal can be asserted high every time a new packet arrives.

[0056] 9 is a flowchart of a method 900 for programming or replacing a DT or RR algorithm in a PTM engine, according to an example. At block 905, a user defines a network scheduling algorithm for implementation in the PTM engine. For example, the user may use an HLS tool or a high-level programming language with RTL (e.g., C / C++) to define the algorithm.

[0057] As mentioned above, the algorithm may be a DT type algorithm or an RR type algorithm. However, embodiments are not limited to these types of algorithms. Other types of algorithms may also be supported by the PTM engine, which may mean that the PTM engine may have additional programmable components (in addition to or instead of the DT and RR modules).

[0058] In block 910, the developer identifies the features to be used by the network scheduling algorithm. As shown in Figures 7 and 8, some of the DT and RR-based algorithms use only a subset of the features provided by non-programmable hardware components (e.g., packet classifiers, queue managers, queue dispatchers, and shapers), while other algorithms use all features. For example, in Figure 7, the first-in-first-out DT algorithm uses only qid and VT as inputs, while the weighted fair queuing DT algorithm uses all features as inputs.

[0059] When defining an algorithm, the developer can specify which features are required as inputs and which features provided by the PTM engine are not required.

[0060] At block 915, the developer configures the non-programmable hardware component to provide the identified features to a programmable hardware component (or components) within the PTM engine. In one embodiment, the developer configures the non-programmable hardware component using the control plane 205 via the PTM driver 120. For example, if the algorithm is an RR-based algorithm, the developer may configure the non-programmable hardware component to provide the identified features to an RR module within the PTM engine. Conversely, if the algorithm is a DT algorithm, the developer configures the non-programmable hardware component to provide the identified features to a DT module within the PTM engine.

[0061] At block 920, the developer configures the programmable hardware component to execute the algorithm using the identified features. That is, using the features provided by the non-programmable hardware component, the developer configures the programmable component (e.g., the DT module or the RR module) to execute the algorithm using the features as inputs. In one embodiment, at a given time when the PTM engine is operating (depending on the type of network scheduling algorithm selected), only one of the DT module or the RR module is active, while the other is inactive or unused. As mentioned above, these modules may be implemented using programmable logic or domain-specific engines. Once configured, the PTM engine can then execute as described above in FIGS. 2-6.

[0062] 10 is a flowchart of a method 1000 for configuring a PTM engine, according to an example. At block 1005, the PTM driver receives desired performance parameters for a network flow. The performance parameters may include priority, weight, desired rate, etc. In one embodiment, the PTM driver also constructs an ID for the flow.

[0063] In block 1010 , the PTM driver constructs a key-value pair that maps the flow ID to the value of the implementation parameter received in block 1005 .

[0064] In block 1015, the PTM driver configures a match table in the PTM engine, i.e., the PTM driver stores key-value pairs in table 315 (i.e., the match table) of the matching module 310 illustrated in FIG.

[0065] In the foregoing, reference is made to embodiments presented in the present disclosure. However, the scope of the present disclosure is not limited to the particular described embodiments. Instead, any combination of the described features and elements, whether associated with different embodiments or not, is contemplated for implementing and performing the contemplated embodiments. Furthermore, while the embodiments disclosed herein may achieve advantages over other possible solutions or prior art, whether or not a particular advantage is achieved by a given embodiment does not limit the scope of the present disclosure. Accordingly, the foregoing aspects, features, embodiments, and advantages are merely exemplary and should not be considered elements or limitations of the appended claims unless expressly recited in the claims.

[0066] As will be appreciated by one skilled in the art, embodiments disclosed herein may be embodied as a system, method, or computer program product. Accordingly, aspects may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects, all of which may be referred to generally herein as a "circuit," "module," or "system." Furthermore, aspects may take the form of a computer program product embodied in one or more computer-readable medium(s) having computer-readable program code embodied therein.

[0067] Any combination of one or more computer-readable media may be utilized. The computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium. The computer-readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (non-exhaustive list) of computer-readable storage media include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this specification, a computer-readable storage medium is any tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device.

[0068] A computer-readable signal medium may include a propagated data signal in which computer-readable program code is embodied, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electromagnetic, optical, or any suitable combination thereof. A computer-readable signal medium is not a computer-readable storage medium but may be any computer-readable medium that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

[0069] The program code embodied on the computer readable medium may be transmitted using any suitable medium, including but not limited to wireless, wireline, fiber optic cable, RF, etc., or any suitable combination of the foregoing.

[0070] Computer program code for carrying out operations of aspects of the present disclosure may be written in any combination of one or more programming languages, including, for example, object-oriented programming languages ​​such as Java, Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer, partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet Service Provider).

[0071] Aspects of the present disclosure are described below with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments presented in the present disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus, such that the instructions, executed by the processor of the computer or other programmable data processing apparatus, cause the machine to create means for performing the functions / acts specified in the flowchart and / or block diagram blocks.

[0072] These computer program instructions may also be stored on a computer-readable medium that can direct a computer, other programmable data processing apparatus, or other device to function in a particular way, such that the instructions stored on the computer-readable medium produce an article of manufacture that includes instructions that implement aspects of the functions / acts specified in the flowchart and / or block diagram blocks.

[0073] Computer program instructions may also be loaded into a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other device to create a computer-implemented process, such that the instructions executing on the computer or other programmable apparatus provide a process for implementing the functions / acts specified in the flowchart and / or block diagram blocks.

[0074] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of instructions, including one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may in fact be executed substantially concurrently, or the blocks may be executed in the reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, may be implemented by a dedicated hardware-based system that performs the specified functions or acts, or a combination of dedicated hardware and computer instructions.

[0075] While the forgoing is directed to particular embodiments, other and further embodiments may be devised without departing from the basic scope thereof, which scope is determined by the following claims.

Claims

1. An integrated circuit disposed within a chip, comprising: a non-programmable hardware component configured to generate a predetermined number of features for use as inputs to execute a network scheduling algorithm; a programmable hardware component configured to execute various network scheduling algorithms, wherein during operation, the programmable hardware component is configured to execute the network scheduling algorithms using at least one of the predetermined number of features provided by the non-programmable hardware component; Equipped with the integrated circuit is located entirely within the chip; Integrated circuit.

2. The integrated circuit of claim 1 , wherein during operation, the programmable hardware component is configured to execute only one network scheduling algorithm.

3. 3. The integrated circuit of claim 2, wherein the programmable hardware component comprises a first programmable component and a second programmable component, and during operation, only one of the first programmable component and the second programmable component is used to execute the network scheduling algorithm, while the other programmable component is ignored or unused.

4. 4. The integrated circuit of claim 3, wherein the first programmable component is specialized to implement a departure time (DT) algorithm and the second programmable component is specialized to implement a round robin (RR) algorithm.

5. The integrated circuit of claim 1 , wherein the network scheduling algorithm uses only a subset of a predetermined number of features as input.

6. The integrated circuit of claim 1 , wherein the non-programmable hardware component and the programmable hardware component are implemented on the same integrated circuit.

7. The integrated circuit of claim 6 , wherein the programmable hardware component is implemented using one of programmable logic or domain-specific engines on the same integrated circuit.

8. 2. The integrated circuit of claim 1, wherein the programmable hardware components comprise, in operation, a first programmable component specialized to implement a departure time (DT) algorithm and a second programmable component specialized to implement a round robin (RR) algorithm, and wherein the non-programmable hardware component and the programmable hardware component are implemented on the same integrated circuit.

9. 10. The integrated circuit of claim 1, wherein the non-programmable hardware components comprise a packet classifier, a queue manager, a queue dispatcher, and a shaper, and the programmable hardware components comprise a first programmable component and a second programmable component.

Images