Patent Grant
11606302
This application is related to the subject matter of U.S. Provisional Patent Application Ser. No. 63/038,473 filed on Jun. 12, 2020 and entitled “Methods and Apparatus for Cross-Layer Transport Awareness,” which is incorporated herein by reference in its entirety.
This following applications are incorporated by reference: U.S. patent application Ser. No. 16/144,992 filed Sep. 27, 2018, now pending, and entitled “Methods and Apparatus for Single Entity Buffer Pool Management”, U.S. patent application Ser. No. 16/146,533 filed Sep. 28, 2018, now pending, and entitled “Methods and Apparatus for Regulating Networking Traffic in Bursty System Conditions”, U.S. patent application Ser. No. 16/146,324 filed Sep. 28, 2018, now U.S. Pat. No. 10,978,224 and entitled “Methods and Apparatus for Preventing Packet Spoofing with User Space Communication Stacks”, U.S. patent application Ser. No. 16/146,916 filed Sep. 28, 2018, now U.S. Pat. No. 10,819,831 and entitled “Methods and Apparatus for Channel Defunct Within User Space Stack Architectures”, U.S. patent application Ser. No. 16/236,032 filed Dec. 28, 2018, now pending and entitled “Methods and Apparatus for Classification of Flow Metadata with User Space Communication Stacks”, U.S. patent application Ser. No. 16/363,495 filed Mar. 25, 2019, now pending and entitled “Methods and Apparatus for Dynamic Packet Pool Configuration in Networking Stack Infrastructures”, U.S. patent application Ser. No. 16/365,462 filed on Mar. 26, 2019, now pending and entitled “Methods and Apparatus for Sharing and Arbitration of Host Stack Information with User Space Communication Stacks”, U.S. patent application Ser. No. 16/368,338, now pending, filed on Mar. 28, 2019 and entitled “Methods and Apparatus for Memory Allocation and Reallocation in Networking Stack Infrastructures”, U.S. patent application Ser. No. 16/365,484, filed on Mar. 26, 2019, now pending and entitled “Methods and Apparatus for Virtualized Hardware Optimizations for User Space Networking”, U.S. patent application Ser. No. 16/368,368 filed on Mar. 28, 2019, now pending, and entitled “Methods and Apparatus for Active Queue Management in User Space Networking”, and U.S. patent application Ser. No. 16/368,214 filed on Mar. 28, 2019, now pending and entitled “Methods and Apparatus for Self-Tuning Operation with User Space Stack Architectures”, U.S. Provisional Patent Application Ser. No. 62/906,617 filed Sep. 26, 2019 and entitled “Methods and Apparatus for Low Latency Operation in User Space Networking”, U.S. Provisional Patent Application Ser. No. 62/906,645 filed Sep. 26, 2019 and entitled “Methods and Apparatus for Emerging Use Case Support in User Space Networking”, and U.S. Provisional Patent Application Ser. No. 62/906,657 filed Sep. 26, 2019 and entitled “Methods and Apparatus for Device Driver Operation in Non-Kernel Space”, the contents of the foregoing being incorporated herein by reference in their entireties.
A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever.
The disclosure relates generally to the field of electronic devices, as well as networks thereof. More particularly, the disclosure is directed to methods and apparatus for implementing computerized networking stack infrastructures.
The consumer electronics industry has seen explosive growth in network connectivity; for example, Internet connectivity is now virtually ubiquitous across many different device types for a variety of different applications and functionalities. The successful implementation of network connectivity over a myriad of different usage cases has been enabled by, inter alia, the principles of modular design and abstraction. Specifically, the traditional network communication paradigm incorporates multiple (generally) modular software “layers” into a “communication stack.” Each layer of the communication stack separately manages its own implementation specific considerations and provides an “abstracted” communication interface to the next layer. In this manner, different applications can communicate freely across different devices without considering the underlying network transport.
Kernel space processing overhead is a function of packet volume within existing communication stacks. Specifically, each layer of the communication stack processes packets one-at-a-time, with little to no shared knowledge between layers. Unfortunately, modern user applications consume a tremendous number of data packets, and the trend in consumer data usage will only continue to increase. Furthermore, processing and memory speeds appear to be asymptotically approaching the theoretical limitations of existing semiconductor manufacturing. Thus, the confluence of these factors (increasing overhead, aggressive consumer expectations, and diminishing improvements in semiconductor manufacturing) present significant design challenges for consumer electronics.
The present disclosure satisfies the foregoing needs by providing, inter alia, methods and apparatus for flow-based batching and processing.
In one aspect, methods and apparatus for providing in-kernel flow control based on flow-batched data structures are disclosed. A method for managing a user space protocol stack can comprise receiving, by a nexus in a kernel space, a packet from a packet pool, wherein the packet is associated with one or more flows, wherein the one or more flows are individually identified by corresponding one or more flow keys; extracting information from the packet to generate a flow key of the packet indicating a particular flow for the packet; looking up the flow key in a flow table to determine whether there is an existing flow key stored in the flow table matching the flow key of the packet; storing, responsive to the existing flow key matching the flow key of the packet, the packet into a batch of packets of the existing flow, wherein the batch of packets of the existing flow are stored in a flow-batched data structure; and releasing, responsive to a release condition being met, the batch of packets of the existing flow to a user space protocol stack within a user space application through a channel communicatively coupled to the nexus and the user space protocol stack
In one aspect, a non-transitory computer readable storage apparatus implementing one or more of the aspects disclosed herein is disclosed and described. A non-transitory computer readable medium comprising computer programs stored thereon, when executed by a processor, can cause a computerized apparatus to receive, by a nexus in a kernel space, a packet from a packet pool, wherein the packet is associated with one or more flows, wherein the one or more flows are individually identified by corresponding one or more flow keys; extract information from the packet to generate a flow key of the packet indicating a particular flow for the packet; look up the flow key in a flow table to determine whether there is an existing flow key stored in the flow table matching the flow key of the packet; store, responsive to the existing flow key matching the flow key of the packet, the packet into a batch of packets of the existing flow, wherein the batch of packets of the existing flow are stored in a flow-batched data structure; and release, responsive to a release condition being met, the batch of packets of the existing flow to a user space protocol stack within a user space application through a channel communicatively coupled to the nexus and the user space protocol stack.
In one aspect, methods and apparatus for providing in-kernel flow control based on flow-batched data structures are disclosed. A system configured for managing packet flows, can include a storage device to store a flow table; and a processor coupled to the storage device, and configured to operate a nexus in a kernel. The nexus is configured to receive a packet from a packet pool, wherein the packet is associated with one or more flows, wherein the one or more flows are individually identified by corresponding one or more flow keys; extract information from the packet to generate a flow key of the packet indicating a particular flow for the packet; look up the flow key in the flow table in the storage to determine whether there is an existing flow key stored in the flow table matching the flow key of the packet; store, responsive to the existing flow key matching the flow key of the packet, the packet into a batch of packets of the existing flow, wherein the batch of packets of the existing flow are stored in a flow-batched data structure; and release, responsive to a release condition being met, the batch of packets of the existing flow to a user space protocol stack within a user space application through a channel communicatively coupled to the nexus and the user space protocol stack.
In one aspect, methods and apparatus for representing multiple packet data structures according to natural memory boundaries of an operating system are disclosed.
In another aspect, computerized apparatus implementing one or more of the foregoing methods and/or apparatus are disclosed. In one embodiment, the computerized apparatus comprises a personal computer, such as a desktop computer.
In another aspect, the computerized apparatus comprises a mobile device such as a smartphone or tablet computer, or laptop computer.
In yet another aspect, the computerized apparatus comprises a server or server blade.
In still another aspect, the computerized apparatus comprises a GPU-based architecture optimized for deep learning or machine-learning.
In still another aspect, the computerized apparatus comprises a media player or rendering device, such as a portable player.
In still another aspect, the computerized apparatus comprises a host server or similar device, with hypervisor and configured to support multiple “guest” virtual machines (VMs) and/or containerized applications.
In another aspect, an integrated circuit (IC) device implementing one or more of the foregoing aspects is disclosed and described. In one embodiment, the IC device is embodied as a SoC (system on Chip) device. In another embodiment, an ASIC (application specific IC) is used as the basis of the device. In yet another embodiment, a chip set (i.e., multiple ICs used in coordinated fashion) is disclosed. In yet another embodiment, the device comprises a multi-logic block FPGA device. In a further embodiment, the IC device is a modem or modem chipset. In another embodiment, the IC device comprises a multi-core processor architecture.
In another aspect, a computer readable storage apparatus implementing one or more of the foregoing aspects is disclosed and described. In one embodiment, the computer readable apparatus comprises a program memory, or an EEPROM. In another embodiment, the apparatus includes a solid state drive (SSD) or other mass storage device. In another embodiment, the apparatus comprises a USB or other “flash drive” or other such portable removable storage device. In yet another embodiment, the apparatus comprises a “cloud” (network) based storage device which is remote from yet accessible via a computerized user or client electronic device. As another embodiment, the storage device is part of a server “farm” or “big data” compute environment.
In yet another aspect, an operating system (OS) is disclosed. In one embodiment, the OS includes a user space and kernel space. In another embodiment, the OS is open-source (e.g., Linux)-based. In another embodiment, the OS is non-open (e.g., proprietary) based.
Other features and advantages of the present disclosure will immediately be recognized by persons of ordinary skill in the art with reference to the attached drawings and detailed description of exemplary embodiments as given below.
All figures ©Copyright 2017-2021 Apple Inc. All rights reserved.
Reference is now made to the drawings, wherein like numerals refer to like parts throughout.
As shown in
As a brief aside, user space is a portion of system memory that a processor executes user processes from. User space is relatively freely and dynamically allocated for application software and a few device drivers. The kernel space is a portion of memory that a processor executes the kernel from. Kernel space is strictly reserved (usually during the processor boot sequence) for running privileged operating system (O/S) processes, extensions, and most device drivers. For example, each user space process normally runs in a specific memory space (its own “sandbox”) and cannot access the memory of other processes unless explicitly allowed. In contrast, the kernel is the core of a computer's operating system; the kernel can exert complete control over all other processes in the system.
The term “operating system” may refer to software that controls and manages access to hardware. An O/S commonly supports processing functions such as e.g., task scheduling, application execution, input and output management, memory management, security, and peripheral access. As used herein, the term “application” refers to software that can interact with the hardware only via procedures and interfaces offered by the O/S.
The term “privilege” may refer to any access restriction or permission which restricts or permits processor execution. System privileges are commonly used within the computing arts to, inter alia, mitigate the potential damage of a computer security vulnerability. For instance, a properly privileged computer system will prevent malicious software applications from affecting data and task execution associated with other applications and the kernel.
As used herein, the term “in-kernel” and/or “kernel space” may refer to data and/or processes that are stored in, and/or have privilege to access the kernel space memory allocations. In contrast, the terms “non-kernel” and/or “user space” refers to data and/or processes that are not privileged to access the kernel space memory allocations. In particular, user space represents the address space specific to the user process, whereas non-kernel space represents address space which is not in-kernel, but which may or may not be specific to user processes.
As previously noted, the illustrated socket 102 provides access to Transmission Control Protocol (TCP) 104, User Datagram Protocol (UDP) 106, and Inter-Processor Communication (IPC) 108. TCP, UDP, and IPC are various suites of transmission protocols each offering different capabilities and/or functionalities. For example, UDP is a minimal message-oriented encapsulation protocol that provides no guarantees to the upper layer protocol for message delivery and the UDP layer retains no state of UDP messages once sent. UDP is commonly used for real-time, interactive applications (e.g., video chat, voice over IP (VoIP) where loss of packets is acceptable. In contrast, TCP provides reliable, ordered, and error-checked delivery of data via a retransmission and acknowledgement scheme; TCP is generally used for file transfers where packet loss is unacceptable, and transmission latency is flexible.
As used herein, the term “encapsulation protocol” may refer to modular communication protocols in which logically separate functions in the network are abstracted from their underlying structures by inclusion or information hiding within higher level objects. For example, in one exemplary embodiment, UDP provides extra information (ports numbering).
As used herein, the term “transport protocol” may refer to communication protocols that transport data between logical endpoints. A transport protocol may include encapsulation protocol functionality.
Both TCP and UDP are commonly layered over an Internet Protocol (IP) 110 for transmission. IP is a connectionless protocol for use on packet-switched networks that provides a “best effort delivery”. Best effort delivery does not guarantee delivery, nor does it assure proper sequencing or avoidance of duplicate delivery. Generally these aspects are addressed by TCP or another transport protocol based on UDP.
As a brief aside, consider a web browser that opens a webpage; the web browser application would generally open a number of network sockets to download and/or interact with the various digital assets of the webpage (e.g., for a relatively common place webpage, this could entail instantiating ˜300 sockets). The web browser can write (or read) data to the socket; thereafter, the socket object executes system calls within kernel space to copy (or fetch) data to data structures in the kernel space.
As used herein, the term “domain” may refer to a self-contained memory allocation e.g., user space, kernel space. A “domain crossing” may refer to a transaction, event, or process that “crosses” from one domain to another domain. For example, writing to a network socket from the user space to the kernel space constitutes a domain crossing access.
In the context of a Berkeley Software Distribution (BSD) based networking implementation, data that is transacted within the kernel space is stored in memory buffers that are also commonly referred to as “mbufs”. Each mbuf is a fixed size memory buffer that is used generically for transfers (mbufs are used regardless of the calling process e.g., TCP, UDP, etc.). Arbitrarily sized data can be split into multiple mbufs and retrieved one at a time or (depending on system support) retrieved using “scatter-gather” direct memory access (DMA) (“scatter-gather” refers to the process of gathering data from, or scattering data into, a given set of buffers). Each mbuf transfer is parameterized by a single identified mbuf.
Notably, each socket transfer can create multiple mbuf transfers, where each mbuf transfer copies (or fetches) data from a single mbuf at a time. As a further complication, because the socket spans both: (i) user space (limited privileges) and (ii) kernel space (privileged without limitation), the socket transfer verifies that each mbuf copy into/out of kernel space is valid. More directly, the verification process ensures that the data access is not malicious, corrupted, and/or malformed (i.e., that the transfer is appropriately sized and is to/from an appropriate area).
The processing overhead associated with domain crossing is a non-trivial processing cost. Processing cost affects user experience both directly and indirectly. A processor has a fixed amount of processing cycles every second; thus cycles that are used for transfer verification detract from more user perceptible tasks (e.g., rendering a video or audio stream). Additionally, processor activity consumes power; thus, increases in processing overhead increases power consumption.
Referring back to
Kernel extensions and public APIs enable, for example, 3rd party software developers to develop a wide variety of applications that can interact with a computer system at even the lowest layers of abstraction. For example, kernel extensions can enable socket level filtering, IP level filtering, and even device interface filtering. In the current consumer applications space, many emerging technologies now rely on closely coupled interfaces to the hardware and kernel functionality. For example, many security applications “sniff” network traffic to detect malicious traffic or filter undesirable content; this requires access to other application sandboxes (a level of privilege that is normally reserved for the kernel).
Unfortunately, 3rd party kernel extensions can be dangerous and/or undesirable. As previously noted, software applications are restricted for security and stability reasons; however the kernel is largely unrestricted. A 3rd party kernel extension can introduce instability issues because the 3rd party kernel extensions run in the same address space as the kernel itself (which is outside the purview of traditional memory read/write protections based on memory allocations). Illegal memory accesses can result in segmentation faults and memory corruptions. Furthermore, unsecure kernel extension can create security vulnerabilities that can be exploited by malware. Additionally, even where correctly used, a kernel extension can expose a user's data to the 3rd party software developer. This heightened level of access may raise privacy concerns (e.g., the 3rd party developer may have access to browsing habits, etc.).
The DLIL 206 provides a common interface layer to each of the various physical device drivers which will handle the subsequent data transfer (e.g., Ethernet, Wi-Fi, cellular, etc.). The DLIL performs a number of system-wide holistic network traffic management functions. In one such implementation, the DLIL is responsible for BSD Virtual Interfaces, IOKit Interfaces (e.g., DLIL is the entity by which IOKit based network drivers are connected to the networking stack), Active Queue Management (AQM), flow control and advisory action, etc. In most cases, the device driver 208 may be handled by an external device (e.g., a baseband co-processor), thus the DLIL 206 is usually (but not always) the lowest layer of the network communication stack.
During normal operation, the computer system will logically segment its tasks to optimize overall system operation. In particular, a processor will execute a task, and then “context switch” to another task, thereby ensuring that any single process thread does not monopolize processor resources from start to finish. More directly, a context switch is the process of storing the state of a process, or of a thread, so that it can be restored and execution resumed from the same point later. This allows multiple processes to share a single processor. However, excessive amounts of context switching can slow processor performance down. Notably, while the present discussion is primarily discussed within the context of a single processor for ease of understanding, multi-processor systems have analogous concepts (e.g., multiple processors also perform context switching, although contexts may not necessarily be resumed by the same processor).
For example, consider the following example of a packet reception. Packets arrive at the device driver 208A. The hardware managed by the device driver 208A may notify the processor via e.g., a doorbell signal (e.g., an interrupt). The device driver 208A work loop thread handles the hardware interrupt/doorbell, then signals the DLIL thread (Loop 1 210). The processor services the device driver 208A with high priority, thereby ensuring that the device driver 208A operation is not bottlenecked (e.g., that the data does not overflow the device driver's memory and/or that the device driver does not stall). Once the data has been moved out of the device driver, the processor can context switch to other tasks.
At a later point, the processor can pick up the DLIL 206 execution process again. The processor determines which socket the packets should be routed to (e.g., socket 204A) and routes the packet data appropriately (Loop 2 212). During this loop, the DLIL thread takes each packet, and moves each one sequentially into the socket memory space. Again, the processor can context switch to other tasks so as to ensure that the DLIL task does not block other concurrently executed processing.
Subsequently thereafter, when the socket has the complete packet data transfer the processor can wake the user space application and deliver the packet into user space memory (Loop 3 214). Generally, user space applications are treated at lower priority than kernel tasks; this can be reflected by larger time intervals between suspension and resumption. While the foregoing discussion is presented in the context of packet reception, artisans of ordinary skill in the related arts will readily appreciate, given the contents of the present disclosure, that the process is substantially reversed for packet transmission.
As demonstrated in the foregoing example, context switching ensures that tasks of different processing priority are allocated commensurate amounts of processing time. For example, a processor can spend significantly more time executing tasks of relatively high priority, and service lower priority tasks on an as-needed basis. As a brief aside, human perception is much more forgiving than hardware operation. Consequently, kernel tasks are generally performed at a much higher priority than user space applications. The difference in priority between kernel and user space allows the kernel to handle immediate system management (e.g., hardware interrupts, and queue overflow) in a timely manner, with minimal noticeable impact to the user experience.
Moreover,
Unfortunately, changing tastes in consumer expectations cannot be effectively addressed with the one-size-fits-all model and the conservative in-kernel traditional networking stack. Artisans of ordinary skill in the related arts will readily appreciate, given the contents of the present disclosure, that different device platforms have different capabilities; for example, a desktop processor has significantly more processing and memory capability than a mobile phone processor. More directly, the “one-size-fits-all” solution does not account for the underlying platform capabilities and/or application requirements, and thus is not optimized for performance. Fine-tuning the traditional networking stack for performance based on various “tailored” special cases results in an inordinate amount of software complexity which is untenable to support across the entire ecosystem of devices.
As shown, an application executing from user space can open a Hypertext Transfer Protocol (HTTP) session 302 with a TLS security layer 304 in order to securely transfer data (Application Transport Security (ATS) services) over a network socket 306 that offers TCP/IP transport 308, 310.
As a brief aside, TLS is a record based protocol; in other words, TLS uses data records which are arbitrarily sized (e.g., up to 16 kilobytes). In contrast, TCP is a byte stream protocol (i.e., a byte has a fixed length of eight (8) bits). Consequently, the TCP layer subdivides TLS records into a sequentially ordered set of bytes for delivery. The receiver of the TCP byte stream reconstructs TLS records from the TCP byte stream by receiving each TCP packet, re-ordering the packets according to sequential numbering to recreate the byte stream and extracting the TLS record from the aggregated byte stream. Notably, every TCP packet of the sequence must be present before the TLS record can be reconstructed. Even though TCP can provide reliable delivery under lossy network conditions, there are a number of situations where TLS record delivery could fail. For example, under ideal conditions TCP isolates packet loss from its client (TLS in this example), and a single TCP packet loss should not result in failed TLS record delivery. However, the TLS layer or the application above may incorporate a timeout strategy in a manner that is unaware of the underlying TCP conditions. Thus, if there's significant packet loss in the network, the TLS timeout may be hit (and thus result in a failure to the application) even though TCP would normally provide reliable delivery.
Referring back to
Ideally, the TLS layer should set TLS record sizes based on network condition information. In particular, large TLS records can efficiently use network bandwidth, but require many successful TCP packet deliveries. In contrast, small TLS records incur significantly more network overhead, but can survive poor bandwidth conditions. Unfortunately, networking condition information is lower layer information that is available to the kernel space (e.g., the DLIL and device drivers), but generally restricted from user space applications. Some 3rd party application developers and device manufacturers have incorporated kernel extensions (or similar operating system capabilities) to provide network condition information to the TLS user space applications; however, kernel extensions are undesirable due to the aforementioned security and privacy concerns. Alternately, some 3rd party applications infer the presence of lossy network conditions based on historic TLS record loss. Such inferences are an indirect measure and significantly less accurate and lag behind real-time information (i.e., previous packet loss often does not predict future packet loss).
As shown, an application executing from user space can open a Virtual Private Network (VPN) session 402 over a network socket 406 that offers TCP/IP transport 408, 410. The VPN session is secured with Encapsulating Security Protocol (ESP) 412. The encrypted packet is securely tunneled via TLS 404 (in user space) and recursively sent again over TCP/IP transport 408, 410.
As illustrated within
Artisans of ordinary skill in the related arts, given the contents of the present disclosure, will readily appreciate that the exemplary recursive cross layer transaction of
As shown, three (3) different concurrently executed applications (e.g., a real time application 502, interactive application 504, and file transfer applications 506) in user space, each open a session over network sockets 508 (508A, 508B, 508C) that offer TCP/UDP/IP transport 510/512. Depending on the type of physical interface required, the sessions are switched to BSD network interfaces (ifnet) 514 (514A, 514B, 514C) which handle the appropriate technology. Three different illustrated technology drivers are shown: Wi-Fi 516, Bluetooth 518, and cellular 520.
It is well understood within the networking arts that different application types are associated with different capabilities and requirements. One such example is real time applications 502, commonly used for e.g., streaming audio/visual and/or other “live” data. Real time data has significant latency and/or throughput restrictions; moreover, certain real time applications may not require (and/or support) retransmission for reliable delivery of lost or corrupted data. Instead, real time applications may lower bandwidth requirements to compensate for poor transmission quality (resulting in lower quality, but timely, delivered data).
Another such example is interactive applications 504, commonly used for e.g., human input/output. Interactive data should be delivered at latencies that are below the human perceptible threshold (within several milliseconds) to ensure that the human experience is relatively seamless. This latency interval may be long enough for a retransmission, depending on the underlying physical technology. Additionally, human perception can be more or less tolerant of certain types of data corruptions; for example, audio delays below 20 ms are generally imperceptible, whereas audio corruptions (pops and clicks) are noticeable. Consequently, some interactive applications may allow for some level of error correction and/or adopt less aggressive bandwidth management mechanisms depending on the acceptable performance requirements for human perception.
In contrast to real time applications and interactive applications, file transfer applications 506 require perfect data fidelity without latency restrictions. To these ends, most file transfer technologies support retransmission of lost or corrupted data, and retransmission can have relatively long attempt intervals (e.g., on the order of multiple seconds to a minute).
Similarly, within the communication arts, different communication technologies are associated with different capabilities and requirements. For example, Wi-Fi 516 (wireless local area networking based on IEEE 802.11) is heavily based on contention-based access and is best suited for high bandwidth deliveries with reasonable latency. Wi-Fi is commonly used for file transfer type applications. Bluetooth 518 (personal area networking) is commonly used for low data rate and low latency applications. Bluetooth is commonly used for human interface devices (e.g., headphones, keyboards, and mice). Cellular network technologies 520 often provide non-contention-based access (e.g., dedicated user access) and can be used over varying geographic ranges. Cellular voice or video delivery is a good example of streaming data applications. Artisans of ordinary skill in the related arts will readily recognize that the foregoing examples are purely illustrative, and that different communication technologies are often used to support a variety of different types of application data. For example, Wi-Fi 516 can support file transfer, real time data transmission and/or interactive data with equivalent success.
Referring back to
Moreover, in the computing arts, a “locking” synchronization mechanism is used by the kernel to enforce access limits (e.g., mutual exclusion) on resources in multi-threaded execution. During operation, each thread acquires a lock before accessing the corresponding locked resources data. In other words, at any point in time, the processor is necessarily limited to only the resources available to its currently executing process thread.
Unfortunately, each of the applications has different latency, throughput and processing utilization requirements. Since, each of the network interfaces is sending and receiving data at different times, in different amounts, and with different levels of priority. From a purely logistical standpoint, the kernel is constantly juggling between high priority kernel threads (to ensure that the high priority hardware activities do not stall out) while still servicing each of its concurrently running applications to attempt to provide acceptable levels of service. In some cases, however, the kernel is bottlenecked by the processor's capabilities. Under such situations, some threads will be deprioritized; currently, the traditional networking stack architecture is unable it clearly identify which threads can be deprioritized while still providing acceptable user service.
For example, consider an “expected use” device of
Unfortunately, the addition of an unexpected amount of additional secondary interactive applications 504 (e.g., remote control interface, headphones, and/or other interface devices) and/or background file transfer applications can easily overwhelm the processor. Specifically, the primary real time application does not get enough CPU cycles to run within its time budget, because the kernel threads handling networking are selected at a higher priority. In other words, the user space application is not able to depress the priority of kernel networking threads (which are servicing both the primary and secondary processes). This can result in significantly worse user experience when the video rendering stalls out (video frame misses or video frame drops); whereas simply slowing down a file transfer or degrading the interaction interface may have been preferable.
Prior art solutions have tailored software for specific device implementations (e.g., the Apple TV®). For example, the device can be specifically programmed for an expected use. However, tailored solutions are becoming increasingly common and by extension the exceptions have swallowed the more generic use case. Moreover, tailored solutions are undesirable from multiple software maintenance standpoints. Devices have limited productive lifetimes, and software upkeep is non-trivial.
Ideally, a per-application or per-profile workload optimization would enable a single processor (or multiple processors) to intelligently determine when and/or how too intelligently context switch and/or prioritize its application load (e.g., in the example of
A networking stack architecture and technology that caters to the needs of non-kernel-based networking use cases is disclosed herein. Unlike prior art monolithic networking stacks, the exemplary networking stack architecture described hereinafter includes various components that span multiple domains (both in-kernel, and non-kernel), with varying transport compositions, workload characteristics and parameters.
The user space networking stack architecture provides an efficient infrastructure to transfer data across domains (user space, non-kernel, and kernel). Unlike the traditional networking paradigm that hides the underlying networking tasks within the kernel and substantially limits control thereof by any non-kernel applications, the various embodiments described herein enable faster and more efficient cross domain data transfers.
Various embodiments of the present disclosure provide a faster and more efficient packet input/output (I/O) infrastructure than prior art techniques. Specifically, unlike traditional networking stacks that use a “socket” based communication, disclosed embodiments can transfer data directly between the kernel and user space domains. Direct transfer reduces the per-byte and per-packet costs relative to socket-based communication. Additionally, direct transfer can improve observability and accountability with traffic monitoring.
As shown, a user space application 602 can initiate a network connection by instancing user space protocol stacks 604. Each user space protocol stacks includes network extensions for e.g., TCP/UDP/QUIC/IP, cryptography, framing, multiplexing, tunneling, and/or any number of other networking stack functionalities. Each user space protocol stack 604 communicates with one or more nexuses 608 via a channel input/output (I/O) 606. Each nexus 608 manages access to the network drivers 610. Additionally, shown is legacy application 612 support via existing network socket technologies 614. While the illustrated embodiment shows nexus connections to both user space and in-kernel networking stacks, it is appreciated that the nexus may also enable e.g., non-kernel networking stacks (such as may be used by a daemon or other non-kernel, non-user process).
The following topical sections hereinafter describe the salient features of the various logical constructs in greater detail.
In one embodiment, the non-kernel networking stack provides a direct channel input output (I/O) 606. In one such implementation, the channel I/O 606 is included as part of the user space protocol stack 604. More directly, the channel I/O 606 enables the delivery of packets as a raw data I/O into kernel space with a single validation (e.g., only when the user stack provides the data to the one or more nexuses 608). The data can be directly accessed and/or manipulated in situ, the data need not be copied to an intermediary buffer.
In one exemplary implementation, a channel is an I/O scheme leveraging kernel-managed shared memory. During an access, the channel I/O is presented to the process (e.g., the user process or kernel process) as a file descriptor-based object, rather than as data. In order to access the data, the process de-references the file descriptor for direct access to the shared memory within kernel space. In one such implementation, the file descriptor-based object based I/O is compatible with existing operating system signaling and “eventing” (event notification/response) mechanisms. In one exemplary variant, the channel I/O is based on Inter Process Communication (IPC) packets.
As used herein, the term “descriptor” may refer to data structures that indicate how other data is stored. Descriptors generally include multiple parameters and can be used to identify more complex data structures; for example, a descriptor may include one or more of type, size, address, tag, flag, headers, footers, metadata, structural links to other data descriptors or locations, and/or any other number of format or construction information.
Within the context of the present disclosure, as used herein, the term “pointer” may refer to a specific reference data type that “points” or “references” a location of data in memory. Typically, a pointer stores a memory address that is interpreted by a compiler as an absolute location in system memory or a relative location in system memory based on e.g., a base address, reference address, memory window, or other memory subset. During operation, a pointer is “de-referenced” to recover the data that is stored in the location of memory.
As used herein, the term “metadata” refers to data that describes data. Metadata varies widely in application, but generally falls into one of the descriptive, structural, and/or administrative categories. Descriptive metadata describes data in a manner to enable e.g., discovery and/or identification. Common examples include without limitation e.g., type, size, index tags, and keywords. Structural metadata describes the structure of the data e.g., how compound objects are put together. Common examples include without limitation e.g., prefix, postfix, table of contents, order, and/or any other information that describes the relationships and other characteristics of digital materials. Administrative metadata provides information to help manage a resource; common examples include e.g., authorship and creation information, access privileges, and/or error checking and security-based information (e.g., cyclic redundancy checks (CRC), parity, etc.).
In one embodiment, the channel I/O can be further leveraged to provide direct monitoring of its corresponding associated memory. More directly, unlike existing data transfers which are based on mbuf based divide/copy/move, etc., the channel I/O can provide (with appropriate viewing privileges) a direct window into the memory accesses of the system. Such implementations further simplify software development as debugging and/or traffic monitoring can be performed directly on traffic. Direct traffic monitoring can reduce errors attributed to false positives/false negatives caused by e.g., different software versioning, task scheduling, compiler settings, and/or other software introduced inaccuracies.
In one embodiment, the in-kernel network device drivers (e.g. Wi-Fi, Cellular, Ethernet) use simplified data movement models based on the aforementioned channel I/O scheme. More directly, the user space networking stacks can directly interface to each of the various different technology-based network drivers via channel I/O; in this manner, the user space networking stacks do not incur the traditional data mbuf based divide/copy/move penalties. Additionally, user space applications can directly access user space networking components for immediate traffic handling and processing.
In one embodiment, the networking stack connects to one or more nexus 608. In one such implementation, the nexus 608 is a kernel space process that arbitrates access to system resources including, without limitation e.g., shared memory within kernel space, network drivers, and/or other kernel or user processes. In one such variant, the nexus 608 aggregates one or more channels 606 together for access to the network drivers 610 and/or shared kernel space memory.
In one exemplary implementation, a nexus is a kernel process that determines the format and/or parameters of the data flowing through its connected channels. In some variants, the nexus may further perform ingress and/or egress filtering.
The nexus may use the determined format and/or parameter information to facilitate one-to-one and one-to-many topologies. For example, the nexus can create user-pipes for process-to-process channels; kernel-pipes for process-to-kernel channels; network interfaces for direct channel connection from a process to in-kernel network drivers, or legacy networking stack interfaces; and/or flow-switches for multiplexing flows across channels (e.g., switching a flow from one channel to one or more other channels).
Additionally, in some variants the nexus may provide the format, parameter, and/or ingress egress information to kernel processes and/or one or more appropriately privileged user space processes.
In one embodiment, the nexus 608 may additionally ensure that there is fairness and/or appropriately prioritize each of its connected stacks. For example, within the context of
In one such embodiment, in-kernel, non-kernel, and/or user space infrastructures ensure fairness and can reduce latency due to e.g., buffer bloat (across channels in a given nexus, as well as flows within a channel). In other words, the in-kernel and/or user space infrastructures can negotiate proper buffering sizes based on the expected amount of traffic and/or network capabilities for each flow. By buffering data according to traffic and/or network capability, buffers are not undersized or oversized.
As a brief aside, “buffer bloat” is commonly used to describe e.g., high latency caused by excessive buffering of packets. Specifically, buffer bloat may occur when excessively large buffers are used to support a real time streaming application. As a brief aside, TCP retransmission mechanism relies on measuring the occurrence of packet drops to determine the available bandwidth. Under certain congestion conditions, excessively large buffers can prevent the TCP feedback mechanism from correctly inferring the presence of a network congestion event in a timely manner (the buffered packets “hide” the congestion, since they are not dropped). Consequently, the buffers have to drain before TCP congestion control resets and the TCP connection can correct itself.
Referring back to
While the foregoing example is based on “fairness” standard, artisans of ordinary skill in the related arts will readily appreciate that other schemes may be substituted with equivalent success given the contents of the present disclosure. For example, some embodiments may dynamically or statically service the user application networking space with greater or less weight compared to the legacy socket-based access. For example, user application networking space may be more heavily weighted to improve overall performance or functionality, whereas legacy socket-based access may be preferred where legacy applications are preferentially supported.
In one embodiment of the present disclosure, a network extension is disclosed. A network extension is an agent-based extension that is tightly coupled to network control policies. The agent is executed by the kernel and exposes libraries of network control functionality to user space applications. During operation, user space software can access kernel space functionality through the context and privileges of the agent.
As used herein, the term “agent” may refer to a software agent that acts for a user space application or other program in a relationship of agency with appropriate privileges. The agency relationship between the agent and the user space application implies the authority to decide which, if any, action is appropriate given the user application and kernel privileges. A software agent is privileged to negotiate with the kernel and other software agents regarding without limitation e.g., scheduling, priority, collaboration, visibility, and/other sharing of user space and kernel space information. While the agent negotiates with the kernel on behalf of the application, the kernel ultimately decides on scheduling, priority, etc.
Various benefits and efficiencies can be gained through the use of network extensions. In particular, user space applications can control the protocol stack down to the resolution of exposed threads (i.e., the threads that are made available by the agent). In other words, software agents expose specific access to lower layer network functionality which was previously hidden or abstracted away from user space applications. For example, consider the previous examples of TLS record sizing (see e.g.,
Similarly, consider the previous examples of multi-threading within the context of expected use devices (see e.g.,
As a related benefit, since a software agent represents the application to the kernel; the agent can trust the kernel, but the kernel may or may not trust the agent. For example, a software agent can be used by the kernel to convey network congestion information in a trusted manner to the application; similarly, a software agent can be used by an application to request a higher network priority. Notably, since a software agent operates from user space, the agent's privilege is not promoted to kernel level permissions. In other words, the agent does not permit the user application to exceed its privileges (e.g., the agent cannot commandeer the network driver at the highest network priority or force a read/write to another application's memory space without the other kernel and/or other application's consent).
Networking extensions allow the user space application to execute networking communications functionality within the user space and interpose a network extension between the user space application and the kernel space. As a result, the number of cross domain accesses for complex layering of different protocol stacks can be greatly reduced. Limiting cross domain accesses prevents context switching and allows the user space to efficiently police its own priorities. For example, consider the previous example of a VPN session as was previously illustrated in
As used herein, the term “interposition” may refer to the insertion of an entity between two or more layers. For example, an agent is interposed between the application and the user space networking stack. Depending on the type of agent or network extension, the interposition can be explicit or implicit. Explicit interposition occurs where the application explicitly instances the agent or network extension. For example, the application may explicitly call a user space tunnel extension. In contrast, implicit interposition occurs where the application did not explicitly instance the agent or network extension. Common examples of implicit interposition occur where one user space application sniffs the traffic or filters the content of another user space application.
As used herein, an “instance” may refer to a single copy of a software program or other software object; “instancing” and “instantiations” refers to the creation of the instance. Multiple instances of a program can be created; e.g., copied into memory several times. Software object instances are instantiations of a class; for example, a first software agent and second software instance are each distinct instances of the software agent class.
Referring now to
In one exemplary embodiment, the user space networking stack 700 is instantiated within an application user space 718. More directly, the user space networking stack 700 is treated identically to any one of multiple threads 710 within the application user space 718. Each of the coexisting threads 720 has access to the various functions and libraries offered by the user space networking stack via a direct function call.
As a brief aside, each of the threads 720 reside within the same address space. By virtue of their shared addressability, each of the threads may grant or deny access to their portions of shared address space via existing user space memory management schemes and/or virtual machine type protections. Additionally, threads can freely transfer data structures from one to the other, without e.g., incurring cross domain penalties. For example, TCP data 710 can be freely passed to TLS 706 as a data structure within a user space function call.
As previously noted, the user space networking stack 700 may grant or deny access to other coexistent user space threads; e.g., a user space thread is restricted to the specific function calls and privileges made available via the application interface 702. Furthermore, the user space networking stack 700 is further restricted to interfacing the operating system via the specific kernel function calls and privileges made available via the operating system interface 704. In this manner, both the threads and the user space networking stack have access and visibility into the kernel space, without compromising the kernel's security and stability.
One significant benefit of the user space networking stack 700 is that networking function calls can be made without acquiring various locks that are present in the in-kernel networking stack. As previously noted, the “locking” mechanism is used by the kernel to enforce access limits on multiple threads from multiple different user space applications; however in the user space, access to shared resources are handled within the context of only one user application space at a time, consequently access to shared resources are inherently handled by the single threading nature of user space execution. More directly, only one thread can access the user space networking stack 700 at a time; consequently, kernel locking is entirely obviated by the user space networking stack.
Another benefit of user space network stack operation is cross platform compatibility. For example, certain types of applications (e.g., iTunes®, Apple Music® developed by the Assignee hereof) are deployed over a variety of different operating systems. Similarly, some emerging transport protocols (e.g. QUIC) are ideally served by portable and common software between the client and server endpoints. Consistency in the user space software implementation allows for better and more consistent user experience, improves statistical data gathering and analysis, and provides a foundation for enhancing, experimenting and developing network technologies used across such services. In other words, a consistent user space networking stack can be deployed over any operating system platform without regard for the native operating system stack (e.g., which may vary widely).
Another important advantage of the exemplary user space networking stack is the flexibility to extend and improve the core protocol functionalities, and thus deliver specialized stacks based on the application's requirements. For example, a video conferencing application (e.g., Face Time® developed by the Assignee hereof) may benefit from a networking stack catered to optimize performance for real-time voice and video-streaming traffics (e.g., by allocating more CPU cycles for video rendering, or conversely deprioritizing unimportant ancillary tasks). In one such variant, a specialized stack can be deployed entirely within the user space application, without specialized kernel extensions or changes to the kernel. In this manner, the specialized user space networking stack can be isolated from networking stacks. This is important both from a reliability standpoint (e.g., updated software doesn't affect other software), as well as to minimize debugging and reduce development and test cycle times.
Furthermore, having the network transport layer (e.g. TCP, QUIC) reside in user space can open up many possibilities for improving performance. For example, as previously alluded to, applications (such as TLS) can be modified depending on the underlying network connections. User space applications can be collapsed or tightly integrated into network transports. In some variants, data structure sizes can be adjusted based on immediate lower layer network condition information (e.g., to accommodate or compensate for poor network conditions). Similarly, overly conservative or under conservative transport mechanisms can be avoided (e.g., too much or not enough buffering previously present at the socket layer). Furthermore, unnecessary data copies and/or transforms can be eliminated and protocol signaling (congestion, error, etc.) can be delivered more efficiently.
In yet another embodiment, the exemplary user space networking stack further provides a framework for both networking clients and networking providers. In one such variant, the networking client framework allows the client to interoperate with any network provider (including the legacy BSD stack). In one such variant, the network provider framework provides consistent methods of discovery, connection, and data transfer to networking clients. By providing consistent frameworks for clients and providers which operate seamlessly over a range of different technologies (such as a VPN, Bluetooth, Wi-Fi, cellular, etc.), the client software can be greatly simplified while retaining compatibility with many different technologies.
As shown in the illustrated example, the nexus 800 dequeues received packets from the driver packet pool ring (step 802). For each packet, the nexus inspects the packet header to extract flow information (step 804). At step 806, the flow information is used to lookup a destination packet pool from a flow table. Thereafter the packet is enqueued to its corresponding destination packet pool (step 808). After all the packets have been processed, the nexus can notify destination user space applications of packet delivery. Thereafter, the user space applications may receive their pool of packets. The aforementioned packet-based processing is a substantial improvement over traditional BSD techniques because packets are routed without substantial protocol processing (e.g., the higher protocol layers (TCP, IP, etc.) are handled as needed by the user space application.)
As an important observation, the driver writes data packets into the buffers of its packet pool according to its own operational considerations (which may be out-of-sequence); the driver relies on higher layers of the network stack (e.g., the TCP/IP layers) to rearrange packets into their correct sequence. Notably, traditional network devices use a single IP address for all network connections because all user space applications are serviced by a single monolithic network stack. Packet data is written to the aforementioned sockets for delivery to endpoint applications. Certain “smart” NIC drivers may additionally tag data packets with metadata that is useful for packet-based processing. As but one such example, so-called Large Receive Offload (LRO) and/or Large Send Offload (LSO) capable NICs may provide source and/or destination port information in packet metadata. By convention, certain network ports require special handling; thus, LRO and LSO may also batch packet data according to ports. So-called “port-batching” is used within high-end network routers and switches to prioritize/de-prioritize port specific tasks (e.g., HTTP connection establishment via port 80, etc.)
Within the context of user space networking architectures, hardware acceleration (e.g., port-batching) is often suboptimal because it assumes the presence of a monolithic kernel space network stack. For example, since the aforementioned user space networking architecture supports a distinct user space network stack for each application, port identifiers alone are not sufficient to identify the destination port (concurrently running stacks may have conflicting usages of the same port identifiers.) Consequently, port-batching does not significantly improve packet-based routing and, in fact, incorrectly orders packets within user packet pools.
For example, each packet is sequentially dequeued from the driver pool and then enqueued into its corresponding user space packet pools by the nexus (kernel space). However, port-batching packets at the driver pool results in out-of-sequence delivery to user space packet pools. As a result, user applications must also parse each packet again to arrange the packets into their correct sequence. Furthermore, priority handling associated with port-batching may inadvertently cause the early or late delivery of collateral packets. For example, a prioritized port packet that must be immediately delivered to a user space application will also cause the early delivery of all of the packets within the application's pool (even though the pool may have incomplete packet flows). In other words, the port-batched packet-based routing mechanism causes inefficient downstream processing.
Even though the aforementioned user space networking architecture substantially improves over traditional networking architectures, packet routing continues to be a limiting factor in overall device performance.
In one exemplary embodiment, the nexus classifies and batches packet flows into flow data structures (“flow-batching”) for flow-based processing. Specifically, the nexus transfers flow-batched data structures (rather than individual packets) between its user and driver space applications. The nexus may additionally leverage user and/or driver space metadata to manage flow-batched data structures. Flow-batching enables in-kernel flow-based processing for packet flows. As a related benefit, flow-based processing improves instruction locality; e.g., hardware accelerators can create metadata to tag flows, the kernel can organize flows based on hardware metadata and kernel information, and applications can leverage flow information based on user space considerations. The exemplary processes described herein preserve information for downstream processing which may help reduce processing costs.
Additionally, as depicted in step 1102, a flow may not be released by the nexus until a release condition exists (e.g., all the packets have arrived, a port event specific to the flow has occurred, etc.) In other words, packet-based processing of a driver pool processes all the packets of the driver pool for delivery; in contrast, flow-based processing delivers flows according to flow-specific considerations.
In the illustrated embodiment, the nexus 1100 may additionally impose flow control on flows that are ready to be delivered. Generally, flow control refers to the process of managing data transfer rates between two nodes; e.g., to prevent a fast sender from overwhelming a slow recipient, or a slow sender from reserving too many resources of a fast recipient. For example, a completed flow may be held at step 1110 until more flows are ready for delivery. Other in-kernel flow control may be performed when necessary (e.g., prioritization, deprioritization, aggregation, status reporting, feedback, error detection, error recovery, retransmission, etc.) Thereafter, the flow data structures are enqueued for delivery to their corresponding pools (step 1114).
At 1151, processor 1103 receives a packet from a packet pool. The packet is associated with one or more flows, where the one or more flows are individually identified by corresponding one or more flow keys. At 1153, processor 1103 extracts information from the packet to generate a flow key of the packet indicating a flow for the packet. In aspects, flow keys are unique (e. g., individual) to each of the network flows. Hence, a first flow is identified by a first flow key, and a second flow is identified by a second flow key different from the first flow key. At 1154, processor 1103 looks up the flow key in flow table 1115 in storage device 1101 to determine whether there is an existing flow key stored in the flow table matching the flow key of the packet.
At 1155, responsive to the existing flow key matching the flow key of the packet, processor 1103 stores the packet into a batch of packets of the existing flow. The batch of packets of the existing flow are stored in a flow-batched data structure. At 1159, processor 1103 releases, responsive to a release condition being met, the batch of packets of the existing flow to a user space protocol stack within a user space application through a channel communicatively coupled to the nexus and the user space protocol stack.
In addition, at 1156, responsive to no existing flow key stored in the flow table 1115 matching the flow key of the packet, processor 1103 may add the flow key of the packet to flow table 1115. At 1157, processor 1103 may generate a flow-batched data structure of the particular flow identified by the flow key of the packet. At 1158, processor 1103 may store the packet into the flow-batched data structure of the particular flow identified by the flow key of the packet. Similarly, at 1159, processor 1103 can release, responsive to a release condition being met, the batch of packets of the existing flow to a user space protocol stack within a user space application through a channel communicatively coupled to the nexus and the user space protocol stack.
The exemplary kernel space nexus 1206 reads each packet from the driver packet pool 1204, and batches packet flows based on a flow key that is unique to the network connection (e.g., source and destination IP addresses, and source and destination port identifiers.) In one embodiment, the flow-batched data structures may further leverage metadata provided from e.g., applications, drivers, etc. For instance, the flow-batched data structures may use port metadata provided by LRO/LSO capable NIC hardware.
In one embodiment, flow-batched data structures may represent flows of packet data to facilitate downstream processing. For example, as shown in
In one exemplary embodiment, once the nexus has batched packets from the driver pool into distinct flow-batched data structures, each flow may be separately held or released in the packet pools 1208A, 1208B without impacting other flows. For example, low-latency flows may be released as soon as packets arrive to ensure timely delivery; however, flows for bulk data transfers may be queued to maximize throughput. Additionally, the nexus can leverage driver metadata to organize and/or manage flows; thus, the valuable insights provided by hardware may be leveraged by the nexus (and preserved for downstream processing at user space applications as well).
For example, packets for flow A and flow B are aligned on separate segments 1312 and buffers 1314; each flow has different corresponding metadata 1316. Flow C is a chain of packets which aligns each constituent packet on buffer boundaries. For instance, the first packet is aligned to the first buffer 1324 of the segment 1322. The second packet is aligned with the second buffer 1324 of the segment 1322. Both packets have their own metadata 1326. Flow D is a super packet that compresses metadata to reduce data size; only the first packet aligns to segment boundaries 1332. Subsequent packets may or may not align to buffer boundaries 1334. Only one copy of metadata 1336 is kept (the second packet references a pointer to the first packet's metadata).
Various embodiments can be implemented, for example, using one or more computer systems, such as computer system 1400 shown in
Computer system 1400 includes one or more processors (also called central processing units, or CPUs), such as a processor 1404. Processor 1404 is connected to communication infrastructure or bus 1406.
One or more processors 1404 may each be a graphics processing unit (GPU). In an embodiment, a GPU is a processor that is a specialized electronic circuit designed to process mathematically intensive applications. The GPU may have a parallel structure that is efficient for parallel processing of large blocks of data, such as mathematically intensive data common to computer graphics applications, images, videos, etc.
Computer system 1400 also includes user input/output device(s) 1403, such as monitors, keyboards, pointing devices, etc., that communicate with communication infrastructure 1406 through user input/output interface(s) 1402.
Computer system 1400 also includes a main or primary memory 1408, such as random access memory (RAM). Main memory 1408 may include one or more levels of cache. Main memory 1408 has stored therein control logic (i.e., computer software) and/or data.
Computer system 1400 may also include one or more secondary storage devices or memory 1410. Secondary memory 1410 may include, for example, a hard disk drive 1412 and/or a removable storage device or drive 1414. Removable storage drive 1414 may be a floppy disk drive, a magnetic tape drive, a compact disk drive, an optical storage device, tape backup device, and/or any other storage device/drive.
Removable storage drive 1414 may interact with a removable storage unit 1418. Removable storage unit 1418 includes a computer usable or readable storage device having stored thereon computer software (control logic) and/or data. Removable storage unit 1418 may be a floppy disk, magnetic tape, compact disk, DVD, optical storage disk, and/any other computer data storage device. Removable storage drive 1414 reads from and/or writes to removable storage unit 1418 in a well-known manner.
According to an exemplary embodiment, secondary memory 1410 may include other means, instrumentalities or other approaches for allowing computer programs and/or other instructions and/or data to be accessed by computer system 1400. Such means, instrumentalities or other approaches may include, for example, a removable storage unit 1422 and an interface 1420. Examples of the removable storage unit 1422 and the interface 1420 may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM or PROM) and associated socket, a memory stick and USB port, a memory card and associated memory card slot, and/or any other removable storage unit and associated interface.
Computer system 1400 may further include a communication or network interface 1424. Communication interface 1424 enables computer system 1400 to communicate and interact with any combination of remote devices, remote networks, remote entities, etc. (individually and collectively referenced by reference number 1428). For example, communication interface 1424 may allow computer system 1400 to communicate with remote devices 1428 over communications path 1426, which may be wired and/or wireless, and which may include any combination of LANs, WANs, the Internet, etc. Control logic and/or data may be transmitted to and from computer system 1400 via communication path 1426.
In an embodiment, a tangible, non-transitory apparatus or article of manufacture comprising a tangible, non-transitory computer useable or readable medium having control logic (software) stored thereon is also referred to herein as a computer program product or program storage device. This includes, but is not limited to, computer system 1400, main memory 1408, secondary memory 1410, and removable storage units 1418 and 1422, as well as tangible articles of manufacture embodying any combination of the foregoing. Such control logic, when executed by one or more data processing devices (such as computer system 1400), causes such data processing devices to operate as described herein.
Based on the teachings contained in this disclosure, it will be apparent to persons skilled in the relevant art(s) how to make and use embodiments of this disclosure using data processing devices, computer systems and/or computer architectures other than that shown in
It is to be appreciated that the Detailed Description section, and not any other section, is intended to be used to interpret the claims. Other sections can set forth one or more but not all exemplary embodiments as contemplated by the inventor(s), and thus, are not intended to limit this disclosure or the appended claims in any way.
While this disclosure describes exemplary embodiments for exemplary fields and applications, it should be understood that the disclosure is not limited thereto. Other embodiments and modifications thereto are possible, and are within the scope and spirit of this disclosure. For example, and without limiting the generality of this paragraph, embodiments are not limited to the software, hardware, firmware, and/or entities illustrated in the figures and/or described herein. Further, embodiments (whether or not explicitly described herein) have significant utility to fields and applications beyond the examples described herein.
Embodiments have been described herein with the aid of functional building blocks illustrating the implementation of specified functions and relationships thereof. The boundaries of these functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternate boundaries can be defined as long as the specified functions and relationships (or equivalents thereof) are appropriately performed. Also, alternative embodiments can perform functional blocks, steps, operations, methods, etc. using orderings different than those described herein.
References herein to “one embodiment,” “an embodiment,” “an example embodiment,” or similar phrases, indicate that the embodiment described can include a particular feature, structure, or characteristic, but every embodiment can not necessarily include the 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 would be within the knowledge of persons skilled in the relevant art(s) to incorporate such feature, structure, or characteristic into other embodiments whether or not explicitly mentioned or described herein. Additionally, some embodiments can be described using the expression “coupled” and “connected” along with their derivatives. These terms are not necessarily intended as synonyms for each other. For example, some embodiments can be described using the terms “connected” and/or “coupled” to indicate that two or more elements are in direct physical or electrical contact with each other. The term “coupled,” however, can also mean that two or more elements are not in direct contact with each other, but yet still co-operate or interact with each other.
As used herein, the term “native” and “natural” refer to memory boundaries of the operating system that are addressable via the memory management unit (MMU). Native memory boundaries of the operating system can be exposed to user space applications directly; the kernel does not need to parse network protocol data structures using the aforementioned read-write accesses. In some variants, transfers based on native memory boundaries enable “zero-copy” data transfers (where the processor does not copy data from one memory location to another memory location). Additionally, since each flow data structure is isolated from other flow data structures, flows do not block one another. Thus, flows may be released when they are ready rather than when e.g., a segment is fully packed with packets. More directly, the exemplary flow data structure prioritizes ease of access over compactness.
It will be recognized that while certain embodiments of the present disclosure are described in terms of a specific sequence of steps of a method, these descriptions are only illustrative of the broader methods described herein, and may be modified as required by the particular application. Certain steps may be rendered unnecessary or optional under certain circumstances. Additionally, certain steps or functionality may be added to the disclosed embodiments, or the order of performance of two or more steps permuted. All such variations are considered to be encompassed within the disclosure and claimed herein.
While the above detailed description has shown, described, and pointed out novel features as applied to various embodiments, it will be understood that various omissions, substitutions, and changes in the form and details of the device or process illustrated may be made by those skilled in the art without departing from principles described herein. The foregoing description is of the best mode presently contemplated. This description is in no way meant to be limiting, but rather should be taken as illustrative of the general principles described herein. The scope of the disclosure should be determined with reference to the claims.
This application claims priority to U.S. Provisional Patent Application No. 63/038,520, filed Jun. 12, 2020, which is incorporated by reference herein in its entirety.
| Number | Name | Date | Kind |
|---|---|---|---|
| 4805137 | Grant et al. | Feb 1989 | A |
| 4949299 | Pickett | Aug 1990 | A |
| 5367688 | Croll | Nov 1994 | A |
| 5467459 | Alexander et al. | Nov 1995 | A |
| 5485578 | Sweazey | Jan 1996 | A |
| 5506968 | Dukes | Apr 1996 | A |
| 5613086 | Frey et al. | Mar 1997 | A |
| 5659542 | Bell et al. | Aug 1997 | A |
| 5708779 | Graziano et al. | Jan 1998 | A |
| 5731973 | Takaishi et al. | Mar 1998 | A |
| 5850395 | Hauser et al. | Dec 1998 | A |
| 5903564 | Ganmukhi et al. | May 1999 | A |
| 5943507 | Cornish et al. | Aug 1999 | A |
| 6008992 | Kawakami | Dec 1999 | A |
| 6032179 | Osborne | Feb 2000 | A |
| 6216178 | Stracovsky et al. | Apr 2001 | B1 |
| 6233702 | Horst et al. | May 2001 | B1 |
| 6260152 | Cole et al. | Jul 2001 | B1 |
| 6349355 | Draves et al. | Feb 2002 | B1 |
| 6359863 | Varma et al. | Mar 2002 | B1 |
| 6411997 | Dawes et al. | Jun 2002 | B1 |
| 6485081 | Bingle et al. | Nov 2002 | B1 |
| 6523073 | Kammer et al. | Feb 2003 | B1 |
| 6553446 | Miller | Apr 2003 | B1 |
| 6693895 | Crummey et al. | Feb 2004 | B1 |
| 6815873 | Johnson et al. | Nov 2004 | B2 |
| 6874075 | Jerding et al. | Mar 2005 | B2 |
| 6948094 | Schultz et al. | Sep 2005 | B2 |
| 6973701 | Momoda et al. | Dec 2005 | B2 |
| 6990594 | Kim | Jan 2006 | B2 |
| 7013536 | Golden et al. | Mar 2006 | B2 |
| 7032282 | Powell et al. | Apr 2006 | B2 |
| 7100020 | Brightman et al. | Aug 2006 | B1 |
| 7111307 | Wang | Sep 2006 | B1 |
| 7127600 | Zimmer et al. | Oct 2006 | B2 |
| 7152231 | Galluscio et al. | Dec 2006 | B1 |
| 7281172 | Chujo | Oct 2007 | B2 |
| 7397774 | Holland et al. | Jul 2008 | B1 |
| 7398382 | Rothman et al. | Jul 2008 | B2 |
| 7403542 | Thompson | Jul 2008 | B1 |
| 7506084 | Moerti et al. | Mar 2009 | B2 |
| 7509391 | Chauvel et al. | Mar 2009 | B1 |
| 7587575 | Moertl et al. | Sep 2009 | B2 |
| 7590817 | Moertl et al. | Sep 2009 | B2 |
| 7617377 | Moertl et al. | Nov 2009 | B2 |
| 7681012 | Verma et al. | Mar 2010 | B2 |
| 7685476 | Andre et al. | Mar 2010 | B2 |
| 7802256 | Havens | Sep 2010 | B2 |
| 7853731 | Zeng | Dec 2010 | B1 |
| 7899941 | Hendry et al. | Mar 2011 | B2 |
| 7941682 | Adams | May 2011 | B2 |
| 8214707 | Munson et al. | Jul 2012 | B2 |
| 8230248 | Dance et al. | Jul 2012 | B2 |
| 8239947 | Glick et al. | Aug 2012 | B1 |
| 8255725 | Shimazaki et al. | Aug 2012 | B2 |
| 8352624 | Zimmerman et al. | Jan 2013 | B2 |
| 8468285 | Kobayashi | Jun 2013 | B2 |
| 8555099 | Marinkovic et al. | Oct 2013 | B2 |
| 8561090 | Schneider | Oct 2013 | B2 |
| 8635412 | Wilshire | Jan 2014 | B1 |
| 8656228 | Check et al. | Feb 2014 | B2 |
| 8769168 | Moertl et al. | Jul 2014 | B2 |
| 8788822 | Riddle | Jul 2014 | B1 |
| 8799537 | Zhu et al. | Aug 2014 | B1 |
| 8806640 | Wang | Aug 2014 | B2 |
| 8819386 | Mather | Aug 2014 | B1 |
| 8848809 | Whitby-Strevens | Sep 2014 | B2 |
| 8855120 | Robbins | Oct 2014 | B2 |
| 8876062 | Baghdasarian | Nov 2014 | B1 |
| 9049179 | Luna | Jun 2015 | B2 |
| 9130864 | Keith | Sep 2015 | B2 |
| 9135059 | Ballard et al. | Sep 2015 | B2 |
| 9152580 | Chau et al. | Oct 2015 | B1 |
| 9170957 | Touzni et al. | Oct 2015 | B2 |
| 9280360 | Xu et al. | Mar 2016 | B2 |
| 9319090 | Whitby-Strevens | Apr 2016 | B2 |
| 9544069 | Whitby-Strevens et al. | Jan 2017 | B2 |
| 9547535 | Wilt | Jan 2017 | B1 |
| 9594718 | Kaushik et al. | Mar 2017 | B2 |
| 9769756 | Cui et al. | Sep 2017 | B1 |
| 9830289 | Pulyala et al. | Nov 2017 | B2 |
| 9910475 | Kurts et al. | Mar 2018 | B2 |
| 9913305 | Pinheiro et al. | Mar 2018 | B2 |
| 9932757 | Hager | Apr 2018 | B2 |
| 9959124 | Herbeck et al. | May 2018 | B1 |
| 9985904 | Shalev et al. | May 2018 | B2 |
| 10078361 | Sanghi et al. | Sep 2018 | B2 |
| 10230608 | Tsirkin | Mar 2019 | B2 |
| 10289555 | Michaud et al. | May 2019 | B1 |
| 10331600 | Rajadnya et al. | Jun 2019 | B1 |
| 10331612 | Petkov et al. | Jun 2019 | B1 |
| 10534601 | Venkata et al. | Jan 2020 | B1 |
| 10678432 | Dreier et al. | Jun 2020 | B1 |
| 10798059 | Singh et al. | Oct 2020 | B1 |
| 10798224 | Masputra et al. | Oct 2020 | B2 |
| 10819831 | Masputra et al. | Oct 2020 | B2 |
| 10999132 | Sagar et al. | May 2021 | B1 |
| 11095758 | Masputra et al. | Aug 2021 | B2 |
| 11146665 | Masputra et al. | Oct 2021 | B2 |
| 11159651 | Masputra et al. | Oct 2021 | B2 |
| 11178259 | Masputra et al. | Nov 2021 | B2 |
| 11178260 | Masputra et al. | Nov 2021 | B2 |
| 11212373 | Masputra et al. | Dec 2021 | B2 |
| 11368560 | Masputra et al. | Jun 2022 | B2 |
| 20010037410 | Gardner | Nov 2001 | A1 |
| 20020013868 | West | Jan 2002 | A1 |
| 20020044553 | Chakravorty | Apr 2002 | A1 |
| 20020053011 | Aiken et al. | May 2002 | A1 |
| 20020065867 | Chauvel | May 2002 | A1 |
| 20020169938 | Scott et al. | Nov 2002 | A1 |
| 20020195177 | Hinkley et al. | Dec 2002 | A1 |
| 20030014607 | Slavin et al. | Jan 2003 | A1 |
| 20030061395 | Kingsbury et al. | Mar 2003 | A1 |
| 20030120935 | Teal et al. | Jun 2003 | A1 |
| 20030200413 | Gurumoorthy et al. | Oct 2003 | A1 |
| 20040010473 | Hsu et al. | Jan 2004 | A1 |
| 20040010545 | Pandya | Jan 2004 | A1 |
| 20040044929 | Chujo | Mar 2004 | A1 |
| 20040105384 | Gallezot et al. | Jun 2004 | A1 |
| 20040128568 | O'Shea | Jul 2004 | A1 |
| 20040179546 | McDaniel et al. | Sep 2004 | A1 |
| 20040201749 | Malloy Desormeaux | Oct 2004 | A1 |
| 20040221056 | Kobayashi | Nov 2004 | A1 |
| 20040228365 | Kobayashi | Nov 2004 | A1 |
| 20050055406 | Singhai et al. | Mar 2005 | A1 |
| 20050068897 | Arita et al. | Mar 2005 | A1 |
| 20050076196 | Zimmer et al. | Apr 2005 | A1 |
| 20050076244 | Watanabe | Apr 2005 | A1 |
| 20050108385 | Wechter et al. | May 2005 | A1 |
| 20050114620 | Justen | May 2005 | A1 |
| 20050117601 | Anderson et al. | Jun 2005 | A1 |
| 20050138628 | Bradford et al. | Jun 2005 | A1 |
| 20050140683 | Collins et al. | Jun 2005 | A1 |
| 20050149711 | Zimmer et al. | Jul 2005 | A1 |
| 20050157781 | Ho et al. | Jul 2005 | A1 |
| 20050198777 | Mabe | Sep 2005 | A1 |
| 20050278498 | Ahluwalia et al. | Dec 2005 | A1 |
| 20050285862 | Noda et al. | Dec 2005 | A1 |
| 20060039285 | Chapman et al. | Feb 2006 | A1 |
| 20060047989 | Delgado et al. | Mar 2006 | A1 |
| 20060075119 | Hussain et al. | Apr 2006 | A1 |
| 20060107071 | Girish et al. | May 2006 | A1 |
| 20060136570 | Pandya | Jun 2006 | A1 |
| 20060186700 | Browne et al. | Aug 2006 | A1 |
| 20060186706 | Browne et al. | Aug 2006 | A1 |
| 20060215697 | Olderdissen | Sep 2006 | A1 |
| 20060218301 | O'Toole et al. | Sep 2006 | A1 |
| 20060232051 | Morris et al. | Oct 2006 | A1 |
| 20060248542 | Wang et al. | Nov 2006 | A1 |
| 20070005869 | Balraj et al. | Jan 2007 | A1 |
| 20070008983 | Van Doren et al. | Jan 2007 | A1 |
| 20070043901 | Wu et al. | Feb 2007 | A1 |
| 20070063540 | Browne et al. | Mar 2007 | A1 |
| 20070063541 | Browne et al. | Mar 2007 | A1 |
| 20070070997 | Weitz et al. | Mar 2007 | A1 |
| 20070080013 | Melz et al. | Apr 2007 | A1 |
| 20070086480 | Elzur | Apr 2007 | A1 |
| 20070118831 | Kondo | May 2007 | A1 |
| 20070180041 | Suzuoki | Aug 2007 | A1 |
| 20070183418 | Riddoch et al. | Aug 2007 | A1 |
| 20070201492 | Kobayashi | Aug 2007 | A1 |
| 20070226375 | Chu et al. | Sep 2007 | A1 |
| 20070226417 | Davis | Sep 2007 | A1 |
| 20070255802 | Aloni et al. | Nov 2007 | A1 |
| 20070261307 | Alexander | Nov 2007 | A1 |
| 20070286246 | Kobayashi | Dec 2007 | A1 |
| 20080005794 | Inoue et al. | Jan 2008 | A1 |
| 20080007081 | Shibata et al. | Jan 2008 | A1 |
| 20080010563 | Nishimura | Jan 2008 | A1 |
| 20080046689 | Chen et al. | Feb 2008 | A1 |
| 20080077816 | Ravichandran | Mar 2008 | A1 |
| 20080100079 | Herrera et al. | May 2008 | A1 |
| 20080100092 | Gao et al. | May 2008 | A1 |
| 20080120911 | Browne et al. | May 2008 | A1 |
| 20080127292 | Cooper et al. | May 2008 | A1 |
| 20080148291 | Huang et al. | Jun 2008 | A1 |
| 20080183931 | Verm et al. | Jul 2008 | A1 |
| 20080231711 | Glen et al. | Sep 2008 | A1 |
| 20080235355 | Spanier et al. | Sep 2008 | A1 |
| 20080244259 | Zimmer et al. | Oct 2008 | A1 |
| 20080301148 | Lee et al. | Dec 2008 | A1 |
| 20090006920 | Munson et al. | Jan 2009 | A1 |
| 20090024924 | Kim | Jan 2009 | A1 |
| 20090092057 | Doctor et al. | Apr 2009 | A1 |
| 20090113141 | Bullman et al. | Apr 2009 | A1 |
| 20090138650 | Lin et al. | May 2009 | A1 |
| 20090172674 | Bobak et al. | Jul 2009 | A1 |
| 20090177847 | Ceze et al. | Jul 2009 | A1 |
| 20090189442 | Chi | Jul 2009 | A1 |
| 20090225818 | Dapper et al. | Sep 2009 | A1 |
| 20090240874 | Pong | Sep 2009 | A1 |
| 20090265723 | Mochizuki et al. | Oct 2009 | A1 |
| 20090322531 | Estevez et al. | Dec 2009 | A1 |
| 20100005014 | Castle et al. | Jan 2010 | A1 |
| 20100017655 | Gooding et al. | Jan 2010 | A1 |
| 20100049876 | Pope et al. | Feb 2010 | A1 |
| 20100082859 | Hendry et al. | Apr 2010 | A1 |
| 20100098419 | Levy et al. | Apr 2010 | A1 |
| 20100118041 | Chen et al. | May 2010 | A1 |
| 20100329319 | Dai et al. | Dec 2010 | A1 |
| 20110029696 | Uehara | Feb 2011 | A1 |
| 20110035575 | Kwon | Feb 2011 | A1 |
| 20110052142 | Sultenfuss et al. | Mar 2011 | A1 |
| 20110083002 | Albers et al. | Apr 2011 | A1 |
| 20110161619 | Kaminski et al. | Jun 2011 | A1 |
| 20110219208 | Asaad et al. | Sep 2011 | A1 |
| 20110242425 | Zeng | Oct 2011 | A1 |
| 20110246742 | Kogen et al. | Oct 2011 | A1 |
| 20110276710 | Mighani et al. | Nov 2011 | A1 |
| 20110292936 | Wang et al. | Dec 2011 | A1 |
| 20110310296 | Lee et al. | Dec 2011 | A1 |
| 20110320861 | Bayer et al. | Dec 2011 | A1 |
| 20120017063 | Hummel et al. | Jan 2012 | A1 |
| 20120036334 | Horman et al. | Feb 2012 | A1 |
| 20120072658 | Hashimoto | Mar 2012 | A1 |
| 20120084483 | Sanjive | Apr 2012 | A1 |
| 20120084484 | Post et al. | Apr 2012 | A1 |
| 20120102307 | Wong | Apr 2012 | A1 |
| 20120124252 | Kayama | May 2012 | A1 |
| 20120203880 | Kluyt et al. | Aug 2012 | A1 |
| 20120224640 | Sole Rojals et al. | Sep 2012 | A1 |
| 20120229076 | Zhu et al. | Sep 2012 | A1 |
| 20120260017 | Mine et al. | Oct 2012 | A1 |
| 20130039278 | Bouazizi et al. | Feb 2013 | A1 |
| 20130050216 | Whitby-Strevens et al. | Feb 2013 | A1 |
| 20130057567 | Frank et al. | Mar 2013 | A1 |
| 20130067188 | Mehra et al. | Mar 2013 | A1 |
| 20130091772 | Berger et al. | Apr 2013 | A1 |
| 20130111014 | Lawrie et al. | May 2013 | A1 |
| 20130138840 | Kegel et al. | May 2013 | A1 |
| 20130162911 | Glen | Jun 2013 | A1 |
| 20130204927 | Kruglikov et al. | Aug 2013 | A1 |
| 20130205113 | Ahmad et al. | Aug 2013 | A1 |
| 20130275976 | Dawson et al. | Oct 2013 | A1 |
| 20130290947 | Li | Oct 2013 | A1 |
| 20130347131 | Mooring et al. | Dec 2013 | A1 |
| 20140033220 | Campbell et al. | Jan 2014 | A1 |
| 20140068624 | Fuller et al. | Mar 2014 | A1 |
| 20140068636 | Dupont et al. | Mar 2014 | A1 |
| 20140122695 | Kulikov et al. | May 2014 | A1 |
| 20140122828 | Kagan et al. | May 2014 | A1 |
| 20140173236 | Kegel | Jun 2014 | A1 |
| 20140189057 | Sankoda et al. | Jul 2014 | A1 |
| 20140211894 | Yang | Jul 2014 | A1 |
| 20140247983 | MacInnis et al. | Sep 2014 | A1 |
| 20140355606 | Riddoch et al. | Dec 2014 | A1 |
| 20150007262 | Aissi et al. | Jan 2015 | A1 |
| 20150036051 | Broberg et al. | Feb 2015 | A1 |
| 20150081985 | Archer et al. | Mar 2015 | A1 |
| 20150156122 | Singh et al. | Jun 2015 | A1 |
| 20150172345 | Mantin et al. | Jun 2015 | A1 |
| 20150189109 | Whitby-Strevens et al. | Jul 2015 | A1 |
| 20150205749 | Whitby-Strevens et al. | Jul 2015 | A1 |
| 20150212806 | Hsieh | Jul 2015 | A1 |
| 20150244804 | Warfield et al. | Aug 2015 | A1 |
| 20150261588 | Liu et al. | Sep 2015 | A1 |
| 20150309940 | Kumar | Oct 2015 | A1 |
| 20150326542 | Serebrin | Nov 2015 | A1 |
| 20150363110 | Batra et al. | Dec 2015 | A1 |
| 20150378737 | Debbage et al. | Dec 2015 | A1 |
| 20160028635 | Wang | Jan 2016 | A1 |
| 20160034195 | Li et al. | Feb 2016 | A1 |
| 20160041852 | Suarez Gracia et al. | Feb 2016 | A1 |
| 20160044143 | Narasimhamurthy | Feb 2016 | A1 |
| 20160063258 | Ackerly | Mar 2016 | A1 |
| 20160077989 | Pulyala et al. | Mar 2016 | A1 |
| 20160103480 | Sanghi et al. | Apr 2016 | A1 |
| 20160103689 | Sanghi et al. | Apr 2016 | A1 |
| 20160103743 | Sanghi et al. | Apr 2016 | A1 |
| 20160142988 | Powell et al. | May 2016 | A1 |
| 20160208539 | Hofmann et al. | Jul 2016 | A1 |
| 20160224442 | Sanghi et al. | Aug 2016 | A1 |
| 20160226957 | Zhang et al. | Aug 2016 | A1 |
| 20160226967 | Zhang et al. | Aug 2016 | A1 |
| 20160231929 | Tsirkin | Aug 2016 | A1 |
| 20160261632 | Kölhi et al. | Sep 2016 | A1 |
| 20160269991 | Van Greunen et al. | Sep 2016 | A1 |
| 20160315880 | Guo | Oct 2016 | A1 |
| 20160357443 | Li et al. | Dec 2016 | A1 |
| 20160363955 | Stevens et al. | Dec 2016 | A1 |
| 20160364350 | Sanghi et al. | Dec 2016 | A1 |
| 20160378545 | Ho | Dec 2016 | A1 |
| 20170003977 | Sumida et al. | Jan 2017 | A1 |
| 20170003997 | Kelly et al. | Jan 2017 | A1 |
| 20170075856 | Suzue et al. | Mar 2017 | A1 |
| 20170089641 | Humfeld et al. | Mar 2017 | A1 |
| 20170108912 | Li et al. | Apr 2017 | A1 |
| 20170111283 | Kumar et al. | Apr 2017 | A1 |
| 20170124327 | Kumbhar et al. | May 2017 | A1 |
| 20170126726 | Han | May 2017 | A1 |
| 20170147282 | Seo | May 2017 | A1 |
| 20170149890 | Shamis et al. | May 2017 | A1 |
| 20170187621 | Shalev et al. | Jun 2017 | A1 |
| 20170187846 | Shalev et al. | Jun 2017 | A1 |
| 20170249098 | Petkov et al. | Aug 2017 | A1 |
| 20170264497 | Lim | Sep 2017 | A1 |
| 20170286300 | Doshi et al. | Oct 2017 | A1 |
| 20170286322 | Garg et al. | Oct 2017 | A1 |
| 20170286323 | Garg et al. | Oct 2017 | A1 |
| 20170308460 | Guthula et al. | Oct 2017 | A1 |
| 20170337588 | Chittilappilly et al. | Nov 2017 | A1 |
| 20170353499 | Huang et al. | Dec 2017 | A1 |
| 20170371591 | Xia et al. | Dec 2017 | A1 |
| 20180004690 | Kaminski et al. | Jan 2018 | A1 |
| 20180070341 | Islam et al. | Mar 2018 | A1 |
| 20180081829 | Kaplan | Mar 2018 | A1 |
| 20180129261 | Garg et al. | May 2018 | A1 |
| 20180129269 | Garg et al. | May 2018 | A1 |
| 20180129270 | Garg et al. | May 2018 | A1 |
| 20180173643 | Yu et al. | Jun 2018 | A1 |
| 20180196648 | Henderson et al. | Jul 2018 | A1 |
| 20180219805 | MacNeil et al. | Aug 2018 | A1 |
| 20180219976 | Decenzo et al. | Aug 2018 | A1 |
| 20180239657 | Petrbok et al. | Aug 2018 | A1 |
| 20180253315 | Norton et al. | Sep 2018 | A1 |
| 20180285561 | Frank et al. | Oct 2018 | A1 |
| 20180295052 | St. Laurent | Oct 2018 | A1 |
| 20180329743 | Pope et al. | Nov 2018 | A1 |
| 20180343206 | White et al. | Nov 2018 | A1 |
| 20180357176 | Wang | Dec 2018 | A1 |
| 20190036893 | Jiang | Jan 2019 | A1 |
| 20190052659 | Weingarten et al. | Feb 2019 | A1 |
| 20190065301 | Tsirkin et al. | Feb 2019 | A1 |
| 20190097938 | Talla et al. | Mar 2019 | A1 |
| 20190102303 | Wang et al. | Apr 2019 | A1 |
| 20190102568 | Hausauer et al. | Apr 2019 | A1 |
| 20190109714 | Clark et al. | Apr 2019 | A1 |
| 20190140983 | Tu | May 2019 | A1 |
| 20190141041 | Bhabbur et al. | May 2019 | A1 |
| 20190147066 | Ben Dayan et al. | May 2019 | A1 |
| 20190147069 | Ben Dayan et al. | May 2019 | A1 |
| 20190205533 | Diehl et al. | Jul 2019 | A1 |
| 20190213044 | Cui et al. | Jul 2019 | A1 |
| 20190213166 | Petkov et al. | Jul 2019 | A1 |
| 20190253351 | Ihlar et al. | Aug 2019 | A1 |
| 20190286466 | Tsirkin et al. | Sep 2019 | A1 |
| 20190303204 | Masputra et al. | Oct 2019 | A1 |
| 20190303205 | Masputra et al. | Oct 2019 | A1 |
| 20190303221 | Masputra et al. | Oct 2019 | A1 |
| 20190303222 | Masputra et al. | Oct 2019 | A1 |
| 20190303280 | Masputra et al. | Oct 2019 | A1 |
| 20190303562 | Masputra et al. | Oct 2019 | A1 |
| 20190303576 | Masputra et al. | Oct 2019 | A1 |
| 20190306076 | Masputra et al. | Oct 2019 | A1 |
| 20190306087 | Masputra et al. | Oct 2019 | A1 |
| 20190306109 | Masputra et al. | Oct 2019 | A1 |
| 20190306281 | Masputra et al. | Oct 2019 | A1 |
| 20190306282 | Masputra et al. | Oct 2019 | A1 |
| 20200019695 | Sovio et al. | Jan 2020 | A1 |
| 20200036615 | Lewis | Jan 2020 | A1 |
| 20200065244 | Sanghi et al. | Feb 2020 | A1 |
| 20200073829 | Tsirkin et al. | Mar 2020 | A1 |
| 20200195684 | Linz | Jun 2020 | A1 |
| 20200328966 | Wang | Oct 2020 | A1 |
| 20210011856 | Xia et al. | Jan 2021 | A1 |
| 20210097006 | Masputra et al. | Apr 2021 | A1 |
| 20210099391 | Masputra et al. | Apr 2021 | A1 |
| Number | Date | Country |
|---|---|---|
| 3013008 | Apr 2016 | EP |
| H02306082 | Dec 1990 | JP |
| H03169996 | Jul 1991 | JP |
| 2013246642 | Dec 2013 | JP |
| 2015001867 | Jan 2015 | JP |
| WO 2008070138 | Jun 2008 | WO |
| Entry |
|---|
| Moon-Sang Lee, Joonwon Lee and S. Maeng, “Context-aware address translation for high-performance SMP cluster system,” 2008u IEEE International Conference on Cluster Computing, Tsukuba, 2008, pp. 292-297, doi: 10.1109/CLUSTR.2008.4663784. (Year: 2008). |
| Honda et al, “Rekindling Network Protocol Innovation with User-Level Stacks”, ACM SIGCOMM Computer Communication Review, vol. 44, No. 2, Apr. 2014. |
| Gopalakrishnan R., et al., “Efficient User-Space Protocol Implementations with QoS Guarantees Using Real-Time Upcalls”, IEEE/ACM Transactions on Networking, Aug. 1998, vol. 6 (4), pp. 374-388. |
| ECN L1 PM Substates with CLKREQ approved Aug. 23, 2012. |
| Jackson, “PCI Express Technology”, Sep. 2012 (Sep. 2012), MindShare Press, xP002777351, pp. 49,86,87,712-723. |
| PCI Express base Specification Revision 3.0, published Nov. 10, 2010. |
| PCI Express Base Specification Revision 3.1, published Oct. 8, 2014. |
| Universal Serial Bus, Communication Class, Subclass Specifications for Network Control Model (NCM) Devices; Revision 1.0 (Errata 1), Nov. 24, 2010, published by USB Implementers Forum, Inc. |
| Whitworth, “Improving Networking by moving the network stack to userspace”, Imperial College London, Jun. 14, 2010 [Mar. 17, 2022]; retrieved from the Internet: <URL https://www.doc.ic.ac.uk/teaching/distinguished-projects/2010/m.whitworth.pdf (Year: 2010). |
| Number | Date | Country | |
|---|---|---|---|
| 20210392080 A1 | Dec 2021 | US |
| Number | Date | Country | |
|---|---|---|---|
| 63038520 | Jun 2020 | US |
