Transmit-side scaling and alignment

Abstract

Examples of the present disclosure describe systems and methods for transmit-side scaling. In an example, transmit-side configuration information is received by a host operating system from a client operating system, where the transmit-side scaling configuration information specifies a manner in which data packets transmitted by the host operating system are to be distributed to a network interface card of the host operating system. The transmitting-side configuration scaling information is implemented in an outbound transport table of the host operating system. When a data packet is received by the host operating system, the host operating system evaluates the data packet using the outbound transport table. Based on the evaluation, the data packet is sent using a specified transmission queue of the network interface card.

Description

Background Art

[0001] Receive side scaling enables an operating system to specify to a network interface card the manner in which data packets received by the network interface card are to be distributed among the processors of the operating system. However, there is currently no mechanism for send side scaling, in which the network interface card specifies to the operating system the manner in which data packets sent by the operating system are to be distributed to the network interface card. Furthermore, there is currently no mechanism to align receive side scaling with send side scaling.

[0002] It is with respect to these and other general considerations that the aspects disclosed herein have been made.In addition, although relatively specific problems may be discussed, it should be understood that the examples should not be limited to solving specific problems identified in the background of this disclosure or elsewhere. Summary of the invention

[0003] Examples of the present disclosure describe systems and methods for send-side scaling. In an example, send-side configuration information is received by a host operating system from a client operating system, wherein the send-side scaling configuration information specifies a manner in which data packets sent by the host operating system are to be distributed to a network interface card of the host operating system. The send-side configuration scaling information is implemented in an outbound transmission table of the host operating system. When a data packet is received by the host operating system, the host operating system uses the outbound transmission table to evaluate the data packet. Based on the evaluation, the data packet is sent using a specified transmission queue of the network interface card.

[0004] Examples of the present disclosure also describe systems and methods for aligning receive-side scaling with transmit-side scaling. In an example, a host operating system constructs an inbound transmission table that includes a mapping of data packet information to a processor of the host operating system. The host operating system provides the inbound transmission table to a network interface card to be stored. When a data packet is received by the network interface card, the network interface card uses the inbound transmission table to evaluate the data packet. Based on the evaluation, the network interface card sends the data packet to a designated processor of the host operating system, and uses the designated processor to send the data packet to a corresponding transmission queue of another network interface card.

[0005] This summary is provided to introduce in simplified form a series of concepts that will be further described in the detailed description below. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Additional aspects, features, and / or advantages of the embodiments will be set forth in part in the subsequent description and will be apparent in part from the description or may be learned through practice of the disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] Examples are described with reference to the following figures.

[0007] Figure 1 An overview of an example host device for TSS and TSS / RSS alignment is shown.

[0008] Figure 2A and Figure 2B An example computing environment for implementing TSS is shown.

[0009] Figure 3 An example computing environment for aligning an RSS with a TSS is shown.

[0010] Figure 4 An example method for providing a TSS solution is shown.

[0011] Figure 5 An example method for aligning the RSS with the TSS is shown.

[0012] Figure 6 is a block diagram illustrating example physical components of a computing device for practicing various aspects of the present disclosure.

[0013] Fig. 7A and Figure 7B is a simplified block diagram of an example mobile computing device for practicing various aspects of the present disclosure.

[0014] Figure 8 is a simplified block diagram of an example distributed computing system for practicing various aspects of the present disclosure. DETAILED DESCRIPTION

[0015] Receive Side Scaling (RSS) is a network driver technology that enables efficient distribution of network received data packets in multi-processor systems. RSS enables an operating system (OS) to specify to a network interface card (NIC) the manner in which data packets received by the NIC are to be distributed among the central processing units (CPUs) of the operating system. RSS ensures that data packets in the same data stream are provided to the same CPU for processing, thereby preventing data packets from being delivered to and processed by the CPU out of order.

[0016] Currently, there is no send side scaling (TSS) mechanism in which the NIC specifies to the OS the manner in which the data packets sent by the OS will be distributed to the NIC. Instead, the OS randomly assigns data packets to the transmission queues of the NIC, and the NIC multiplexes and requeues the data packets on different transmission queues as needed. A transmission queue as used herein is a data structure implemented in the NIC and is used to sequentially send data packets from the NIC to a destination. The requeuing of data packets results in processing delays, additional memory consumption, and increases in data packet discards (e.g., lost or failed data packet transmissions).

[0017] Additionally, there is currently no mechanism for aligning the RSS with the TSS so that data packets received via the RSS can be sent according to the TSS configuration. On the contrary, even if the TSS mechanism is implemented by the OS, the CPU designated by the OS to receive data packets from the NIC may not process the same data packet type as the transmission queue associated with the CPU. For example, RSS can be used to specify that CPU 1 of the OS will be used to receive a certain type of data packet. TSS can be used to specify that transmission queue 3 of the NIC of the OS will be used to send a certain type of data packet. If CPU 1 is not aligned to transmission queue 3 (for example, if CPU 1 is aligned to transmission queue 1 and CPU 3 is aligned to transmission queue 3), it may be necessary for the NIC to requeue the data packets when receiving data packets from the OS.

