Patent Application
20190007318
Systems for enabling multiple worker applications to operate on a set of data packets typically prepare queues, such as first in first out (FIFO) queues, that store pointers to the data packets and provide packets from the individual queues to each worker application as queue elements. The worker applications are typically assigned to various cores of a processor of a system. Each queue is independent, meaning each queue is allocated its own set of memory, and each worker application operates on its own copy of the queue. The queues are implemented in memory by a queue manager. The memory storage is controlled using a credit scheme whereby each worker application is assigned a certain number of credits.
Worker applications spend credits when enqueueing (or producing) packets to the queue, and earn credits when dequeueing (or consuming) packets from the queue. This approach tends to cause at least two credit loop scenarios where one or more worker applications run out of credits because their consuming does not release sufficient credit to meet their producing needs. In one scenario, packets are subject to packet multiplication where each subsidiary packet, when produced to the queue, results in a credit being expended. In another scenario, if a first application produces a packet that is then consumed by a second application, the first application does not earn back the credit it spent, which may, over time, lead to the first application running out of credits.
The concepts described herein are illustrated by way of example and not by way of limitation in the accompanying figures. For simplicity and clarity of illustration, elements illustrated in the figures are not necessarily drawn to scale. Where considered appropriate, reference labels have been repeated among the figures to indicate corresponding or analogous elements.
While the concepts of the present disclosure are susceptible to various modifications and alternative forms, specific embodiments thereof have been shown by way of example in the drawings and will be described herein in detail. It should be understood, however, that there is no intent to limit the concepts of the present disclosure to the particular forms disclosed, but on the contrary, the intention is to cover all modifications, equivalents, and alternatives consistent with the present disclosure and the appended claims.
References in the specification to “one embodiment,” “an embodiment,” “an illustrative embodiment,” etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may or may not necessarily include that particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to effect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described. Additionally, it should be appreciated that items included in a list in the form of “at least one A, B, and C” can mean (A); (B); (C); (A and B); (A and C); (B and C); or (A, B, and C). Similarly, items listed in the form of “at least one of A, B, or C” can mean (A); (B); (C); (A and B); (A and C); (B and C); or (A, B, and C).
The disclosed embodiments may be implemented, in some cases, in hardware, firmware, software, or any combination thereof. The disclosed embodiments may also be implemented as instructions carried by or stored on a transitory or non-transitory machine-readable (e.g., computer-readable) storage medium, which may be read and executed by one or more processors. A machine-readable storage medium may be embodied as any storage device, mechanism, or other physical structure for storing or transmitting information in a form readable by a machine (e.g., a volatile or non-volatile memory, a media disc, or other media device).
In the drawings, some structural or method features may be shown in specific arrangements and/or orderings. However, it should be appreciated that such specific arrangements and/or orderings may not be required. Rather, in some embodiments, such features may be arranged in a different manner and/or order than shown in the illustrative figures. Additionally, the inclusion of a structural or method feature in a particular figure is not meant to imply that such feature is required in all embodiments and, in some embodiments, may not be included or may be combined with other features.
Referring now to
In networking, data packets (or packets) may traverse a number of applications, also referred to herein as worker applications. In at least some implementations, a queue manager queues these packets based on the priority and ordering requirements of the tasks and associated packets. In packet processing applications, individual cores may do part of the overall task and pass packets to succeeding cores. These cores are may be referred to as ‘workers’ or ‘agents’. A worker may both consume and produce packets for processing. The queue manager may be implemented via hardware and referred to as a hardware queue manager (HQM). The HQM may be embodied as a system of queues that links worker applications, some of which will consume a packet from a queue (i.e., dequeue the packet from the queue), whereas others will produce a packet (i.e., enqueue the packet into the queue). In some embodiments, the HQM implements the queue in memory. In such embodiments, the memory is accessed using a credit scheme where each worker is assigned a share of the internal storage. In some embodiments, this share is represented as a number of credits. Accordingly, an application spends a credit when producing a packet for the queue (i.e., adding the packet to the memory of the queue) and earns a credit back when consuming a packet from the queue (i.e., removing a packet from the queue and processing the packet). In at least some implementations, each worker application is treated as equal, resulting in a scenario where a worker application may rely on consuming packets just to obtain credit with which to produce packets for enqueueing. This scenario is referred to herein as a credit loop. The technologies disclosed herein allow for the ability to avoid deadlocks caused due to credit loops.
As described in more detail herein, the illustrative network device 106 utilizes a hardware queue manager (HQM) and allocates cores of one or more processors of the network device 106 to process packets that are produced for and consumed from one or more queues. A packet is also referred to herein as a queue element. The HQM receives data packets from a network interface controller (NIC), which may also be referred to as a host fabric interface (HFI), of the network device 106 (i.e., data packets from the source endpoint node 102). Each packet includes metadata defining properties of the data packet. Worker applications, as described above, consume packets from the queue and perform operations on the metadata and data packets, such as compressing, decompressing, encrypting, or decrypting packet data and/or adding, removing, or modifying headers. Worker applications additionally may modify the metadata to indicate a status of the packet, such as whether a particular process has completed and/or whether the data packet is ready for processing by another worker application.
The source endpoint node 102 may be embodied as any type of computation or computing device capable of performing the functions described herein, including, without limitation, a computer, a desktop computer, a smartphone, a workstation, a laptop computer, a notebook computer, a tablet computer, a mobile computing device, a wearable computing device, a network appliance, a web appliance, a distributed computing system, a processor-based system, and/or a consumer electronic device. Similarly, the destination endpoint node 108 may be embodied as any type of computation or computing device capable of performing the functions described herein, including, without limitation, a computer, a desktop computer, a smartphone, a workstation, a laptop computer, a notebook computer, a tablet computer, a mobile computing device, a wearable computing device, a network appliance, a web appliance, a distributed computing system, a processor-based system, and/or a consumer electronic device. Each of the source endpoint node 102 and the destination endpoint node 108 may include components commonly found in a computing device such as a processor, memory, input/output subsystem, data storage, communication circuitry, etc.
The network 104 may be embodied as any type of wired or wireless communication network, including cellular networks (e.g., Global System for Mobile Communications (GSM), 3G, Long Term Evolution (LTE), Worldwide Interoperability for Microwave Access (WiMAX), etc.), digital subscriber line (DSL) networks, cable networks (e.g., coaxial networks, fiber networks, etc.), telephony networks, local area networks (LANs) or wide area networks (WANs), global networks (e.g., the Internet), or any combination thereof. Additionally, the network 104 may include any number of network devices 106 as needed to facilitate communication between the source endpoint node 102 and the destination endpoint node 108.
Each network device 106 may be embodied as any type of computing device capable of facilitating wired and/or wireless network communications between the source endpoint node 102 and the destination endpoint node 108. For example, each network device 106 may be embodied as a server (e.g., stand-alone, rack-mounted, blade, etc.), a router, a switch, a network hub, an access point, a storage device, a compute device, a multiprocessor system, a network appliance (e.g., physical or virtual), a computer, a desktop computer, a smartphone, a workstation, a laptop computer, a notebook computer, a tablet computer, a mobile computing device, or any other computing device capable of processing network packets.
As shown in
The CPU 210 may be embodied as any type of processor capable of performing the functions described herein. The CPU 210 may be embodied as a single or multi-core processor(s), a microcontroller, or other processor or processing/controlling circuit. In some embodiments, the CPU 210 may be embodied as, include, or be coupled to a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), a graphics processing unit (GPU), reconfigurable hardware or hardware circuitry, or other specialized hardware to facilitate performance of the functions described herein. In the illustrative embodiment, the CPU 210 is embodied as a processor containing a set 230 of multiple cores 232, 234, 236, 238, 240, 242, 244, and 246. While eight cores are shown in
In addition, the CPU 210, in the illustrative embodiment, also includes a queue manager logic unit 250. The queue manager logic unit 250 may be embodied as any hardware device (e.g., a co-processor, an FPGA, and ASIC, or circuitry) capable of performing functions that include inflight limiting of data packets in a queue environment. More specifically, the queue manager logic unit 250 is any device capable of performing the inflight packet count limiting scheme described with respect to
The I/O subsystem 214 may be embodied as circuitry and/or components to facilitate input/output operations with the CPU 210, the main memory 212, and other components of the network device 106. For example, the I/O subsystem 214 may be embodied as, or otherwise include, memory controller hubs, input/output control hubs, integrated sensor hubs, firmware devices, communication links (i.e., point-to-point links, bus links, wires, cables, light guides, printed circuit board traces, etc.), and/or other components and subsystems to facilitate the input/output operations. In some embodiments, the I/O subsystem 214 may form a portion of a system-on-a-chip (SoC) and be incorporated, along with one or more of the CPU 210, the main memory 212, and other components of the network device 106, on a single integrated circuit chip.
The communication circuitry 216 may be embodied as any communication circuit, device, or collection thereof, capable of enabling communications over the network 104 between the network device 106 and the source endpoint node 102, another network device 106, and/or the destination endpoint node 108. The communication circuitry 216 may be configured to use any one or more communication technology (e.g., wired or wireless communications) and associated protocols (e.g., Ethernet, Bluetooth®, Wi-Fi®, WiMAX, etc.) to effect such communication.
The illustrative communication circuitry 216 includes a network interface controller (NIC) 218, which may also be referred to as a host fabric interface (HFI). The NIC 218 may be embodied as one or more add-in-boards, daughtercards, network interface cards, controller chips, chipsets, or other devices that may be used by the network device 106 to connect the source endpoint node 102, the destination endpoint node 108, and/or another network device 106. In some embodiments, the NIC 218 may be embodied as part of a system-on-a-chip (SoC) that includes one or more processors, or included on a multichip package that also contains one or more processors. In some embodiments, the NIC 218 may include a local processor (not shown) and/or a local memory (not shown) that are both local to the NIC 218. In such embodiments, the local processor of the NIC 218 may be capable of performing one or more of the functions of the CPU 210 described herein. Additionally or alternatively, in such embodiments, the local memory of the NIC 218 may be integrated into one or more components of the network device 106 at the board level, socket level, chip level, and/or other levels.
The network device 106 may additionally include a data storage device 220, which may be embodied as any type of device or devices configured for short-term or long-term storage of data such as, for example, memory devices and circuits, memory cards, hard disk drives, solid-state drives, or other data storage devices. The data storage device 220 may include a system partition that stores data and firmware code for the network device 106. The data storage device 220 may also include an operating system partition that stores data files and executables for an operating system of the network device 106.
Additionally, the network device 106 may include a display 222. The display 222 may be embodied as, or otherwise use, any suitable display technology including, for example, a liquid crystal display (LCD), a light emitting diode (LED) display, a cathode ray tube (CRT) display, a plasma display, and/or other display usable in a compute device. The display may include a touchscreen sensor that uses any suitable touchscreen input technology to detect the user's tactile selection of information displayed on the display including, but not limited to, resistive touchscreen sensors, capacitive touchscreen sensors, surface acoustic wave (SAW) touchscreen sensors, infrared touchscreen sensors, optical imaging touchscreen sensors, acoustic touchscreen sensors, and/or other type of touchscreen sensors. Additionally or alternatively, the network device 106 may include one or more peripheral devices 224. Such peripheral devices 224 may include any type of peripheral device commonly found in a compute device such as speakers, a mouse, a keyboard, and/or other input/output devices, interface devices, and/or other peripheral devices. It should be appreciated that the network device 106 may include other components, sub-components and/or devices commonly found in a network device, which are not illustrated in
Referring now to
In the illustrative environment 300, the network device 106 also includes queue data 302, packet data 304, and credit data 306. The queue data 302 may be embodied as any data that is indicative of one or more queues that are managed by the queue element manager 330 (e.g., the HQM). The queue data 302, in the illustrative embodiment, as also includes data indicative of queue elements (e.g., packets) that are enqueued and/or dequeued from the one or more queues, queue status, and producer and consumer worker applications presently associated with each queue. The packet data 304 may be embodied as any data that is indicative of packet payloads, packet source and destination information, and packet metadata. The metadata defines properties of a packet, such as the packet size, an input port number, an output port number, and state data that is indicative of which worker applications have completed processing of the data packet and whether the data packet is ready for transmission to another device (e.g., to the destination endpoint node 108). In some embodiments, the metadata also includes data indicative of whether the packet is subject to multiplication or fragmentation during processing. The packet data 304, in the illustrative embodiment, also includes data indicative of the contents of the data packets received and operated on by the various worker applications assigned to the cores 230. As such, the packet data 304 includes headers, payload data, and/or other information initially included in a data packet and/or information added to or modified in the data packet as a result of processing by the worker applications. The credit data 306 may be embodied as any data usable to manage the credit status of the various worker applications executed by the cores 230 in the network device 106. For example, a worker application A may be represented in the credit data 306 as having a maximum possible number of credits, no credits, or a non-zero number of credits that is less than the maximum. The credit data 306, in the illustrative embodiment, also includes data indicative of maximum credit counts and/or a maximum credit weight assigned (e.g., in a packet multiplication scenario). The queue data 302, packet data 304, and credit data 306 may be accessed by the various components and/or sub-components of the network device 106.
The network communication manager 320, which may be embodied as hardware, firmware, software, virtualized hardware, emulated architecture, and/or a combination thereof as discussed above, is configured to facilitate inbound and outbound network communications (e.g., network traffic, network packets, network flows, etc.) to and from the network device 106, respectively. To do so, the network communication manager 320 is configured to receive and process data packets from one computing device (e.g., the source endpoint node 102, another network device 106, the destination endpoint node 108) and to prepare and send data packets to another computing device (e.g., the source endpoint node 102, another network device 106, the destination endpoint node 108). Accordingly, in some embodiments, at least a portion of the functionality of the network communication manager 320 may be performed by the communication circuitry 216, and, in the illustrative embodiment, by the NIC 218.
The queue element manager 330, which may be embodied as hardware, firmware, software, virtualized hardware, emulated architecture, and/or a combination thereof as discussed above, is configured to manage one or more packet queues in the memory 212 of the network device 106, assign the cores 230 of the CPU 210 to one or more worker applications for a packet, and manage concurrent access of the worker applications to the one or more queues. To do so, in the illustrative embodiment, the queue element manager 330 includes the queue manager interface 340 and the inflight count manager 350. Worker applications produce packets for enqueueing into a queue as other worker applications consume packets from the queue, with the queue manager interface 340 managing the enqueue and dequeue processes. The queue element manager 330 may be implemented by the queue manager logic unit 250 of
The inflight count manager 350, which may be embodied as hardware, firmware, software, virtualized hardware, emulated architecture, and/or a combination thereof as discussed above, is configured to limit the number of packets that are inflight across the various queues managed by the queue manager interface 340. To do so, the illustrative inflight count manager 350 includes an inflight limiter manager 352, an inflight count decrement control manager 354, and a packet multiplication manager 356. The inflight count decrement control manager 354, in the illustrative embodiment, is configured to perform a decrement control scheme as described in further detail with respect to
It should be appreciated that each of the inflight limiter manager 352, the inflight count decrement control manager 354, and the packet multiplication manager 356 may be separately embodied as hardware, firmware, software, virtualized hardware, emulated architecture, and/or a combination thereof. For example, the inflight limiter manager 352 may be embodied as a hardware component, while the inflight count decrement control manager 354 and the packet multiplication manager 356 are embodied as virtualized hardware components or as some other combination of hardware, firmware, software, virtualized hardware, emulated architecture, and/or a combination thereof.
Referring now to
CREDITS>MAX_INJ*MAX_CHILD+(AGENTS−1)*HWM Equation 1.
wherein CREDITS is the allocation of credits to a worker application, MAX_INJ is a limit on the number of packets that can be injected into the queue, MAX_CHILD is a limit on the number of child packets that can be spawned from a single packet, AGENTS is the number of worker applications (i.e., worker application agents) executed by the network device 106, and HWM is a high water mark level. In general, and as indicated by Equation 1, a worker application's credits are kept artificially higher than the number of packets inflight. This is done by controlling MAX_INJ as described below with respect to
The method 400 begins with block 402, in which the network device 106 determines whether to perform the inflight limiting scheme. In the illustrative embodiment, the network device 106 may determine to perform the inflight limiting scheme in response to determining that the queue manager logic unit 250 is present, in response to a determination that a setting stored in a configuration file in the data storage device 220 indicates to perform the inflight limiting scheme, and/or as a function of other criteria. Regardless, in response to a determination to perform the inflight limiting scheme, the method 400 advances to block 404 in which the network device 106 receives a packet from a worker application. As an example, an application A will produce a packet that is to be enqueued into a queue by the network device 106. In response to receipt of the queue element, the network device 106 determines whether an inflight packet count satisfies a threshold inflight limit, as indicated in block 406. More specifically, a threshold inflight limit is set for a number of data packets that may be inflight (e.g., being sent and received by one or more queues managed by the network device 106). For example, the threshold inflight limit may represent a maximum number of packets that can be enqueued, or a maximum number of packets that can be transacted across all worker applications, or a maximum number of packets that can be received from the cache during a given time period. The threshold inflight limit may also be represented as a minimum, a floor value, a ceiling value, a range, or any numerical formulation capable of serving as a comparison or threshold point for the number of packets being managed by the network device 106.
In block 408, the network device 106 determines the subsequent operations to perform as a function of whether the inflight count satisfies the threshold inflight limit. In determining whether the inflight count satisfies the threshold inflight limit, the network device 106 may determine whether the inflight count is less than the threshold inflight limit. If the inflight count does not satisfy the threshold inflight limit, the method returns to block 402, and the network device 106 again determines whether to perform the inflight limiting scheme. However, if the threshold inflight limit is satisfied, the method 400 advances to block 410, in which the network device 106 proceeds to enqueue the packet into a queue. In one embodiment, another worker application may consume the packet and perform operations on the packet. For example, in block 410, the network device 106 enqueues the packet into a worker application queue. From this worker application queue, another application B (e.g., “application B”) may consume the packet and process it. The method 400 subsequently proceeds to block 412 in which the network device 106 increments the inflight count. Afterwards, the method 400 returns to the block 402, in which the network device 106 determines whether to continue performing the inflight limiting scheme.
Referring now to
The method 500 begins at block 502, in which the network device 106 determines whether to perform the decrement control scheme. In the illustrative embodiment, the network device 106 may determine to perform the decrement control scheme in response to determining that the queue manager logic unit 250 is present, in response to a determination that a setting stored in a configuration file in the data storage device 220 indicates to perform the decrement control scheme, and/or as a function of other criteria. The method 500 advances to block 504, in which the network device 106 receives completion data from an application, referred to in the illustrative embodiment as application B. As used herein, completion data refers to any data produced by a worker application that indicates that the worker application has completed processing on a packet. In the illustrative embodiment, worker application B provides completion data to the network device 106. The completion data indicates that worker application B has completed processing on a packet that worker application B previously consumed from a queue managed by the network device 106. The method 500 then advances to block 506, in which the network device 106 determines whether the completion data includes a flag. The flag may be embodied as any data indicative of whether to decrement the inflight count and/or whether to indicate to the network device 106 that the packet is being released by worker application B, as described in greater detail with respect to
If it is determined in block 508 that the completion data includes a flag, the method 500 advances to block 510. In block 510, the network device 106 determines the type of flag within the completion data. In the illustrative embodiment, the flag may be a release flag or a no decrement flag as described in greater detail with respect to
Referring now to
Referring now to
Subsequently, the method 700 advances to block 706, in which the worker application determines whether the packet is subject to packet fragmentation. In the illustrative embodiment, the network device 106 adopts a pessimistic approach that presumes that every packet is subject to packet fragmentation. More specifically, in the illustrative embodiment, the worker application queries the packet data 304 to determine whether the packet is subject to packet fragmentation. As used herein, packet fragmentation refers to a property of a packet whereby, to process the packet, the packet is distributed into one or more sub-packets. In the illustrative embodiment, each sub-packet is counted as a single packet for purposes of credit management for the worker application. Accordingly, if the worker application completes processing on each sub-packet and enqueues each sub-packet into a queue managed by the network device 106, the worker application may need to spend credits for each sub-packet, rather than just for the single packet that it initially consumed from the queue. Excessive spending of credits due to packet multiplication may lead to the worker application running out of credits. To prevent this, the worker application determines whether the packet will be subject to packet multiplication before processing the packet further. In block 708, if the worker application determines that the packet is subject to packet multiplication, the method 700 advances to block 710. In block 710, the worker application determines a value for the maximum fragment count. As used herein, the maximum fragment count is a value set by the network device 106 to denote the maximum number of sub-packets into which a packet may be fragmented during the course of processing. In the illustrative embodiment, the network device 106 may be provided this value by an operator, may set the value based on prior instances of packet multiplication, may read the value from a configuration file, or may obtain the value from another source. The maximum fragment count may also be chosen based on known traffic and network conditions. Additionally, the network device 106 may be provided data regarding the largest possible packet that can be enqueued, based on, for example, the maximum transmission unit (MTU) size of an egress port for the network device 106.
The method 700 subsequently advances to block 714 in which the worker application enforces a maximum credit weight for the queue element. In the illustrative embodiment, and as indicated in block 716, the worker application sets the maximum credit weight equal to the maximum fragment count determined in block 710. Additionally, in the illustrative embodiment, the worker application assigns the maximum credit weight to the packet, as indicated in block 718. For example, the maximum fragment count may be set by the network device 106 to be 16. Accordingly, in the example, the maximum credit weight assigned to the packet by the worker application will be 16. In the illustrative embodiment, the worker application also registers or records packet fragmentation as the packet traverses through processing, as indicated in block 720. For example, the worker application may have one or more subsidiary worker agents that each operate on a fragment of the packet. Each time a worker agent fragments the packet for processing, the worker application records the instance of packet fragmentation. Additionally, in the illustrative embodiment, the worker application modifies the packet data to denote the packet fragmentation during processing, as indicated in block 722. Subsequently, the method 700 advances to block 724 of
Referring now to block 726 of
Illustrative examples of the technologies disclosed herein are provided below. An embodiment of the technologies may include any one or more, and any combination of, the examples described below.
Example 1 includes a network device to limit an inflight packet count, the network device comprising one or more processors that include a plurality of cores; a network interface controller coupled to the one or more processors; and one or more memory devices having stored therein a plurality of instructions that, when executed by the one or more processors, cause the network device to receive a packet from a producer application, wherein the packet is configured to be enqueued into a packet queue as a queue element to be consumed by a consumer application; increment, in response to receipt of the packet, an inflight count variable; determine whether a value of the inflight count variable satisfies an inflight count limit; and enqueue, in response to a determination that the value of the inflight count variable satisfies the inflight count limit, the packet into the packet queue.
Example 2 includes the subject matter of Example 1, and wherein to receive a packet from the producer application comprises to query a memory address at which the packet was stored by the producer application for retrieval by the network device.
Example 3 includes the subject matter of any of Examples 1 and 2, and wherein the plurality of instructions, when executed by the one or more processors, further cause the network device to decline, in response to a determination that the value of the inflight count variable does not satisfy the inflight count limit, to enqueue the packet as the queue element into a worker agent queue associated with the consumer application.
Example 4 includes the subject matter of any of Examples 1-3, and wherein the plurality of instructions, when executed by the one or more processors, further cause the network device to receive completion data from the consumer application, wherein the completion data is indicative of completion of processing of the packet by the consumer application.
Example 5 includes the subject matter of any of Examples 1-4, and wherein the plurality of network instructions, when executed by the one or more processors, further cause the network device to determine whether the completion data includes a no decrement flag.
Example 6 includes the subject matter of any of Examples 1-5, and wherein the plurality of instructions, when executed by the one or more processors, further cause the network device to decline, in response to a determination that the completion data includes the no decrement flag, to decrement the inflight count variable.
Example 7 includes the subject matter of any of Examples 1-6, and wherein the plurality of instructions, when executed by the one or more processors, further cause the network device to decrement, in response to receipt of a release command, the inflight count variable.
Example 8 includes the subject matter of any of Examples 1-7, and wherein the plurality of instructions, when executed by the one or more processors, cause the network device to execute the consumer application to consume the packet from the packet queue; and generate completion data indicative of completion of processing of the packet by the consumer application.
Example 9 includes the subject matter of any of Examples 1-8, and wherein the plurality of instructions, when executed by the one or more processors, cause the network device to execute the consumer application to detect whether the packet has fragmented into at least one sub-packet; determine, in response to a detection that the packet has fragmented into at least one sub-packet, a maximum fragment count; increment, in response to the detection that the packet has fragmented into at least one sub-packet, a fragment count; determine whether the fragment count satisfies the maximum fragment count; and provide, in response to a determination that the fragment count satisfies the maximum fragment count, completion data to the network device, wherein the completion data is indicative of completion of processing of the packet by the consumer application.
Example 10 includes the subject matter of any of Examples 1-9, and wherein to provide the completion data to the network device comprises to receive a release command indicative of a request to decrement the inflight count variable.
Example 11 includes a method for limiting an inflight packet count, the method comprising receiving, by a network device, a packet from a producer application, wherein the packet is configured to be enqueued into a packet queue as a queue element to be consumed by a consumer application; incrementing, by the network device and in response to receipt of the packet, an inflight count variable; determining, by the network device, whether a value of the inflight count variable satisfies an inflight count limit; and enqueuing, by the network device and in response to a determination that the value of the inflight count variable satisfies the inflight count limit, the packet into the packet queue.
Example 12 includes the subject matter of Example 11, and wherein receiving a packet from the producer application comprises querying a memory address at which the packet was stored by the producer application for retrieval by the network device.
Example 13 includes the subject matter of any of Examples 11 and 12, and further including declining, by the network device and in response to a determination that the value of the inflight count variable does not satisfy the inflight count limit, to enqueue the packet as the queue element into a worker agent queue associated with the consumer application.
Example 14 includes the subject matter of any of Examples 11-13, and further including receiving, by the network device, completion data from the consumer application, wherein the completion data is indicative of completion of processing of the packet by the consumer application.
Example 15 includes the subject matter of any of Examples 11-14, and further including determining, by the network device, whether the completion data includes a no decrement flag.
Example 16 includes the subject matter of any of Examples 11-15, and further including declining, by the network device and in response to a determination that the completion data includes the no decrement flag, to decrement the inflight count variable.
Example 17 includes the subject matter of any of Examples 11-16, and further including decrementing, by the network device and in response to receipt of a release command, the inflight count variable.
Example 18 includes the subject matter of any of Examples 11-17, and further including consuming, by the network device and with the consumer application, the packet from the packet queue; and generating, by the network device and with the consumer application, completion data indicative of completion of processing of the packet by the consumer application.
Example 19 includes the subject matter of any of Examples 11-18, and further including detecting, by the network device, whether the packet has fragmented into at least one sub-packet; determining, by the network device and in response to a detection that the packet has fragmented into at least one sub-packet, a maximum fragment count; incrementing, by the network device and in response to the detection that the packet has fragmented into at least one sub-packet, a fragment count; determining, by the network device, whether the fragment count satisfies the maximum fragment count; and generating, by the network device and in response to a determination that the fragment count satisfies the maximum fragment count, completion data indicative of completion of processing of the packet by the consumer application.
Example 20 includes the subject matter of any of Examples 11-19, and wherein generating the completion data comprises generating completion data that includes a no decrement flag indicative of a request to decline to decrement the inflight count variable.
Example 21 includes one or more machine-readable storage media comprising a plurality of instructions stored thereon that, in response to being executed, cause a network device to perform the method of any of Examples 11-20.
Example 22 includes a network device to limit an inflight packet count, the network device comprising one or more processors that include a plurality of cores; a network interface controller coupled to the one or more processors; and one or more memory devices having stored therein a plurality of instructions that, when executed, cause the network device to perform the method of any of Examples 11-20.
Example 23 includes a network device to limit an inflight packet count, the network device comprising means for performing the method of any of Examples 11-20.
Example 24 includes a network device to limit an inflight packet count, the network device comprising inflight count manager circuitry to receive a packet from a producer application, wherein the packet is configured to be enqueued into a packet queue as a queue element to be consumed by a consumer application, increment, in response to receipt of the packet, an inflight count variable, determine whether a value of the inflight count variable satisfies an inflight count limit, and enqueue, in response to a determination that the value of the inflight count variable satisfies the inflight count limit, the packet into the packet queue.
Example 25 includes the subject matter of Example 24, and wherein to receive a packet from the producer application comprises to query a memory address at which the packet was stored by the producer application for retrieval by the network device.
Example 26 includes the subject matter of any of Examples 24 and 25, and wherein the inflight count manager circuitry is to decline, in response to a determination that the value of the inflight count variable does not satisfy the inflight count limit, to enqueue the packet as the queue element into a worker agent queue associated with the consumer application.
Example 27 includes the subject matter of any of Examples 24-26, and wherein the inflight count manager circuitry is to receive completion data from the consumer application, wherein the completion data is indicative of completion of processing of the packet by the consumer application.
Example 28 includes the subject matter of any of Examples 24-27, and wherein the inflight count manager circuitry is to determine whether the completion data includes a no decrement flag.
Example 29 includes the subject matter of any of Examples 24-28, and wherein the inflight count manager circuitry is to decline, in response to a determination that the completion data includes the no decrement flag, to decrement the inflight count variable.
Example 30 includes the subject matter of any of Examples 24-29, and wherein the inflight count manager circuitry is to decrement, in response to receipt of a release command, the inflight count variable.
Example 31 includes the subject matter of any of Examples 24-30, and wherein the inflight count manager circuitry is to execute the consumer application to consume the packet from the packet queue; and generate completion data indicative of completion of processing of the packet by the consumer application.
Example 32 includes the subject matter of any of Examples 24-31, and wherein the inflight count manager circuitry is to execute the consumer application to detect whether the packet has fragmented into at least one sub-packet; determine, in response to a detection that the packet has fragmented into at least one sub-packet, a maximum fragment count; increment, in response to the detection that the packet has fragmented into at least one sub-packet, a fragment count; determine whether the fragment count satisfies the maximum fragment count; and provide, in response to a determination that the fragment count satisfies the maximum fragment count, completion data to the network device, wherein the completion data is indicative of completion of processing of the packet by the consumer application.
Example 33 includes the subject matter of any of Examples 24-32, and wherein to provide the completion data to the network device comprises to provide completion data that includes a no decrement flag indicative of a request to decline to decrement the inflight count variable.
Example 34 includes a network device to limit an inflight packet count, the network device comprising circuitry for receiving a packet from a producer application, wherein the packet is configured to be enqueued into a packet queue as a queue element to be consumed by a consumer application; means for incrementing, in response to receipt of the packet, an inflight count variable; means for determining whether a value of the inflight count variable satisfies an inflight count limit; and circuitry for enqueueing, in response to a determination that the value of the inflight count variable satisfies the inflight count limit, the packet into the packet queue.
Example 35 includes the subject matter of Example 34, and wherein the circuitry for receiving a packet from a producer application comprises circuitry for querying a memory address at which the packet was stored by the producer application for retrieval by the network device.
Example 36 includes the subject matter of any of Examples 34 and 35, and further including circuitry for declining, in response to a determination that the value of the inflight count variable does not satisfy the inflight count limit, to enqueue the packet as the queue element into a worker agent queue associated with the consumer application.
Example 37 includes the subject matter of any of Examples 34-36, and further including circuitry for receiving completion data from the consumer application, wherein the completion data is indicative of completion of processing of the packet by the consumer application.
Example 38 includes the subject matter of any of Examples 34-37, and further including circuitry for determining whether the completion data includes a no decrement flag.
Example 39 includes the subject matter of any of Examples 34-38, and further including circuitry for declining, in response to a determination that the completion data includes the no decrement flag, to decrement the inflight count variable.
Example 40 includes the subject matter of any of Examples 34-39, and further including circuitry for consuming the packet from the packet queue; and circuitry for generating completion data indicative of completion of processing of the packet by the consumer application.
Example 41 includes the subject matter of any of Examples 34-40, and further including circuitry for detecting whether the packet has fragmented into at least one sub-packet; circuitry for determining, in response to a detection that the packet has fragmented into at least one sub-packet, a maximum fragment count; circuitry for incrementing, in response to the detection that the packet has fragmented into at least one sub-packet, a fragment count; circuitry for determining whether the fragment count satisfies the maximum fragment count; and circuitry for providing, in response to a determination that the fragment count satisfies the maximum fragment count, completion data to the network device, wherein the completion data is indicative of completion of processing of the packet by the consumer application.
Example 42 includes the subject matter of any of Examples 34-41, and wherein the circuitry for providing the completion data to the network device comprises circuitry for receiving a release command indicative of a request to decrement the inflight count variable.
