System, device and method for implementing network packet templating

Abstract

Disclosed are systems, devices, and methods for performing network packet templating for communications initiated by a graphics processing unit (GPU). A central processing unit (CPU) creates a network packet according to a template and populates a first subset of fields of the network packet with static data. Next, the CPU stores the network packet in a memory. The GPU initiates execution of a kernel and detects a network communication request within the kernel before the kernel completes execution. In response to this determination, the GPU populates a second subset of fields of the network packet with runtime data. The GPU then generates a notification that the network packet is ready to be processed. A network interface controller (NIC) processes the network packet using data retrieved from the first subset of fields and from the second subset of fields in response to detecting the notification.

Description

Background Art

[0001] A general-purpose processor, such as a central processing unit (CPU), typically performs input / output (I / O) operations for software applications. In a system that includes multiple processors, the CPU may be the only processor that can generate network messages. In addition to general-purpose processors, the system may also include data-parallel processors. Data-parallel processors have a highly parallel execution architecture. Data-parallel processors may include graphics processing units (GPUs), digital signal processors (DSPs), and the like. Data-parallel processors can cause computational delays while waiting for the CPU to coordinate network communications on their behalf. In computing systems with CPUs and GPUs, the CPU is often referred to as a "host." In these systems, the GPU is a second-class citizen with respect to network operations. This limits the ability of the GPU to initiate network operations and requires the CPU to participate in any network operations initiated by the GPU. Using the host to generate network messages for the GPU may involve several back-to-back round trips from the GPU to the host and from the host to the network interface, resulting in reduced performance. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Advantages of the methods and mechanisms described herein may be better understood by referring to the following description in conjunction with the accompanying drawings, in which:

[0003] Figure 1 is a block diagram of one implementation of a computing system.

[0004] Figure 2 is a block diagram of another implementation of a computing system.

[0005] Figure 3 A timing diagram illustrating one implementation of offloading the network control path from the CPU to the GPU.

[0006] Figure 4 A diagram showing one implementation of a queue for storing network packet templates.

[0007] Figure 5 A diagram showing one implementation of a network packet template.

[0008] Figure 6 A diagram showing another implementation of a network packet template.

[0009] Figure 7 is a generalized flow chart illustrating one implementation of a method for creating and using network packet templates.

[0010] Figure 8 is a generalized flow chart illustrating one implementation of a method for determining when to add a network packet template to a queue.

[0011] Fig. 9 is a generalized flow chart illustrating another implementation of a method for determining when to add a network packet template to a queue. DETAILED DESCRIPTION

[0012] In the following description, numerous specific details are set forth to provide a thorough understanding of the methods and mechanisms presented herein. However, it will be appreciated by those of ordinary skill in the art that various implementations may be practiced without these specific details. In some cases, well-known structures, components, signals, computer program instructions, and techniques are not shown in detail to avoid confusion with the methods described herein. It should be understood that for simplicity and clarity of illustration, the elements shown in the drawings are not necessarily drawn to scale. For example, the size of some elements may be enlarged relative to other elements.

[0013] Various systems, devices, and methods for implementing network packet templating are disclosed herein. A first processor (e.g., a central processing unit (CPU)) creates a network packet according to a template and fills a first field subset of the network packet with static data. Next, the first processor stores the network packet in a memory. A second processor (e.g., a graphics processing unit (GPU)) initiates execution of a kernel and detects a network communication request before the kernel completes execution. In response to detecting the network communication request, the second processor fills a second field subset of the network packet with runtime data. Then, the second processor generates a notification that the network packet is ready to be processed. A network interface controller (NIC) processes the network packet using data retrieved from the first field subset and from the second field subset in response to detecting the notification.

[0014] In one implementation, a circular buffer is maintained in a memory accessible by the first and second processors. The circular buffer stores a plurality of network packets. In one implementation, the first processor periodically checks the state of the circular buffer, and if the number of existing network packets is below a threshold, the first processor adds one or more network packets to the circular buffer. When adding network packets to the circular buffer, the first processor fills a first field subset of each network packet added to the circular buffer. In one implementation, the first field subset includes a network control bit field and a memory access key field. In one implementation, the second field subset includes a source offset field, a destination offset field, and an operation type field.