[0018] Therefore, the present disclosure describes a system and method for providing a TSS solution. In an example, TSS configuration information is received by a host OS from an alternative OS (e.g., a client OS or an OS of a remote computing device or computing system). The TSS configuration information specifies the manner in which data packets sent by the host OS will be distributed to the NIC of the host OS, so that the NIC sends data packets to the alternative OS in a specific manner. For example, the client OS can specify that certain data packets are sent to a specific virtual CPU of the client OS. The TSS configuration information includes data packet information and transmission queue information. In an example, the data packet information relates to the type of data packet (e.g., original Internet Protocol (IP), Internet Control Message Protocol (ICMP), User Datagram Protocol (UDP), Transmission Control Protocol (TCP)) and / or one or more header fields of the data packet (e.g., IP version, source IP address, destination IP address, lifetime, network service category, flow label, payload length). The transmission queue information includes a transmission queue identifier (e.g., a queue number or a queue label).

[0019] The TSS configuration information is implemented in an outbound transmission data structure of the host OS, such as a data table, index, or list (collectively referred to herein as an "outbound transmission table"). In some examples, the TSS configuration information is implemented in the NIC of the host OS. The NIC can be a physical NIC or a virtual NIC. In other examples, the TSS configuration information is not implemented in the NIC. Implementing the TSS configuration information includes applying a hash function to the data packet information to calculate a hash value. The hash value and the transmission queue information are stored in the outbound transmission table. In one example, only a portion of the hash value (such as the least significant bit of the hash value) is stored with the transmission queue information. In some examples, the hash function is not applied to the data packet information, and the unhashed data packet information is stored in the outbound transmission table together with the transmission queue information.

[0020] When a data packet intended for an alternative OS is received by the host OS or generated by the host OS, the host OS uses the outbound transmission table to evaluate the data packet. As part of the evaluation, the host OS uses a data structure (such as a lookup table) that maps the data packet information to a hash value to perform a lookup of the data packet information of the data packet. The hash value for the data packet is compared with the hash value in the outbound transmission table to determine the transmission queue that will be used to send the data packet. In an example where the outbound transmission table does not store a hash value, the NIC compares the data packet information of the data packet with the data packet information stored in the outbound transmission table. The NIC then uses the determined transmission queue to send the data packet to the alternative OS.

[0021] The present disclosure also provides a system and method for aligning RSS with TSS. In an example, the host operating system constructs an inbound transmission data structure including RSS configuration information, such as a data table, index, or list (collectively referred to herein as an "inbound transmission table"). The RSS configuration information specifies the manner in which data packets sent to the host OS will be distributed to the CPUs of the host OS. For example, the host OS may specify that certain data packets are sent to specific CPUs of the host OS. The RSS configuration information includes data packet information (as described above) and CPU information. The CPU information includes a CPU identifier (e.g., a CPU number or a CPU tag).

[0022] The host OS constructs an inbound transmission table so that the RSS configuration information is aligned to the TSS configuration information stored by the host OS. As an example, the RSS configuration information may specify that a certain data packet type is to be sent to a specific physical CPU of the host OS. The TSS configuration information may specify that a certain data packet type is to be sent to a specific virtual CPU of the client OS using a specific transmission queue of the NIC of the host OS. Therefore, the host OS constructs an inbound transmission table so that the CPU for receiving a certain data packet type is aligned with the transmission queue for sending a certain data packet type. In the example, aligning the RSS configuration information with the TSS configuration information includes storing a mapping of the CPU of the host OS to the transmission queue of the NIC.

[0023] The host OS provides an inbound transmission table to the NIC of the host OS. The NIC may be a physical NIC or a virtual NIC. The NIC implements the inbound transmission table. Implementing the inbound transmission table may include applying a hash function to the data packet information in the inbound transmission table, as described above.

[0024] When a data packet intended for an alternate OS accessible to the host OS is received by the NIC, the NIC uses an inbound transmission table to evaluate the data packet. As described above, the evaluation may include calculating a hash value for the data packet information or performing a search for the data packet information. Based on the evaluation, the NIC sends the data packet to the designated CPU of the host OS. The designated CPU sends the data packet to the transmission queue aligned to the designated CPU. Then, the NIC (or a different NIC of the host OS) uses the determined transmission queue to send the data packet to the alternate OS. Therefore, the host OS does not need to requeue the data packet in order to send the data packet to the alternate OS.

[0025] Therefore, the present disclosure provides multiple technical benefits and improvements over previous data transmission solutions. These technical benefits and improvements include: providing a TSS mechanism to specify the manner in which data packets sent by the host OS will be distributed to the transmission queues of the NIC, aligning the RSS configuration with the TSS configuration to prevent unintentional requeuing of data packets, and reducing processing latency, memory consumption, and packet loss during transmission, etc.

[0026] Figure 1A host device for aligning a TSS and an RSS with the TSS is shown. The example host device 100 as presented is a combination of interdependent components that interact to form an integrated whole. The components of the host device 100 can be hardware components or software components (e.g., applications, application programming interfaces (APIs), modules, VMs, or runtime libraries) implemented on and / or executed by hardware components of the host device 100. In one example, the components of the host device 100 are distributed across multiple processing devices.

[0027] exist Figure 1 In the embodiment, host device 100 includes host physical resources 102, host OS 104, host application 106, hypervisor 108, and VM 110A, VM 110B, and VM 110C (collectively referred to as "(plurality) VM 110"). The scale and structure of the devices, environments, and systems discussed herein may vary and may include more than Figure 1 The components described in the subsequent figures may be additional or fewer than those described in the subsequent figures. In addition, although the VM will be discussed in the context of Figure 1 The examples in the following figures are provided, but the examples are equally applicable to other contexts, such as those that do not implement a virtual environment or virtual components. Examples of host device 100 include personal computers (PCs), server devices, mobile devices (e.g., smart phones, tablet computers, laptop computers, personal digital assistants (PDAs)), wearable devices (e.g., smart watches, smart glasses, fitness trackers, smart clothing, body-mounted devices, head-mounted displays), game consoles or devices, and Internet of Things (IoT) devices.

[0028] Host physical resources 102 include processing hardware (e.g., central processing unit (CPU), graphics processing unit (GPU), video card), memory, persistent storage, network interfaces (e.g., physical NIC and virtual NIC), etc. In the example, host physical resources 102 are directly accessible by host OS 104, host applications 106, and hypervisor 108, and are not directly accessible by VM(s) 110. Instead, VM(s) 110 access host physical resources 102 indirectly via components of host device 100, such as hypervisor 108.

[0029] The host OS 104 provides software for performing various computing functions, such as executing the host application 106, executing the hypervisor 108, scheduling tasks, and controlling peripheral devices (e.g., microphones, touch-based sensors, geolocation sensors, accelerometers, optical / magnetic sensors, gyroscopes, keyboards, and pointing / selection tools). The host OS 104 is configured to receive input data (e.g., audio input, touch input, text-based input, gesture input, and / or image input) from a user or computing device. In some examples, the input data corresponds to user interaction with the host application 106 or the hypervisor 108. In other examples, the input data corresponds to automated interaction with the service or host application 106, such as automatic (e.g., non-manual) execution of a script or set of commands at a scheduled time or in response to a predetermined event.

[0030] The host application 106 may be implemented locally on the host device 100 or remotely accessible by the host device 100 via a network (e.g., a private area network (PAN), a local area network (LAN), a wide area network (WAN), etc.). The host application 106 provides access to a collection of software functions and / or hardware functions. Examples of the host application 106 include applications and services related to word processing, spreadsheets, presentation software, document reading, social media software or platforms, search engines, media software or platforms, multimedia players, content design software or tools, database software or tools, provisioning software, and alarm or notification software.

[0031] Hypervisor 108 is software that creates, executes, and manages VM(s) 110 within the execution environment of host device 100. Hypervisor 108 exposes VM(s) 110 to one or more networks to enable VM(s) 110 to communicate with each other and with other devices or components of host device 100 or other devices or components external to host device 100. In an example, hypervisor 108 provides VM(s) 110 with access to host physical resources 102 and / or physical resources of computing devices external to host device 100.

[0032] (Multiple) VM 110 is a computing resource that uses software rather than physical computing devices to execute and deploy applications. (Multiple) VM 110 includes client OS 112A, client OS 112B and client OS 112C (collectively referred to as "client OS 112"). Each client OS 112 includes kernel space and user space. Kernel space is reserved for executing privileged OS kernels, kernel extensions and most device drivers. User space is reserved for executing application software and non-privileged device drivers. In the example, client OS 112 implements or has access to applications (such as described about host application 106). Each client OS 112 can include or provide access to different application sets. A set as used herein can include one or more items.

[0033] Figure 2A , Figure 2B and Figure 3 A computing environment for implementing a TSS and aligning an RSS with the TSS is shown. In an example, the computing environment is implemented in a computing device, such as host device 100. However, alternative implementations of the computing environment are contemplated.

[0034] Figure 2A A computing environment implementing TSS is shown. Example computing environment 200 includes host OS 202. Host OS 202 includes client OS 204, virtual NIC 206, outbound transmission table (OTT) 208, and physical CPU 210A to physical CPU 210D. Client OS 204 includes virtual CPU 212A to virtual CPU 212D. Virtual CPU represents a portion or share of a physical CPU assigned to the client OS. Each virtual CPU in virtual CPU 212A to virtual CPU 212D can be configured to receive and process one or more data packet types. Virtual NIC 206 includes transmission queue (TXQ) 214A to transmission queue 214D. Transmission queue 214A to transmission queue 214D send data packets to / from host OS 202 and client OS 204.

[0035] exist Figure 2AIn the embodiment of the present invention, the client OS 204 is configured so that each of the virtual CPUs 212A to 212D is configured to process a certain data packet type. For example, the virtual CPU 212A processes a first packet data type, the virtual CPU 212B processes a second packet data type, and so on. In order to prevent requeuing of data packets received by the virtual NIC 206 and intended for the client OS 204, each of the virtual CPUs 212A to 212D is aligned to a corresponding one of the transmission queues 214A to 214D, so that data packets sent using the transmission queue are directly provided to the virtual CPU aligned to the transmission queue. For example, the transmission queue 214A is aligned to the virtual CPU 212A, the transmission queue 214B is aligned to the virtual CPU 212B, the transmission queue 214C is aligned to the virtual CPU 212C, and the transmission queue 214D is aligned to the virtual CPU 212D.