[0015] Reference now Figure 1, a block diagram of an implementation of a computing system 100 is shown. In one implementation, the computing system 100 includes at least processors 105A to 105N, an input / output (I / O) interface 120, a bus 125, one or more memory controllers 130, a network interface controller (NIC) 135, and one or more memory devices 140. In other implementations, the computing system 100 includes other components and / or the computing system 100 is arranged in a different manner. Processors 105A to 105N represent any number of processors included in the system 100. In one implementation, the processor 105A is a general-purpose processor, such as a central processing unit (CPU). In one implementation, the processor 105N is a data parallel processor with a highly parallel architecture. Data parallel processors include graphics processing units (GPUs), digital signal processors (DSPs), field programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), and the like. In some implementations, the processors 105A to 105N include multiple data parallel processors.

[0016] One or more memory controllers 130 represent any number and type of memory controllers accessible by processors 105A to 105N and I / O devices (not shown) coupled to I / O interface 120. One or more memory controllers 130 are coupled to any number and type of one or more memory devices 140. One or more memory devices 140 represent any number and type of memory devices. For example, the types of memory in one or more memory devices 140 include dynamic random access memory (DRAM), static random access memory (SRAM), NAND flash memory, NOR flash memory, ferroelectric random access memory (FeRAM), etc. In one implementation, a given memory device 140 includes a circular buffer 150 for storing newly created network packets generated by the first processor 105A according to the network packet template. The first processor 105A fills each newly created network packet with static information. In one implementation, a given memory device 140 is local to the second processor 105N. When the second processor is ready to initiate a network transmission, the second processor 105N updates the network packet stored in the circular buffer 150 with the dynamic runtime information, and then the second processor 105N notifies the NIC 135 that the network packet is ready to be processed. The NIC 135 processes the network packet and performs the requested network communication on the network 145. As used herein, a network packet is a formatted data structure having a plurality of fields, wherein the data structure is created by the first processor 105A and updated by the second processor 105B. In other words, the network packet is a formatted data structure having a first subset of fields written by the first processor 105A and a second subset of fields written and / or updated by the second processor 105N.

[0017] The I / O interface 120 represents any number and type of I / O interfaces (e.g., a peripheral component interconnect (PCI) bus, a PCI extension (PCI-X), a PCIE (PCI Express) bus, a Gigabit Ethernet (GBE) bus, a universal serial bus (USB)). Various types of peripheral devices (not shown) are coupled to the I / O interface 120. Such peripheral devices include (but are not limited to) a display, a keyboard, a mouse, a printer, a scanner, a joystick or other type of game controller, a media recording device, an external storage device, a network interface card, etc. The network interface controller (NIC) 135 receives and sends network messages across the network 145. In one implementation, a given processor 105N generates a request for the NIC 135 to process a network packet. In one implementation, the NIC 135 processes the request generated by the processor 105N without involving the processor 105A. In this implementation, the processor 105A is a CPU and the processor 105N is a GPU. In other implementations, other types of processors are capable of performing these actions.

[0018] The network 145 represents any type of network or combination of networks, including wireless connections, direct local area networks (LANs), metropolitan area networks (MANs), wide area networks (WANs), intranets, the Internet, wired networks, packet switching networks, fiber optic networks, routers, storage area networks, or other types of networks. Examples of LANs include Ethernet networks, fiber distributed data interface (FDDI) networks, and token ring networks. In various implementations, the network 145 also includes remote direct memory access (RDMA) hardware and / or software, transmission control protocol / Internet protocol (TCP / IP) hardware and / or software, routers, repeaters, switches, power grids, and / or other components.

[0019] In various implementations, computing system 100 is any of a computer, a laptop, a mobile device, a game console, a server, a streaming device, a wearable device, or various other types of computing systems or devices. It should be noted that the number of components of computing system 100 varies from implementation to implementation. For example, in other implementations, there are Figure 1 It should also be noted that in other implementations, the computing system 100 includes Figure 1 In addition, in other implementations, the computing system 100 is configured to Figure 1 The different ways of structuring are shown in .

[0020] Now go to Figure 2, a block diagram of another implementation of a computing system 200 is shown. In one implementation, the system 200 includes a GPU 205, a system memory 225, and a local memory 230. The system 200 also includes other components that are not shown to avoid obscuring the drawing. The GPU 205 includes at least a command processor 235, a dispatch unit 250, computation units 255A to 255N, a memory controller 220, a global data sharing 270, a level 1 (L1) cache 265, and a level 2 (L2) cache 260. In other implementations, even if Figure 2 Although only one instance is shown and / or only one instance is organized in other suitable ways, GPU 205 may also include other components, omit one or more of the components shown, or have multiple instances of a component.

[0021] In various implementations, the computing system 200 executes any of a variety of types of software applications. In one implementation, as part of executing a given software application, a host CPU (not shown) of the computing system 200 launches a kernel to be executed on the GPU 205. As used herein, the term "kernel" or "compute kernel" is defined as a function or task that includes executable instructions that are launched and executed as one or more threads on one or more compute units. The command processor 235 receives the kernel from the host CPU and issues the kernel to the dispatch unit 250 for dispatch to the compute units 255A to 255N. The threads within the kernel executing on the compute units 255A to 255N initiate network communications by updating the network packets stored in the circular buffer 240 with runtime information and then notifying the NIC (not shown). The NIC processes the given network packet in response to receiving the corresponding notification. Although Figure 2 Not shown, but in one implementation, the computing units 255A-255N also include one or more caches and / or local memories within each computing unit 255A-255N.

[0022] Now go to Figure 3, a timing diagram 300 of one implementation of offloading a network control path from a CPU to a GPU is shown. In one implementation, a CPU 320 launches a kernel 335 on a GPU 325, and then the GPU 325 executes the kernel 335 independently of the CPU 320. While the GPU 325 executes the kernel 335, the CPU 320 is able to perform other tasks. In some implementations, the CPU 320 is coupled to other GPUs, and the CPU 320 is able to launch kernels on the other GPUs that execute in parallel with the kernel 335 on the GPU 325. The CPU 320 generates network packets according to the template and fills in a portion of the fields of each network packet. The CPU 320 then stores each network packet in a location accessible to the GPU 325 and the NIC 315. The CPU 320 generates network packets in advance without waiting for an explicit request from the GPU 325.

[0023] During the execution of kernel 335 and without waiting for kernel 335 to complete, GPU 325 fills in the rest of the fields for a given network packet, and then GPU 325 sends the network packet request to network interface controller (NIC) 315, as shown in send block 340. It should be noted that GPU 325 sends this network request to NIC 315 without any involvement of CPU 320. NIC 315 processes the network packet request and places the request on the network while kernel 335 continues to execute, as shown in place block 345. Although Figure 3 315, but it should be noted that the kernel 335 is capable of sending multiple network packet requests to the NIC 315, which are processed by the NIC 315 during the execution of the kernel 335. At a later point in time, the execution of the kernel 335 is completed, which is represented by the completion box 350.

[0024] Now go to Figure 4 , a diagram of one implementation of a queue 400 for storing network packets is shown. In one implementation, the queue 400 is a circular queue, where operations are performed based on a first in first out (FIFO) principle, and the last position is connected back to the first position to form a circle. It should be noted that a "circular queue" is also referred to as a "circular buffer" in this article. In other implementations, any of a variety of other types of data structures are used to implement the queue 400. In one implementation, the queue 400 is used by a computing system including a CPU, a GPU, and a NIC.

[0025] In one implementation, CPU 415 adds network packets to queue 400, wherein each network packet is generated according to a network packet template. As used herein, "network packet template" is defined as the structure of a communication packet created by a first processor, but has one or more empty fields to be filled and / or updated by a second processor. In other words, "network packet template" defines the structure of a communication packet, but at least a portion of the content of the communication packet will be filled by a second processor. Typically, CPU 415 will fill a portion of the field of the network packet with static information (e.g., network control bits, memory access keys (Rkey)) before storing the packet at an available slot in queue 400. After the second processor writes a second field subset to the network packet, a notification is transmitted to NIC 420 to process the network packet. In other words, once the second processor has completed the filling of all fields and has generated a notification for NIC 420, the network packet is ready. In one implementation, the second processor notifies NIC 420 that the network packet is ready by writing a notification to a doorbell register. In other implementations, the second processor transmits the notification to NIC 420 using other techniques.