[0036] Outbound transmission table 208 includes TSS configuration information received from client OS 204. The TSS configuration information specifies the manner in which data packets sent by physical CPU 210A to physical CPU D to client OS 204 are to be distributed to transmission queues 214A to 214D. As an example, outbound transmission table 208 specifies that a first data packet type is to be sent to transmission queue 214A, a second data packet type is to be sent to transmission queue 214B, a third data packet type is to be sent to transmission queue 214C, and a fourth data packet type is to be sent to transmission queue 214D. In some examples, multiple data packet types may be sent to each of transmission queues 214A to 214D, and the same data packet type may be sent to two or more of transmission queues 214A to 214D.

[0037] In some examples, outbound transmission table 208 includes TSS configuration information for multiple NICs. Figure 2B , computing environment 200 also includes physical NIC 216. Physical NIC 216 includes transmit queues 218A to 218D. Outbound transmit table 208 includes TSS configuration information for virtual NIC 206 and physical NIC 216. The TSS configuration information for the physical NIC specifies the manner in which data packets sent by physical CPU 210A to physical CPU 210D to a remote computing device or computing system will be distributed to transmit queues 218A to 218D.

[0038] Figure 3 The computing environment for realizing the alignment of RSS and TSS is shown. Figure 3 In the embodiment of the present invention, the physical NIC 216 also includes an inbound transmission table 220. The inbound transmission table (ITT) 220 includes RSS configuration information received from the host OS 202. The RSS configuration information specifies the manner in which data packets received by the host OS 202 will be distributed to the physical CPUs 210A to 210D. As an example, the inbound transmission table 220 specifies that a first data packet type will be sent to the physical CPU 210A using the transmission queue 218A, a second data packet type will be sent to the physical CPU 210B using the transmission queue 218B, a third data packet type will be sent to the physical CPU 210C using the transmission queue 218C, and a fourth data packet type will be sent to the physical CPU 210D using the transmission queue 218D. In some examples, multiple data packet types can be sent to each physical CPU in the physical CPU 210A to 210D, and the same data packet type can be sent to two or more physical CPUs in the physical CPU 210A to 210D.

[0039] exist Figure 3 In the embodiment of the present invention, the host OS 202 is configured so that the RSS configuration information in the inbound transmission table 220 is aligned with the TSS configuration information in the outbound transmission table 208. Continuing with the above example, the physical CPU 210A is aligned to the transmission queue 214A, the physical CPU 210B is aligned to the transmission queue 214B, the physical CPU 210C is aligned to the transmission queue 214C, and the physical CPU 210D is aligned to the transmission queue 214D. Therefore, the data packets received by the physical NIC 216 can be sent between the physical CPU 210A to the physical CPU 210D and the virtual CPU 212A to the virtual CPU 212D, so that the data packets do not need to be re-queued to be sent to a different one of the physical CPUs 210A to the physical CPU 210D or a different one of the virtual CPUs 212A to the virtual CPU 212D.