[0026] In one implementation, the CPU 415 periodically adds newly created network packets to the queue 400. For example, the CPU 415 periodically checks the status of the queue 400. In one implementation, each queue entry includes a valid indicator to indicate whether the queue entry stores a valid network packet. It should be noted that a "queue entry" is also referred to as a "queue slot" in this article. In one implementation, if there are any unused (i.e., available) slots in the queue 400, as indicated by the valid indicator, the CPU 415 adds one or more network packets to these empty entries of the queue 400. In another implementation, if the number of network packets currently stored in the queue 400 is less than a threshold, the CPU 415 adds one or more network packets to the available slots of the queue 400. In various implementations, based on the number of available slots, the number of 415 network packets added to the queue 400 by the CPU 415 is fixed, programmable, or determined in other suitable ways.

[0027] In one implementation, the NIC 420 maintains a pointer to the next position in the queue 400 to be processed. After the NIC 420 receives the notification and processes the network packet, the NIC 420 increments the pointer to point to the next position in the queue. Similarly, the GPU 425 maintains a pointer to a position in the queue 400 that stores the network packet ready to be modified and then processed by the NIC 420. In one implementation, the pointer maintained by the GPU 425 is offset by one queue element from the pointer maintained by the NIC 420. Similarly, in one implementation, the CPU 415 maintains a pointer to an available position in the queue 400 for storing a newly created network packet.

[0028] In one implementation, CPU 415 queries the entries of queue 400 to determine whether there are any entries available for storing the newly created network packet. In one implementation, if CPU 415 detects an available entry in queue 400, CPU 415 generates a new network packet and stores the network packet in the available entry. In another implementation, if CPU 415 detects an available entry in queue 400 and satisfies a first condition, CPU 415 generates a new network packet and stores the network packet in the available entry. In one implementation, the first condition is that queue 400 has less than a threshold number of network packets ready to be used by GPU 425. In other implementations, the first condition is any of various other types of conditions. In various implementations, CPU 415 creates a network packet in advance and outside the critical path. In this way, when GPU 425 needs to generate a network packet, GPU 425 accesses the network packet stored on queue 400 in real time, and sets the network packet for NIC 420 to use immediately without any participation of CPU 415.

[0029] Reference now Figure 5 , a diagram of one implementation of a network packet template 505 is shown. In various implementations, a network packet template as described herein includes a plurality of indicators and / or fields having various static and runtime information. For example, in one implementation, the network packet template 505 includes a valid indicator 510, a packet ready indicator 515, and a plurality of fields 520A to 520N. In other implementations, the network packet template 505 includes other numbers and / or types of indicators and fields and / or the network packet template 505 is structured in other suitable ways.

[0030] In one implementation, the valid indicator 510 indicates whether the entry stores a valid network packet. A valid network packet is a packet that has been created and initialized by a first processor (e.g., a CPU) and is ready to be updated by a second processor (e.g., a GPU, a processing in memory (PIM) device). In one implementation, the packet ready indicator 515 specifies when the entry stores a network packet that is ready to be processed by the NIC. In various implementations, fields 520A to 520N store any of various network communication settings. In one implementation, when creating a network packet according to the network packet template 505, the first processor programs the first field subset 520A to 520N, and when the second processor needs to initiate a network transmission, the second field subset 520A to 520N is programmed in real time.

[0031] Now go to Figure 6 , a diagram showing another implementation of a network packet template 605. In one implementation, the network packet template 605 includes a valid indicator 610 and a packet ready indicator 615. The network packet template 605 also includes a network control bit 620 and a memory access key 625. In one implementation, when a network packet is created according to the template 605 and stored in a queue (e.g., a memory accessible by a second processor (e.g., a GPU), Figure 4 400), the first processor (e.g., CPU) fills in the fields for network control bits 620 and memory access key 625. Although not shown, in other implementations, network packet template 605 also includes one or more other fields that are filled in by the first processor when creating and storing network packets in the queue.

[0032] The network packet template 605 also includes various fields that are dynamically populated with runtime information by the second processor. For example, in one implementation, the network packet template 605 includes a source offset 630, a destination offset 635, and an operation type 640 that are populated with runtime information by the second processor. The source offset 630 specifies where in the source buffer or source memory device the data transfer begins. The destination offset 635 specifies where in the destination buffer or destination memory device the transferred data is stored. The operation type 640 specifies the type of operation to be performed (e.g., read, write, atomic). It should be noted that in other implementations, the network packet template 605 includes other numbers and types of fields that are dynamically populated with runtime information by the second processor. Moreover, in further implementations, the network packet template 605 is structured in other suitable ways.

[0033] Reference now Figure 7, shows one implementation of a method 700 for creating and using a network packet template. For discussion purposes, the steps and steps in this implementation are shown in sequential order. Figure 8 However, it should be noted that in various implementations of the described method, one or more of the described elements are performed simultaneously, in a different order than shown, or omitted entirely. Other additional elements may also be performed as needed. Any of the various systems or devices described herein is configured to implement method 700.

[0034] The first processor creates a network packet according to the template and fills a first field subset of the network packet (box 705). In one implementation, the first processor is a CPU. The first processor stores the network packet in a location accessible by the second processor (box 710). In one implementation, the first processor performs steps 705 and 710 without receiving an explicit request for the network packet template from the second processor. This allows steps 705 and 710 to be executed in advance and outside the critical path. In one implementation, a ready flag is not set for the network packet stored by the first processor to indicate that the network packet is not yet ready to be processed by the NIC. Not setting the ready flag also indicates that the second processor still needs to add more data to the network packet before the network packet is ready.

[0035] Furthermore, the first processor launches the kernel on the second processor (block 715). In one implementation, the second processor is a GPU. It should be noted that step 715 is sometimes performed in parallel with steps 705 and 710, or performed before steps 705 and 710. Next, during kernel execution, the second processor populates a second subset of fields of the network packet in response to a network communication request detected by the kernel (block 720). The second processor then notifies the NIC that the network packet is ready to be processed (block 725). Next, the NIC processes the network packet using the data retrieved from the first subset of fields and from the second subset of fields (block 730). After block 730, method 700 ends.

[0036] Now go to Figure 8, shows an implementation of a method 800 for determining when to add a network packet template to a queue. A first processor monitors the state of a queue storing network packets (box 805). If a first condition for the queue is detected (conditional box 810, "yes" branch), the first processor creates one or more network packets and adds them to the queue (box 815). In one implementation, the first condition is that the occupancy level of the queue is below a threshold, where the occupancy level is specified as the number of valid network packets stored in the queue and ready to be filled by the second processor. In one implementation, the threshold is programmed by a second processor, which updates the network packets stored in the queue. In this implementation, the second processor adjusts the threshold based on the state of the kernel currently being executed by the second processor. For example, in one implementation, if the second processor executes a kernel that is generating a relatively large number of network requests, the second processor dynamically lowers the threshold to ensure that the first processor retains a large number of network packets on the queue. In other implementations, the second processor adjusts the threshold based on one or more other factors.

[0037] In another implementation, the first condition is that the queue has one or more available slots for storing network packets. In other implementations, the first condition is any of various other types of conditions. If the first condition for the queue is not detected (conditional block 810, "no" branch), the first processor waits for a programmable amount of time before checking the state of the queue again (block 820). In one implementation, the programmable amount of time is determined by the second processor based on one or more factors associated with the currently executing kernel. After block 820, method 800 returns to block 805.

[0038] Reference now Fig. 9 , another implementation of a method 900 for determining when to add a network packet template to a queue is shown. In a system having a first processor (e.g., a CPU) and a second processor (e.g., a GPU), the second processor monitors the state of a queue storing network packets (block 905). If a first condition for the queue is detected (conditional block 910, "yes" branch), the second processor generates an interrupt for the first processor to create one or more network packets and add them to the queue (block 915). In response to receiving the interrupt, the first processor creates one or more network packets and adds them to the queue (block 920).

[0039] In one implementation, the first condition is that the occupancy level of the queue is below a threshold, wherein the occupancy level is specified as the number of valid network packets stored in the queue and ready to be filled with one or more fields by the second processor. In another implementation, the first condition is that the queue has one or more available slots for storing network packets. In other implementations, the first condition is any of various other types of conditions. If the first condition for the queue is not detected (conditional box 910, "no" branch), the second processor waits for a programmable amount of time (box 925) before checking the state of the queue again. After box 925, method 900 returns to box 905.