[0040] Having described one or more devices and systems that can employ various aspects of the present disclosure, methods for performing these aspects will now be described. In an example, methods 400 and 500 can be performed by a device (such as host device 100) or a computing environment (such as Figure 2A , Figure 2B as well as Figure 3 However, the methods 400 and 500 are not limited to this example.

[0041] Figure 4An example method for providing a TSS solution is shown. Example method 400 begins at operation 402, where TSS configuration information is received by a host OS (such as host OS 202). The TSS configuration information can be provided by a client OS (such as client OS 204) or by an alternative OS of a remote computing device or computing system. The TSS configuration information specifies the manner in which data packets sent by the host OS will be distributed to the NIC (such as virtual NIC 206 or physical NIC 216) of the host OS. In one example, the TSS configuration information specifies the data packet type (e.g., raw IP, ICMP, UDP, TCP) to be distributed to each transmission queue of the NIC. Alternatively, the TSS configuration information can specify data packet header fields that will be used to distribute data packets to each transmission queue of the NIC.

[0042] At operation 404, the TSS configuration information is implemented in an outbound transmission table (such as outbound transmission table 208). In an example, implementing the TSS configuration information includes applying a hash function to data packet header fields or other data packet information to calculate a hash value. The hash value (or portion thereof) and the transmission queue information are stored in the outbound transmission table such that the hash value is associated with a particular transmission queue of the NIC, such as transmission queues 214A to transmission queue 214D and transmission queues 218A to transmission queue 218D. As a specific example, the hash value for the original IP data packet is associated with transmission queue 1 of the virtual NIC (e.g., mapped to transmission queue 1 of the virtual NIC), the hash value for the ICMP data packet is associated with transmission queue 2 of the virtual NIC, and so on.

[0043] At operation 406, a data packet is received by the host OS. The data packet may be intended for the client OS and may be generated by the host OS and received via the NIC. In an example, the data packet is received by a physical CPU of the host OS (such as physical CPU 210A to physical CPU 210D). The data packet has a data packet type and includes data packet information, such as a header segment and a body segment. The header segment includes header fields, and the body segment includes a payload (e.g., a portion of the data packet that is intended to be an actual message).

[0044] At operation 408, the data packet is evaluated using the outbound transmission table. In an example, evaluating the data packet includes providing the data packet to the NIC by the host OS. The NIC calculates a hash value for data packet information of the data packet, or performs a lookup of the data packet information using a data structure (such as a lookup table) that maps the data packet information to a hash value. The hash value for the data packet is compared with the hash value in the outbound transmission table to determine a transmission queue that will be used to send the data packet to the client OS. In at least one example, the outbound transmission table includes the data packet information instead of or in addition to the hash value for the data packet information. In such an example, evaluating the outbound transmission table includes performing a lookup of the data packet information of the data packet, as described above.

[0045] At operation 410, the data packets are sent to the client OS using the determined transmission queues. In an example, the determined transmission queues are aligned to the virtual CPUs of the client OS (such as one or more of virtual CPUs 212A to 212D). Each virtual CPU can be configured to process a specific data packet type according to TSS configuration information provided by the client OS to the host OS. As a specific example, a first virtual CPU is configured to receive raw IP data packets, a second virtual CPU is configured to receive ICMP data packets, and so on.

[0046] Figure 5 An example method for aligning RSS with TSS is shown. Example method 500 begins at operation 502, where a host OS (such as host OS 202) constructs an inbound transmission table (such as inbound transmission table 220). The inbound transmission table is constructed based on RSS configuration information for the host OS and TSS configuration information provided by a client OS (such as client OS 204) or an alternative OS of a remote computing device or computing system. The RSS configuration information specifies the manner in which data packets sent to the host OS will be distributed to the CPUs of the host OS, while the TSS configuration information specifies the manner in which data packets sent by the host OS will be distributed to the NICs of the host OS.

[0047] The host OS constructs an inbound transmission table so that the RSS configuration information is aligned to the TSS configuration information. As an example, the TSS configuration information may specify that a certain data packet type (e.g., raw IP, ICMP, UDP, TCP) will be sent to a specific virtual CPU of the client OS using a specific transmission queue of a NIC (such as virtual NIC 206 or physical NIC 216). The RSS configuration information may specify that a certain data packet type will be received by a specific physical CPU of the host OS (such as physical CPU 210A to physical CPU 210D). Therefore, the host OS constructs an inbound transmission table so that a specific physical CPU is aligned to a specific transmission queue of the NIC. In some examples, the inbound transmission table stores a mapping of physical CPUs to transmission queues.

[0048] At operation 504, the host OS provides the NIC with an inbound transmission table. The NIC may store the inbound transmission table as a new data table. Alternatively, the NIC may use the inbound transmission table to update an existing table. As an example, the NIC may include a data table that includes previously received RSS configuration information. The data table may be an indirect table representing a mapping between a hash value and transmission queue information. The indirect table may be indexed using a number of least significant bits of a set of hash values ​​corresponding to data packet information. In this example, the NIC updates the mapping in the indirect table using the correlation / mapping in the inbound transmission table.

[0049] At operation 506, the physical CPU of the host OS receives a data packet based on the inbound transmission table. The data packet may be intended for the client OS and may be received via the NIC. The data packet has a data packet type that includes data packet information, such as information about the client OS. Figure 4 as described in operation 406 .

[0050] At operation 508, the data packet is sent to the transmission queue that is aligned to the physical CPU. In an example, the transmission queue is aligned to the physical CPU according to the inbound transmission table. As a specific example, both the transmission queue and the physical CPU are configured to receive and send the same data packet type (e.g., the data packet type of the received data packet). Therefore, the physical CPU sends the data packet to the transmission queue, and the transmission queue sends the data packet to the virtual CPU of the client OS, where the virtual CPU is configured to receive and send the data packet type of the received data packet.

[0051] Figures 6 to 8 and the associated description provide a discussion of various operating environments in which various aspects of the present disclosure may be practiced. Figures 6 to 8The devices and systems shown and discussed are for purposes of example and explanation, and it is understood that a wide variety of computing device configurations may be utilized for practicing the various aspects of the present disclosure described herein.

[0052] Figure 6 600 with which various aspects of the present disclosure may be practiced. The computing device components described below are applicable to the computing devices and systems described above. In a basic configuration, the computing device 600 includes a processing system 602, which includes at least one processing unit and a system memory 604. Depending on the configuration and type of the computing device, the system memory 604 may include volatile storage (e.g., random access memory), non-volatile storage (e.g., read-only memory), flash memory, or any combination of such memories.

[0053] System memory 604 includes operating system 605 and one or more program modules 606 suitable for running software applications 620, such as one or more components supported by the system described herein. For example, operating system 605 is suitable for controlling the operation of computing device 600.

[0054] In addition, embodiments of the present disclosure may be practiced in conjunction with a graphics library, other operating systems, or any other application. Figure 6 608. The computing device 600 may have additional features or functionality. For example, the computing device 600 may include additional data storage devices (removable and / or non-removable) such as, for example, magnetic disks, optical disks, tapes, and other computer-readable media. Such additional storage devices may be used to store data. Figure 6 607 and a non-removable storage device 610.

[0055] The term computer-readable media as used herein includes computer storage media. Computer storage media include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information (such as computer-readable instructions, data structures or program modules). System memory 604, removable storage device 607 and non-removable storage device 610 are all examples of computer storage media (e.g., memory storage devices). Computer storage media include random access memory (RAM), read-only memory (ROM), electrically erasable ROM (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical storage device, cassette, magnetic tape, disk storage or other magnetic storage device, or any other product that can be used to store information and can be accessed by computing device 600. Any such computer storage medium can be part of computing device 600. Computer storage media do not include carrier waves or other propagated or modulated data signals.

[0056] Communication media may be embodied by computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transmission mechanism, and includes any information delivery media. The term "modulated data signal" describes a signal that has one or more characteristics set or changed in such a manner as to encode information in the signal. By way of example, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media.

[0057] As stated above, several program modules and data files may be stored in system memory 604. When executed on processing system 602, program modules 606 (e.g., applications 620) perform processes including various aspects as described herein. Other program modules that may be used in accordance with various aspects of the present disclosure may include email and contact applications, word processing applications, spreadsheet applications, database applications, slide presentation applications, drawing or computer-assisted applications, and the like.

[0058] In addition, embodiments of the present disclosure may be practiced in circuits including discrete electronic components, packaged or integrated electronic chips containing logic gates, circuits utilizing microprocessors, or single chips containing electronic components or microprocessors. For example, embodiments of the present disclosure may be practiced via a system on a chip (SOC), wherein Figure 6Each component or multiple components of the components shown in are integrated into a single integrated circuit. This SOC device may include one or more processing units, a graphics unit, a communication unit, a system virtualization unit, and various application functions, all of which are integrated (or "burned") onto a chip substrate as a single integrated circuit. When operated via the SOC, the functions described herein regarding the ability of the client switching protocol can be operated via application-specific logic integrated with other components of the computing device 600 on a single integrated circuit (chip). Embodiments of the present disclosure may also be practiced using other technologies (including mechanical, optical, fluid, and quantum technologies) capable of performing logical operations (such as, for example, AND, OR, and NOT). In addition, embodiments of the present disclosure may be practiced in a general-purpose computer or in any other circuit or system.

[0059] The computing device 600 may also have one or more input devices 612, such as a keyboard, a mouse, a pen, a sound or voice input device, a touch or slide input device, etc. Output device(s) 614 may also be included, such as a display, a speaker, a printer, etc. The above devices are examples and other devices may be used. The computing device 600 includes one or more communication connections 616 that allow communication with other computing devices 640. Examples of suitable communication connections 616 include radio frequency (RF) transmitters, receivers, and / or transceiver circuitry; universal serial bus (USB), parallel ports, and / or serial ports.

[0060] Fig. 7A and Figure 7B A mobile computing device 700 is shown, such as a mobile phone (e.g., a smart phone), a wearable computer (such as a smart watch), a tablet computer, a laptop computer, etc., with which embodiments of the present disclosure may be practiced. In some aspects, the client device is a mobile computing device. Fig. 7A , one aspect of a mobile computing device 700 for implementing these aspects is shown. In a basic configuration, the mobile computing device 700 is a handheld computer having both input elements and output elements. The mobile computing device 700 typically includes a display 705 and one or more input buttons 710 that allow a user to enter information into the mobile computing device 700. The display 705 of the mobile computing device 700 may also be used as an input device (e.g., a touch screen display).

[0061] If included, the optional side input element 715 allows further user input. The side input element 715 can be a rotary switch, a button, or any other type of manual input element. In alternative aspects, the mobile computing device 700 incorporates more or fewer input elements. For example, in some embodiments, the display 705 may not be a touch screen.

[0062] In yet another alternative embodiment, the mobile computing device 700 is a mobile phone, such as a cellular phone. The mobile computing device 700 may also include an optional keypad 735. The optional keypad 735 is a physical keypad or a "soft" keypad generated on a touch screen display.

[0063] In various embodiments, output elements include a display 705 for displaying a graphical user interface (GUI), a visual indicator 720 (e.g., a light emitting diode), and / or an audio transducer 725 (e.g., a speaker). In some aspects, the mobile computing device 700 incorporates a vibration transducer for providing tactile feedback to the user. In yet another aspect, the mobile computing device 700 incorporates input ports and / or output ports for sending or receiving signals to or from external devices, such as an audio input (e.g., a microphone jack), an audio output (e.g., a headphone jack), and a video output (e.g., an HDMI port).

[0064] Figure 7B 702 is a block diagram illustrating the architecture of one aspect of a mobile computing device. In other words, a mobile computing device may incorporate system (e.g., architecture) 702 to implement some aspects. In one embodiment, system 702 is implemented as a "smart phone" capable of running one or more applications (e.g., browser, email, calendar, contact manager, messaging client, game, and media client / player). In some aspects, system 702 is integrated into a computing device, such as an integrated personal digital assistant (PDA) and wireless phone.

[0065] One or more application programs 766 may be loaded into the memory 762 and run on or in association with the operating system (OS) 764. Examples of application programs include a phone dialer, an email program, a personal information management (PIM) program, a word processing program, a spreadsheet program, an Internet browser program, a messaging program, and the like. The system 702 also includes a non-volatile storage area 768 within the memory 762. The non-volatile storage area 768 is used to store persistent information that should not be lost if the system 702 loses power. The application programs 766 may use information and store the information in the non-volatile storage area 768, such as emails or other messages used by the email application, and the like. A synchronization application (not shown) also resides on the system 702 and is programmed to interact with a corresponding synchronization application residing on the host computer to keep the information stored in the non-volatile storage area 768 synchronized with the corresponding information stored at the host computer. As should be appreciated, other applications may be loaded into memory 762 and executed on the mobile computing devices described herein (eg, search engines, extractor modules, relevance ranking modules, answer scoring modules).

[0066] System 702 has a power source 770, which can be implemented as one or more batteries. Power source 770 can also include an external power source, such as an AC adapter or a powered docking cradle to replenish or recharge the batteries.

[0067] The system 702 also includes a radio interface layer 772 that performs the function of sending and receiving radio frequency communications. The radio interface layer 772 facilitates wireless connectivity between the system 702 and the "outside world" via a communications carrier or service provider. Transmissions to and from the radio interface layer 772 are performed under the control of the operating system 764. In other words, communications received by the radio interface layer 772 are disseminated to the application 766 via the OS 764, and vice versa.

[0068] A visual indicator (e.g., a light emitting diode (LED) 720) is used to provide a visual notification, and / or an audio interface 774 is used to generate an audible notification via an audio transducer 725. In the illustrated embodiment, the visual indicator 720 is a light emitting diode (LED), and the audio transducer 725 is a speaker. These devices can be directly coupled to a power supply 770 so that when the device is activated, even if (multiple) processors (e.g., processor 760 and / or dedicated processor 761) and other components may be turned off to save battery power, the device remains turned on for a duration indicated by the notification mechanism. The LED can be programmed to remain turned on indefinitely until the user takes action to indicate the power-on state of the device. The audio interface 774 is used to provide an audible signal to the user and to receive an audible signal from the user. For example, in addition to being coupled to the audio transducer 725, the audio interface 774 can also be coupled to a microphone to receive an audible input, such as to facilitate a telephone conversation. According to an embodiment of the present disclosure, the microphone is also used as an audio sensor to facilitate the control of notifications, as will be described below. System 702 also includes a video interface 776 that enables operation of peripheral port 730 (eg, an on-board camera) to record still images, video streams, and the like.

[0069] The mobile computing device 700 implementing the system 702 may have additional features or functionality. For example, the mobile computing device 700 may also include additional data storage devices (removable and / or non-removable) such as magnetic disks, optical disks, or tapes. Such additional storage devices may be used to store data (e.g., data or other data) on the mobile computing device 700. Figure 7B , shown by non-volatile storage area 768.

[0070] As described above, data / information generated or captured by the mobile computing device 700 and stored via the system 702 may be stored locally on the mobile computing device 700, or the data may be stored on any number of storage media that may be accessed by the device via the radio interface layer 772 or via a wired connection between the mobile computing device 700 and a separate computing device associated with the mobile computing device 700 (e.g., a server computer in a distributed computing network such as the Internet). As should be appreciated, such data / information may be accessed via the mobile computing device 700 via the wireless interface layer 772 or via a distributed computing network. Similarly, such data may be readily transferred between computing devices for storage and use according to well-known data transfer and storage means, including electronic mail and collaborative data sharing systems.

[0071] Figure 8One aspect of the architecture of a system for processing data received at a computing system from a remote source, such as a personal computer 804, a tablet computing device 806, or a mobile computing device 808, as described above, is shown. The content displayed at the server device 802 can be stored in different communication channels or other storage types. For example, a directory service 822, a web portal 824, a mailbox service 826, an instant messaging storage 828, or a social networking service 830 can be used to store various documents.

[0072] The input evaluation service 820 may be employed by a client communicating with the server device 802, and / or the input evaluation service 820 may be employed by the server device 802. The server device 802 provides data to and from client computing devices, such as personal computers 804, tablet computing devices 806, and / or mobile computing devices 808 (e.g., smart phones), over the network 815. By way of example, the computer system described above may be embodied in the personal computer 804, the tablet computing device 806, and / or the mobile computing device 808 (e.g., smart phones). In addition to receiving graphics data that may be pre-processed at a graphics originating system, or post-processed at a receiving computing system, any of these embodiments of the computing device may obtain content from the data store 816.

[0073] As will be understood from the foregoing disclosure, one example of the present technology relates to a computer-implemented method. The method includes: receiving a client transmit configuration at a host operating system (OS) from a client OS; implementing a client transmit configuration transmit table in an outbound transmit table at the host OS; receiving a data packet at the host OS; determining a transmit queue for transmitting the data packet to the client OS by evaluating the data packet using the outbound transmit table; and transmitting the data packet to the client OS using the transmit queue.

[0074] In another example, the present technology relates to an alternative computer-implemented method. The method includes: constructing an inbound transmission table by a host operating system (OS), the inbound transmission table including a mapping of data packet types to a processor set of the host OS; providing the inbound transmission table to a network interface card (NIC); receiving a data packet based on the mapping at a processor in the processor set; and sending the data packet to a transmission queue associated with a client operating system (OS), wherein the processor is aligned to the transmission queue.

[0075] In another example, the present technology relates to a system, comprising: a processor system; and a memory coupled to the processor system, the memory comprising computer executable instructions, which when executed by the processor system, perform operations, the operations comprising: receiving a transmit side scaling (TSS) send configuration from a client OS at a host operating system (OS); implementing a TSS send configuration transmission table in an outbound send table at the host OS; receiving a data packet at the host OS, wherein the data packet is for the client OS; determining a transmission queue associated with header data stored in an outbound transmission table by matching header data associated with the data packet with header data stored in the outbound transmission table; and sending the data packet to the client OS using the transmission queue.

[0076] For example, according to various aspects of the present disclosure, the above reference method, system and computer program product block diagram and / or operation diagram describes various aspects of the present disclosure. The functions / actions indicated in the frame may not appear in the order shown in any flow chart. For example, depending on the functions / actions involved, two frames shown in succession may actually be executed substantially simultaneously, or the frame may sometimes be executed in reverse order.

[0077] The description and illustration of one or more aspects provided in this application are not intended to limit or constrain the scope of the disclosure as claimed in any way. The aspects, examples and details provided in this application are considered to be sufficient to convey ownership and enable others to make and use the best mode of the disclosure claimed. The disclosure claimed should not be interpreted as being limited to any aspect, example or detail provided in this application. Whether displayed and described in combination or individually, various features (both structural and method) are intended to be selectively included or omitted to produce an embodiment with a specific feature set. The description and illustration of this application have been provided, and those skilled in the art can envision changes, modifications and alternative aspects that fall within the spirit of the broader aspects of the overall inventive concept embodied in this application, which do not depart from the broader scope of the disclosure claimed.

Claims

1. A method comprising: receiving, at a host operating system (OS), a client-sent configuration from a client OS; Implementing, at the host OS, the client transmission configuration in the outbound transmission table; receiving a data packet at the host OS; Determining a transmit queue for sending the data packet to the client OS by evaluating the data packet using the outbound transmit table; as well as The data packet is sent to the client OS using the transmit queue.

2. The method of claim 1, wherein the client sends a configuration comprising data packet information associated with a data packet type.

3. The method of claim 2, wherein the client transmit configuration further comprises a set of transmit queues for sending data packets to the client OS. The method of claim 3 , wherein each transmit queue in the set of transmit queues is aligned to a processor of the client OS.

5. The method of claim 3, wherein the data packet information associated with each data packet type is associated with a corresponding transmit queue in the set of transmit queues.

6. The method according to claim 5, wherein implementing the client sending configuration further comprises: Creating a hash value for each data packet type; as well as Each hash value and the corresponding transmit queue associated with the hash value are stored in the outbound transmit table such that the hash value is mapped to the corresponding transmit queue.

7. The method of claim 1, wherein receiving the data packet at the host OS comprises receiving the data packet via a physical network interface card of the host OS, wherein the data packet is intended for the client OS.

8. The method of claim 1 , wherein using the outbound transmission table to evaluate the data packet comprises: matching a hash value of the data packet with a hash value stored in the outbound transmission table; identifying the transmit queue as associated with the hash value stored in the outbound transmit table; as well as The transmit queue is determined based on correlating the transmit queue with the hash value.

9. The method of claim 8, wherein matching the hash value of the data packet with the hash value stored in the outbound transmission table comprises: identifying a set of fields in a header of the data packet; A hash function is applied to the set of fields to generate the hash value.

10. The method of claim 1, wherein sending the data packet to the client OS using the transmit queue comprises: identifying a first processor in a set of processors for the client OS, wherein the first processor is aligned with the transmit queue and a second processor in the set of processors for the client OS is not aligned to the transmit queue; as well as The data packet is sent to the client OS so that the data packet is provided to the first processor.

11. The method of claim 1, wherein the outbound transmission table is an indirection table.

12. A method comprising: constructing, by a host operating system (OS), an inbound transmission table including a mapping of data packet types to a set of processors of the host OS; providing the inbound transmission table to a network interface card (NIC); receiving, at a processor in the set of processors, a data packet based on the mapping; as well as The data packet is sent to a transmit queue associated with a client operating system (OS), wherein the processor is aligned to the transmit queue.

13. The method of claim 12, wherein constructing the inbound transmission table comprises: creating a hash value for each of the data packet types; associating each hash value with a processor in the set of processors; as well as Each hash value and the processor associated with the hash value are stored in the inbound transmission table.

14. The method of claim 12, wherein: The host OS includes a set of transmit queues for sending data packets to the client OS, the set of transmit queues including the transmit queue; and Each transmit queue in the set of transmit queues is aligned to a corresponding processor in the set of processors.

15. A system comprising: Processor system; as well as a memory coupled to the processor system, the memory comprising computer executable instructions that, when executed by the processor system, perform operations comprising: receiving, at a host operating system (OS), a send side scaling (TSS) send configuration from a client OS; Implementing, at the host OS, the TSS sending configuration in the outbound transmission table; receiving a data packet at the host OS, wherein the data packet is intended for the client OS; determining a transmission queue associated with the header data stored in the outbound transmission table by matching header data associated with the data packet with header data stored in the outbound transmission table; and The data packet is sent to the client OS using the transmit queue.

Images