[0040] In various implementations, the method and / or mechanism described herein is implemented using program instructions of a software application. For example, program instructions that can be executed by a general or special processor are contemplated. In various implementations, such program instructions are represented by a high-level programming language. In other implementations, program instructions are compiled from a high-level programming language into a binary form, an intermediate form, or other forms. Alternatively, program instructions describing the behavior or design of hardware are written. Such program instructions are represented by a high-level programming language such as C. Alternatively, a hardware design language (HDL) such as Verilog is used. In various implementations, program instructions are stored on any of a variety of non-temporary computer-readable storage media. During use, a computing system can access a storage medium to provide program instructions to a computing system for program execution. Generally speaking, such a computing system includes at least one or more memories and one or more processors configured to execute program instructions.

[0041] It should be emphasized that the above implementations are only non-limiting examples of implementations. Once the above disclosure is fully understood, many changes and modifications will become apparent to those skilled in the art. The following claims are intended to be interpreted as including all such changes and modifications.

Claims

1. A system for implementing network packet templating, comprising: Memory; A first processor, wherein the first processor is configured to: Creating a network packet according to the template and populating a first subset of fields of the network packet; as well as storing the network packets in the memory; A second processor, wherein the second processor is configured to: Initiate kernel execution; In response to detecting a network communication request within the kernel and before the kernel completes execution: populating a second subset of fields of the network packet; as well as generating a notification that the network packet is ready to be processed; A network interface controller is configured to process the network packet in response to detecting the notification before the kernel completes execution.

2. The system of claim 1, wherein the network interface controller processes the network packet using data retrieved from the first subset of fields and from the second subset of fields.

3. The system of claim 1, wherein the first subset of fields includes static data, and wherein the second subset of fields includes runtime data.

4. The system of claim 1, wherein the first subset of fields includes a network control bit field and a memory access key field, and wherein the second subset of fields includes a source offset field, a destination offset field, and an operation type field.

5. The system of claim 1, wherein the first processor is configured to create the network packet and populate the first subset of fields of the network packet before the second processor detects the network communication request.

6. The system of claim 1, wherein the first processor is configured to create the network packet according to a template and store the network packet in a queue only in response to detecting a first condition.

7. The system of claim 6, wherein the first condition is that an occupancy level of the queue is below a threshold.

8. A method for implementing network packet templating, comprising: Creating, by a first processor, a network packet according to the template and filling a first field subset of the network packet; storing, by the first processor, the network packet in a memory; Initiating execution of the kernel on the second processor; In response to detecting a network communication request within the kernel and before the kernel completes execution: populating, by the second processor, a second subset of fields of the network packet; generating, by the second processor, a notification that a network packet is ready to be processed; as well as The network packet is processed by a network interface controller in response to detecting the notification and before the kernel completes execution on the second processor.

9. The method of claim 8, further comprising: The network packet is processed using data retrieved from the first subset of fields and from the second subset of fields.

10. The method of claim 8, wherein the first subset of fields includes static data, and wherein the second subset of fields includes runtime data.

11. The method of claim 8, wherein the first subset of fields includes a network control bit field and a memory access key field, and wherein the second subset of fields includes a source offset field, a destination offset field, and an operation type field.

12. The method of claim 8, further comprising: The network packet is created by the first processor and the first subset of fields of the network packet is populated before the second processor detects the network communication request.

13. The method of claim 8, further comprising: The network packet is created by the first processor according to a template and stored on a queue only in response to detecting a first condition. The method of claim 13 , wherein the first condition is that an occupancy level of the queue is below a threshold.

15. A processor for implementing network packet templating, comprising: Memory; as well as Multiple computing units; The processor is configured to: initiating execution of the kernel on one or more of the plurality of computing units; In response to detecting a network communication request within the kernel and before the kernel completes execution: locating within the memory a network packet having only a first subset of fields populated; populating a second subset of fields of the network packet; and Generates notification that a network packet is ready to be processed.

16. The processor of claim 15, wherein the first subset of fields comprises static data, and wherein the second subset of fields comprises runtime data.

17. The processor of claim 15, wherein the first subset of fields includes a network control bit field and a memory access key field, and wherein the second subset of fields includes a source offset field, a destination offset field, and an operation type field.

18. The processor of claim 15, wherein a first subset of fields of the network packet is populated before the processor detects the network communication request.

19. The processor of claim 15, wherein the processor is further configured to program a threshold for determining when to add a network packet populated with the first subset of fields to a queue.

20. The processor of claim 15, wherein the processor is further configured to communicate the notification to a network interface controller to cause the network packet to be processed.

Images