Patent Description:
As with TCP, different operations performed during transmission and reception of data packets using QUIC, particularly larger data packets, could benefit from offloading to hardware. However, known hardware offload arrangements implemented for TCP protocols cannot be used in QUIC, which uses the connectionless UDP protocol.

<CIT> discloses a method for offloading a secure protocol connection, involving establishing the secure protocol connection between a host system and a remote peer, offloading the secure protocol connection to a network interface card (NIC) to obtain an offloaded secure protocol connection, determining whether a packet is associated with the offloaded secure protocol connection, and if the packet is associated with the offloaded secure protocol connection, identifying the offloaded secure protocol connection, performing cryptographic operations on the packet using at least one secret key to obtain a processed packet, and returning a status of the processed packet to the host system.

A computerized method for hardware offloading comprises programing a network interface card with a mapping between (i) a connection identification (CID) for one or more QUIC data packets and (ii) a symmetric key and a crypto algorithm. The computerized method further comprises identifying the CID for one or more QUIC data packets and sending the CID to the network interface card. The network interface card is configured to select one or more processors of a plurality of processors to process the QUIC data packets, the one or more processors being selected using a mapping in a hash table based on the CID, and process the QUIC data packets using the selected one or more processors, the processing comprising performing at least one of (i) receiving and decrypting the one or more QUIC data packets over a network and (ii) encrypting and transmitting the one or more QUIC data packets over the network, the symmetric key and the crypto algorithm for the decryption or encryption being identified by the network interface card based on the CID for the one or more QUIC data packets. Processing of larger data packets for receiving and transmitting is provided in some examples.

In the figures, the systems are illustrated as schematic drawings. The drawings may not be to scale.

The computing devices and methods described herein are configured to offload one or more processes to hardware when communicating using the QUIC transport layer protocol. In some examples, receive side scaling (RSS), large send offload (LSO), receive segment coalescing (RSC), and crypto (encryption/decryption) offload are performed in hardware for QUIC communications. A connection identification (ID), also referred to as CID, is hashed from a QUIC packet to facilitate performing different processes, including routing the data traffic to a particular processor (e.g., one of a plurality of central processing units (CPUs)) to perform the different hardware offloaded processes. As a result of offloading tasks, including to different processors, a software control complexity and processing burden (such as for individual processors) is reduced.

It should be noted that hashing is one example method for mapping data traffic. The present disclosure is operable with other mapping methodologies, such as mapping tables.

The hardware of some examples is configured as part of a network interface card to perform at least one of RSS, LSO, RSC or crypto operations, instead of performing these operations in software. As a result, functions associated with these processes are performed more efficiently than when performed by software running on a general-purpose CPU. Additionally, processing data packets for communication using the unique connection identifier (CID) or the unique CID in combination with unique <NUM>-tuples (defining source and destination IP addresses) that identifies a unique local socket address assigned to a socket number in the UDP, allows for the offloading to hardware of functions.

Thus, various examples allow for offloading one or more functions from software to hardware to process data packets for transmission and/or receipt. For example, the present disclosure allows for offloading of one or more computing tasks that are typically performed by a host processor in software, to a specific hardware component, thereby freeing up host processor resources and increasing the overall efficiency of the computer system.

<FIG> illustrates a channel <NUM> established between user devices <NUM> and <NUM> via a network <NUM>. The network <NUM> has a plurality of network layers, illustrated as a link layer <NUM> (lowest layer), a network layer <NUM> (illustrated as an Internet Protocol (IP) layer) above the link layer <NUM>, a transport layer <NUM> (which in various examples is a QUIC transport layer) above the network layer <NUM>, and an application layer <NUM> above the transport layer <NUM>. The network layers in one example are provided in accordance with a UDP/IP suite utilizing the QUIC transport layer protocol. The application layer <NUM> provides process-to-process communication between processes running on different hosts (e.g., general purpose computer devices) connected to the network <NUM>, such as the user devices <NUM> and <NUM>. The transport layer <NUM> provides end-to-end communication between different hosts, including providing end-to-end connections(s) between hosts for use by the processes. The network (internet) layer <NUM> provides routing (e.g., communication between different individual portions of the network <NUM>) via routers. The link layer <NUM> provides communication between physical network addresses, such as Medium Access Control (MAC) addresses of adjacent nodes in the network <NUM>, such as for the same individual network via network switches and/or hubs, which operate at the link layer <NUM>.

In one example, the channel <NUM> is an application-layer channel at the application layer <NUM> of the network <NUM>, established between instances of clients, running on the user devices <NUM> and <NUM>. That is, the channel <NUM> is a process-to-process channel between the client instances on the user devices <NUM> and <NUM>.

The (application-layer) channel <NUM> in some examples is established via one or more transport layer channels between the devices user <NUM> and <NUM>, often referred to as end-to-end or host-to-host channel(s). Each transport layer channel is established via network layer channel(s) between one of user devices <NUM> and <NUM> and a router, or between pairs of routers, which are established via link layer channels within the individual networks of, for example, the Internet. It should be noted that the channel <NUM> can be a unidirectional channel or a bidirectional channel.

With reference to <FIG>, a computer system <NUM> in one example includes one or more hardware components configured to perform operations offloaded from software, such as RSS, LSO, RSC and crypto offload for QUIC communications. The computer system <NUM> may be any type of computing device connected to a network. One or more examples increase the efficiency with which packets communicated over a network using QUIC are processed. Accordingly, in some examples, the computer <NUM> is used in applications that require the computer <NUM> to send or receive numerous data packets over the network, including larger sized data packets. For example, the computer <NUM> can be a network server.

The computer system <NUM> in some examples is connected to other computers through a physical network link. The physical network link can be any suitable transmission medium, such as copper wire, optical fiber or, in the case of a wireless network, air.

In the illustrated example, the computer <NUM> includes a network interface card (NIC) <NUM> configured to send and receive packets over a physical network link <NUM>. The specific construction of network interface card <NUM> depends on the characteristics of physical network link <NUM>. However, the network interface card <NUM> is implemented in one example with circuitry as is used in the data transmission technology to transmit and receive packets over a physical network link.

The network interface card <NUM> in one example is a modular unit implemented on a printed circuit board that is coupled to (e.g., inserted in) the computer <NUM>. However, in some examples, the network interface card <NUM> is a logical device that is implemented in circuitry resident on a module that performs functions other than those of network interface card <NUM>. Thus, the network interface card <NUM> can be implemented in different suitable ways.

In the illustrated example, the network interface card <NUM> additionally includes logic that performs processing on data packets to be sent or received over the physical network link <NUM>. In one example, this logic is embodied in electronic circuitry on the network interface card <NUM> to perform some or all of the offloaded software operations. In some examples, different hardware configurations of the network interface card <NUM> are provided separate from the network interface card <NUM> to perform the offloaded functions.

The network interface card <NUM> includes an integrated circuit <NUM> and/or other hardware, which contains circuitry to perform the offloaded processing. Additionally, or optionally, the present disclosure contemplates offloading the software functions to other hardware, such as one or more processors, illustrated as CPUs <NUM>. For example, in one example, traffic is spread across the CPUs <NUM> with a hashing process that utilizes the CID from QUIC and optionally values from the IP address as described in more detail herein. In some examples, the CPUs <NUM> form part of the network interface card <NUM>.

The integrated circuit <NUM> in some examples is a programmable logic device, such as one or more field programmable gate arrays, or can be one or more application-specific integrated circuits or other suitable integrated circuits configured to perform a particular offloaded function. As should be appreciated, the CPUs <NUM> can be hardware components each configured to perform one or more of the offloaded functions from software. It should be appreciated that the integrated circuit <NUM> and the CPUs <NUM> in some examples, in addition to performing processing on data packets for send and/or receive operations, perform other functions, which may or may not be related to send and/or receive operations.

Once the network interface card <NUM> receives a packet and performs processing on the packet, the packet can be further processed by software within the computer <NUM>. For example, the computer <NUM> includes an operating system <NUM> that processes packets received by the network interface card <NUM>. The operating system <NUM> in some examples is implemented in layers, with each layer containing one or more modules. In one example, the computer <NUM> operates according to a layered protocol and processing performed for each layer of the protocol is implemented in a separate module. However, in some examples, the operations performed by multiple modules may be performed in a single module.

In operation in one example, where the processing of data packets depends on the information within a packet or information that is applicable to certain packets, the processing is offloaded from software to hardware. For example, a determination may be made whether the data stored in a packet buffer within the network interface card <NUM> has fields characteristic of headers for Ethernet (ETH), IP and UDP headers contiguously located in the buffer, which can be processed in part by hardware. Once the logic within network interface card <NUM> or the CPUs <NUM> complete processing on a received packet, the packet can be transferred to the operating system <NUM> for further processing in some examples.

In the illustrated example, a driver <NUM> transfers the data packet from the network interface card <NUM> and stores the data packet in a location at which the operating system <NUM> has access to the packet. In one example, the received data packet is transferred to a buffer within an operating system memory of the computer <NUM>. Thus, the driver <NUM> controls the network interface card <NUM>. The driver <NUM> moves data packets received by the network interface card <NUM> into a buffer managed by the operating system of the computer <NUM>. Each successive layer within the network stack then processes the data packet by reading and/or modifying this buffer. As each layer finishes processing, the layer signals the next layer to begin processing. In the illustrated embodiments, the ETH processing module <NUM> processes the packet to determine compliance with the requirements of the ethernet protocol layer, an IP processing module <NUM> processes the packet to determine compliance with the requirements of the IP protocol layer, a UDP processing module <NUM> processes the packet to determine compliance with the requirements of UDP, and a QUIC processing module <NUM> processes the packet to determine compliance with the requirements of QUIC. It should be appreciated that other checks may be performed, such as checking a packet to determine whether the packet has a header indicating that the packet was sent from a IP-address that is a permitted source of packets and/or whether the data packet was sent using the QUIC transport protocol. Other similar checks may be performed to determine whether a received packet complies with requirements of a layered protocol.

In one example, at each step in the processing, a determination is made whether the packet complies with the requirements of a specific protocol in the layered protocol. If the processing determines that the packet does not comply with the requirements of the protocol, the packet may be discarded. Alternatively, error detection or error recovery steps may be performed. However, if compliance with all protocol layers is validated, the data from the packet may be passed on to an application within the computer <NUM> or otherwise utilized. In the example of <FIG>, the UDP protocol layer is the last layer for which validation is performed and data is passed to an application when processing in accordance with UDP is completed.

<FIG> illustrates an example of a data structure <NUM> (defining a data packet) that may exist in the memory of the computer <NUM> following receipt of a data received packet by the network interface card <NUM>. The data structure <NUM> includes fields that store information used for processing the packet. In this example, the data structure <NUM> generally includes an Ethernet header <NUM>, an IP header <NUM>, a UDP header <NUM> and a body defined by a QUIC payload <NUM>. As should be appreciated, the QUIC payload is encrypted.

Additionally, in the illustrated example, the data structure <NUM> includes an authenticated data portion, illustrated as a QUIC plaintext <NUM> (an unencrypted portion), as well a QUIC header <NUM>. The QUIC plaintext portion <NUM> is a portion of the header that is visible to the network, while the QUIC payload <NUM> is not visible to the network. In various embodiments, the QUIC packet header (i.e., QUIC header <NUM>) is always unencrypted. The remainder of the packet is the encrypted payload. Inside the packet payload, there are one or more frames, each with a header and optionally a payload. In various examples, the key used for the encryption depends on the type of packet header (static version specific for 'cleartext' long headers, TLS determined for short headers and <NUM>-RTT for long headers).

Various examples use information within the data structure <NUM> to perform hardware offloading, which includes having a single call to perform the offloaded functions. In QUIC, encryption is performed at the transport layer and an example protocol stack <NUM> is illustrated in <FIG>. The stack <NUM> includes an IP layer <NUM>, a UDP layer <NUM>, a QUIC layer <NUM> and an HTTP/<NUM> layer <NUM>, in that order. It should be noted that transport layer security (TLS) <NUM> is also provided, which in one example is included as part of the QUIC layer <NUM>. As should be appreciated, QUIC makes the HTTP <NUM> layer smaller and subsumes some of the functionality of HTTP <NUM>, TCP and TLS within the QUIC layer <NUM>, including stream multiplexing and prioritization. Moreover, because encryption is performed at the transport layer, the QUIC headers are encrypted as data packets are transmitted across the network using UDP. The QUIC transport protocol thereby provides an end-to-end secure protocol. It should be noted that in some examples, QUIC over HTTP <NUM> is used.

Thus, QUIC runs on top of UDP sockets and in various examples uses TLS <NUM> for encrypting data. QUIC also uses specific headers and subsumes some parts of HTTP/<NUM>. According to various examples as described in more detail herein, QUIC delivers TCP-like reliability, while supporting <NUM>-RTT and stream multiplexing, and is tamper proof and secure.

In one example, a set of operations are performed in hardware instead of software. In particular, RSS, LSO, RSC and crypto offload are all performed in hardware instead of in software in some examples, each of which will be described below.

More particularly, with respect to RSS and as illustrated in <FIG>, data traffic <NUM> comes in (i.e., is received) on different connections <NUM> to different connection sockets <NUM>. However, in some examples, such as when a particular socket is identified with a specific CID, all of a data stream being transmitted is received through a single socket <NUM> (i.e., because a single object is defined for a particular port, multiple streams of data or a large amount of data packets can be received at the single port). This data traffic is spread across multiple CPUs <NUM>, such as by hardware operations performed in a network interface card <NUM>, which may be embodied as the network interface card <NUM> (illustrated in <FIG>). In one example, the network interface card <NUM> uses the CID or the CID and a <NUM>-tuple value of data packet IP address as an identifier.

One example of a defined <NUM>-tuple is shown in <FIG>. The <NUM>-tuple is defined by values at predefined address positions <NUM> within the source IP address <NUM> and the destination IP address <NUM>, and in some examples, is used in combination with a CID <NUM> (located within the QUIC plaintext portion <NUM> of the data structure <NUM> shown in <FIG>) for hashing operations. However, in some examples, the CID <NUM> is the sole value used for hashing operations or other control operations.

The values represent a key used to spread the traffic across the CPUs <NUM>. For example, the CID or the <NUM>-tuple in combination with the CID is used as an identifier to seed to a hashing algorithm to select a CPU <NUM> for output of data packets thereto. Thus, the network interface card <NUM> uses either the CID or a combination of the CID and the <NUM>-tuple to generate a value using the hashing algorithm, which will then be used to spread data packets across the CPUs <NUM> (e.g., to select specific CPUs for processing certain data packets). Thus, in some examples, only the CID is used. However, in other examples, such as when using multiple servers, the CID is used in combination with the <NUM>-tuple. In still other examples, the CID is used in combination with a <NUM>-tuple.

In some examples, a QUIC stream ID may be used to perform the hash (after decrypting the QUIC packet) and generate a value to spread the packets across the CPUs <NUM>. In this case, instead of each packet being sent to a CPU <NUM> corresponding to the hashed value, a data stream is sent instead. It should be noted that the stream ID is located in the encrypted portion of the data structure <NUM> shown in <FIG> (that includes the cyphertext and the stream ID). Each stream in some examples is a different data stream, such as different video streams, such that each video stream is processed by a different CPU <NUM>.

Thus, in operation, the hashing algorithm uses the CID D value or the <NUM>-tuple value in combination with the CID value to generate a value representative of the CPU <NUM> to which the data packet should be sent for processing. For example, the hashing algorithm uses a hash table (e.g., hash map) that maps keys (defined by the CID or the CID + <NUM>-tuple value) to values for selecting CPUs <NUM> for data packet processing. In one example, the hash table uses hash functionality technology to compute an index into an array of buckets or slots, from which the output value is determined.

It should be noted that in some examples, the hardware offload is performed using a <NUM>-tuple instead of a <NUM>-tuple. It also should be noted that using the CID provides a fail over in the event of a failure. For example, if a connection fails over, different <NUM>-tuple information is used, but the CID remains the same, thereby providing consistent hashing.

Thus, various examples perform RSS using QUIC header fields. QUIC headers include QUIC specific fields, such as the CID and stream ID used to more effectively spread traffic on the host between CPUs as described herein. The CID field in QUIC also allows for the connection to migrate from one network to the other. For example, if the client roams from a Wi-Fi network to a cellular network, then the CID allows the client and server to preserve the connection even if the local IP address and port change, which is not possible with TCP. The Stream ID field also allows QUIC to multiplex multiple streams in the same connection. If RSS is performed using the stream ID, a single QUIC connection can be processed on multiple cores and single connection performance is able to be scaled. It should be noted that because the CID field is present without decryption, RSS does not depend on crypto offload when using the CID field. However, the Stream ID is in the encrypted portion, so RSS on this field includes decryption and hence depends on crypto offload.

Regarding crypto offload, various examples perform a stateful offload, wherein the CID and the <NUM>-tuple is associated with a symmetric key and a crypto algorithm. Thus, instead of using asymmetric cryptography (such as a Rivest-Shamir-Adleman (RSA) public-key cryptosystem), wherein an asymmetric key is generated, a symmetric crypto (e.g., Advanced Encryption Standard (AES), Galois/Counter Mode (GCM) or ChaCha/Poly crypto) is performed and offloaded to hardware, such as to the network interface card <NUM>. In one example, AES-GCM functionality is offloaded to the network interface card <NUM> to be completed in hardware.

In particular, with respect to the stateful offload, in one example, the following is performed:.

Thus, hardware, which is this example is the network interface card <NUM>, is programmed up-front (instead of being performed in software), which is after the initial connection handshake is performed in some examples. If the network interface card <NUM> supports a given QUIC version number, in various examples, the network interface card <NUM> supports encrypting/decrypting the handshake packets, which are encrypted with a static, version specific key. This is independent of the specific connection the packet applied to.

In one example, once connection is established, the network interface card <NUM> is programmed as described above (i.e., the programming portion). In QUIC, unlike TCP, each packet is a TLS packet, such that each packet is decryptable on its own (e.g., decryptable on the fly). As a result of the crypto offload, various examples are able to perform the software offload of the RSS, LSO and RSC operations as described herein. Thus, in QUIC, the TLS record is exactly the same size as the QUIC packet. As such, even if packets are reordered, the packets can be decrypted independently. The hardware can decrypt on the fly, with the data packets being later reassembled. In TCP, the data packets can arrive out of order and, thus, sequence number tracking and buffering of packets would need to be performed.

Variations and modifications are contemplated by the present disclosure. For example, on the send side, instead of encrypting a portion of the QUIC packet in software, the portion can be provided in cleartext (i.e., non-encrypted data) and sent to hardware. In this case, the network interface card <NUM> performs packet segmentation and encrypts the individual segmented packets. Thus, in addition to having only one call to send a data packet, encryption does not have to be performed.

As should be appreciated, the crypto offload is a stateful offload. In operation, in one example, when the network interface card <NUM> binds to the network stack (e.g., the stack <NUM>), the network interface card <NUM> advertises all the TLS cypher suites that the network interface card <NUM> supports. The network interface card <NUM> also advertises the maximum number of connections the network interface card <NUM> can support for crypto offload. The cypher suite in one example is a combination of authentication algorithms and encryption algorithms. As a particular example, the network interface card <NUM> advertises support for AES GCM <NUM>, AES GCM <NUM>, ChaCha-poly and SHA-<NUM> algorithms. The network stack then has the information to decide if a connection can be offloaded to the hardware using a subset of the crypto algorithms.

In one example, once a QUIC connection is established and <NUM>-rtt (symmetric crypto) key has been negotiated (e.g., using TLS <NUM>), the network stack offloads the information about the QUIC connection to the network interface card <NUM>. The following details are programmed in one example:.

It should be noted that in some examples, <NUM>-RTT crypto offload similarly is provided.

The network stack keeps track of how many connections have been offloaded for crypto. If the number of offloaded connections is less than a maximum value, a new connection can be offloaded to the network interface card <NUM> by programming the information in the list above.

Once the connection is offloaded, all subsequent sent and received packets for this connection are encrypted and authenticated in hardware. This process saves CPU cycles. The packets are then processed as plain text in the network stack.

The network interface card <NUM> will also keep track of the latest packet number processed on transmit and receive operations so the network interface card <NUM> can correctly encode/decode the packet number and use the number as part of encryption/decryption.

Similar to offload, any connection can be "uploaded" (i.e., revoked from hardware offload) by the network stack at any time. For example, if the connection is closed for any reason or the connection migrates, then the network stack can upload the connection by specifying the following details:.

It should be appreciated that that the crypto offload can run the portion of the network driver that uses the symmetric key in a secure virtualization enclave (e.g., VSM virtual secure mode). This process supports scenarios that do not trust the network driver code to give access to the encryption keys.

Optionally the network interface card <NUM> can also decrypt the connection handshake and stateless reset packets using static keys that are QUIC version specific. In one example, the connection handshake uses static version specific keys that the network stack can program to the driver. Similarly, for an offloaded connection that has closed locally, the network stack can program the key for generating a stateless reset packet in response to any received packet for the matching connection. The network stack then uploads the connection after the duration for which the stack needs the hardware to keep generating stateless reset packets.

It also should be appreciated that various examples provide version support advertisement and enablement. For example, when the network interface card <NUM> binds to the network stack, the network interface card <NUM> advertises all the QUIC versions the network interface card <NUM> supports in the format, a set of ranges and specific values. For example, if the network interface card <NUM> supports versions <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> and <NUM>, the network interface card <NUM> advertises <NUM>, <NUM>-<NUM>, <NUM>. Depending on the operating system configuration and network stack version, the operating system programs a subset of versions to offload. As one example, the network stack could only require support for the latest version <NUM> so the network stack enables offload of version <NUM> on the network interface card <NUM>. If the network interface card <NUM> receives or sends any QUIC version other than the ones enabled, no offloads are performed, and the packets are passed unmodified in both directions (send and receive).

<FIG> illustrates a batch application programming interface (API) for LSO and <FIG> illustrate an RSC combining process for QUIC that can be performed when the above-described crypto offload is performed. In particular, a network interface card <NUM> performs a chopping operation on a data packet <NUM> that chops the data packet <NUM> into a plurality of smaller data packets <NUM> when the data packet <NUM> is too large to be sent over the network (e.g., exceeds the maximum data packet size configured by the operating system, such that the operation system performs the path maximum transmission unit (PMTU) discovery). Each of the data packets <NUM> are individually encrypted before being transmitted. This can be performed because the crypto offload allows the network interface card <NUM> to access the payload portion <NUM> of the data packet <NUM> and split/chop the payload portion <NUM> into smaller payload portions <NUM> in the data packets <NUM> (e.g., 64kB into <NUM>-byte data packets).

The chopping is performed based on a single call to the network interface card <NUM> to generate the data packets <NUM>, instead of separate calls to generate each data packet <NUM>. A single large packet is thus sent to the network interface card <NUM>, such that hardware generates the individual data packets <NUM> from the data packet <NUM>. As such, with the crypto offload, various examples perform LSO to split up (chop) QUIC packets on transmit using a batch API process.

It should be noted that the LSO offload is dependent on the QUIC crypto offload in various examples. Bulk connections transmit a lot of QUIC packets with just one frame type: the stream which describes a set of contiguous bytes for a stream. On the transmit path, crypto offload allows the network stack to generate a large plaintext QUIC packet (larger than maximum transmission unit (MTU) size) with just the stream frame. Hence this offload is effectively a Large Stream Send Offload. The out-of-band (OOB) information in various examples includes the MTU size that the packet needs to be segmented into and the packet number to be used for the first generated packet.

Thus, in operation, the network interface card <NUM> segments the QUIC packet into smaller MTU sized packets (and optionally one smaller than MTU sized packet) and then performs the encryption as part of the crypto offload for each smaller packet. Hence, on the receiver, the packets will show up as the packets would have been generated in the absence of QUIC offloads. The network stack is, thus, able to compute how many packets will be generated and can increment the packet number to be used for further packets correctly. In various examples, LSO offload allows QUIC to match TCP performance on transmit for bulk transfer connections.

It should be noted that checksums are performed in various examples in hardware. For example, the operating system network stack can offload checksum on transmit by setting OOB information on a given packet. On receive, the network interface card <NUM> validates the checksum and sets the OOB information on whether the checksum is valid or not. This saves CPU processing time and improves performance.

Regarding RSC, various examples combine QUIC packets on receive. For example, on the receive side, QUIC data packets are combinable into a single packet, in clear text, and then provided to a receive side application. For example, as shown in <FIG>, the individual data packets <NUM> (that were chopped) are combined into a single data packet <NUM> by a network interface card <NUM>, which can be performed as result of the crypto offload. Similar to the send batch operation, the receive batch operation is performed based on a single call to the network interface card <NUM> (and knowing the packet numbers of the packets received to send an acknowledgement), such that the network interface card <NUM> confirms that the data packets <NUM> are QUIC data packets and that the data flow has been offloaded to the network interface card <NUM>. The data packets <NUM> are then decrypted by the network interface card <NUM> and reassembled into the single data packet <NUM>. It should be noted that the network interface card <NUM> in some examples performs the herein described RSS operation after performing the RSC operation. Again, as should be appreciated, because decryption has already occurred as a result of the crypto offload, the network interface card <NUM> is able to perform the RSC operation. The resulting packet <NUM> is a plain text packet that can be transmitted for further processing or for execution.

It should be noted that the RSC offload is dependent on the QUIC crypto offload. Thus, if a connection is offloaded to the hardware and the packets for the connection are received by the network interface card <NUM>, the network interface card <NUM> will first perform a decryption operation on MTU (or smaller than MTU) packets. Thereafter, since the packets are plaintext and all header information is available, the network interface card <NUM> combines successive QUIC packets (packet numbers in sequence order) that only have a stream frame and stream sequence numbers that are also contiguous. Such a combined QUIC packet can then be indicated in plaintext to the network stack, which can process one packet with more data, instead of multiple packets, hence reducing CPU usage. The RSC offload operation in various examples allows QUIC to match TCP performance on receive for bulk transfer connections.

<FIG> illustrates an exemplary flow chart of a method <NUM> for QUIC hardware offload. In particular, this figure is an exemplary flow chart illustrating operations of a computing device to perform a stateful offload of data packet processing functions to hardware. The operations illustrated in the flow charts described herein may be performed in a different order than is shown, may include additional or fewer steps and may be modified as desired or needed. Additionally, one or more operations may be performed simultaneously, concurrently or sequentially.

In particular, at <NUM>, the computing device, which includes or is coupled to at least one network interface card, is configured to determine the CID for one or more QUIC data packets. For example, as described herein, the CID can be obtained from the QUIC plaintext portion of the QUIC data packet, which is an unencrypted portion. The CID is information provided as part of the QUIC data packet that identifies uniquely the connection being used for communication of the QUIC data packet. It should be noted that in some examples, additional packet information for the QUIC data packet may be obtained, such as a <NUM>-tuple corresponding to the source and destination IP address for the QUIC data packet.

At <NUM>, a programmed network interface card (e.g., a preprogrammed network interface card) of the computing device receives a value for the CID of the QUIC data packet(s) and uses the value to identify a symmetric key and crypto algorithm using a programmed mapping (e.g., a preprogrammed mapping). In one example, a mapping is sent to the network interface card during a programming portion of a stateful offload. The mapping is between (CID, <NUM>-tuple) and (symmetric key, crypto algorithm), which is sent to hardware so that the network interface card is ready to parse the QUIC data packets on receipt. This operation hands off the crypto key and crypto algorithm to the hardware of the network interface card that defines a crypto offload to hardware. In some example, the mapping is between (i) connection information, including the CID, the local IP address and the UDP port and (ii) the symmetric key and the crypto algorithm.

At <NUM>, the hardware of the network interface card performs one of a receive and decrypt operation or an encrypt and transmit operation on the one or more QUIC data packets using the independent symmetric key and crypto algorithm. For example, with the crypto offload performed, a hardware RSS, LSO or RSC can be performed on the one or more QUIC data packets in combination with a transmit operation or a receive operation. Encryption or decryption is can be performed on smaller individual packets in some examples before transmission or after reception as described herein. As should be appreciated, each of the smaller individual packets is a TLS record.

<FIG> illustrates an exemplary flow chart of a method <NUM> for performing specific QUIC hardware offload functions. In particular, this figure is an exemplary flow chart illustrating operations of a computing device to perform software functions in hardware, particularly using a network interface card. At <NUM>, the computing device determines whether the data packets to be processed are QUIC data packets. For example, a version specific QUIC verification process can be used to identify whether the data packets include QUIC data headers. It should be noted that any suitable process may be used within the QUIC protocol to determine whether the packets comply with the QUIC protocol.

If a determination is made at <NUM> that the packets are not QUIC packets, the packets are determined to be UDP packets and processed using UDP processing techniques. It should be noted that the UDP processing may be performed in software or in hardware.

If a determination is made at <NUM> that the packets are QUIC packets, the computing device determines the CID and optionally the <NUM>-tuple values of the source and destination IP addresses of the QUIC data packets. This information defines QUIC packet information used for a crypto offload. In one example, the value of at least the CID is used to perform a crypto offload, such as by associating the CID and optionally the <NUM>-tuple values with a symmetric key and crypto algorithm programmed in the network interface card. Thus, a symmetric crypto (encryption/decryption) operation is performed in hardware instead of in software (such as is performed in TCP processing, for example, at <NUM>).

A determination is made at <NUM> whether a receive call is received by the network interface card. If a receive call is issued, an RSS operation and/or an RSC operation are performed at <NUM>, if needed, and as part of decrypting the QUIC data packets. It should be noted that the decryption is first performed in various examples before the RSS operation or RSC operation is performed. In one example, a receive call indicating the socket as batched, results in the RSC operation combining received QUIC packets into a larger packet as described herein. It should be noted that each of the smaller received QUIC packets are individually decrypted by the network interface card, which are then reassembled. Additionally, RSS may be performed to send the smaller packets to different CPUs for processing in some examples and for larger coalesced packets depending on the processing pipeline of the hardware. For example, so as to not hit a scale limit for the network interface card that could otherwise occur because all of the packets would be sent to a single CPU due to the QUIC transfer protocol, the incoming data packets are sent to different CPUs for processing such as by hashing the CID or by hashing a combination of the CID and the <NUM>-tuple to determine a CPU to use for processing. Thus, multiple CPUs are used in some embodiments for the hardware decrypting of the QUIC data packets, which are then combined in hardware, such as using the RSC operation. Accordingly, the network interface card receives smaller QUIC data packets and assembles or recreates a single larger data packet. The RSC operation is essentially the reverse of the LSO operation, which are both performed in hardware by the present disclosure.

It should be appreciated that in some examples a stream ID is used instead of the CID as described herein. For example, the stream ID is used to perform the hashing (after decrypting the QUIC data packet) and is used to spread the data streams (instead of data packets) for processing among the multiple CPUs.

If a determination is made at <NUM> that no receive call was made, then a determination is made a <NUM> whether a send call has been made. If a send call has been made, then at <NUM> the network interface card performs an LSO operation, as needed, and then encrypts the QUIC data packets for transmission. For example, a single call to UDP is made that results in splitting/chopping a larger data packet into smaller data packets before encryption and transmission as UDP QUIC packets at <NUM>.

With QUIC, each of the smaller data packets is individually encrypted based on the single call to UDP. It should be appreciated that the splitting/chopping operation to generate smaller packets does not use IP fragmentation, but instead chops the larger packet into smaller predefined sized packets (e.g., predetermined byte size packets). That is, the hardware can take large packets on transmit and chop the packets up, such that after encryption the packets are MTU sized UDP QUIC packets, and on receive decrypt the MTU sized UDP packets and then coalesce the packets into one large plaintext packet.

If a determination is made at <NUM> that a send call was not made, then the one or more packets are transmitted to software for processing at <NUM>. In some examples, if the crypto offload fails or if the encrypt or decrypt operation fails, such as if the send or receive call fails (which is equivalent to no send or receive call being made), an error code is generated. Additionally, as part of the fail over, in which the packet is indicated as an "as-is" packet, the operation in then performed in software.

Thus, the present disclosure provides effective and efficient packet processing using a hardware offload. The processing in hardware is programmed to perform operations that otherwise are performed in software.

Various examples are able to advertise QUIC versions supported by the network interface card hardware and then the network stack programs the subset of versions needed for QUIC offload. The network interface card also advertises all the TLS cypher suites that the network interface card supports for encryption and authentication.

In various examples, TLS crypto operations like symmetric key encryption and authentication for QUIC connections are offloaded to the network interface card hardware by programming the mapping of "connection information → {symmetric key, crypto algorithms}. Also, various examples allow for the upload (or terminate / revoke) of the offloaded connection.

In some examples, security technology like VSM can be used for cases where the network interface card driver cannot be trusted with the symmetric key. As such, the portion of the network driver code that needs to access the key is run in the enclave protected by virtualization technology.

Various examples leverage crypto offload to achieve bulk performance offloads like LSO and RSC (i.e., because the network interface card processes QUIC plaintext packets, the network interface card can properly segment one large QUIC packet into smaller MTU sized packets on transmit, and combine multiple smaller packets into one large packet on receive). In some examples, LSO and RSC is supported for packets with just the stream frame type (i.e. data packets).

Various examples also perform RSS based on QUIC header fields (some in clear text and some encrypted) to achieve a more fine-grained spreading of traffic.

The present disclosure is operable with a computing apparatus <NUM> according to an embodiment as a functional block diagram <NUM> in <FIG>. In one example, components of the computing apparatus <NUM> may be implemented as a part of an electronic device according to one or more embodiments described in this specification. The computing apparatus <NUM> comprises one or more processors <NUM> which may be microprocessors, controllers or any other suitable type of processors for processing computer executable instructions to control the operation of the electronic device. Platform software comprising an operating system <NUM> or any other suitable platform software may be provided on the apparatus <NUM> to enable application software <NUM> to be executed on the device. According to an embodiment, QUIC hardware offloading is performed by a network interface card <NUM> using QUIC packet information <NUM> (e.g., a CID value) instead of being accomplished by software.

Computer executable instructions may be provided using any computer-readable media that are accessible by the computing apparatus <NUM>. Computer-readable media may include, for example, computer storage media such as a memory <NUM> and communications media. Computer storage media, such as the memory <NUM>, include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or the like. Computer storage media include, but are not limited to, RAM, ROM, EPROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information for access by a computing apparatus. In contrast, communication media may embody computer readable instructions, data structures, program modules, or the like in a modulated data signal, such as a carrier wave, or other transport mechanism. As defined herein, computer storage media do not include communication media. Therefore, a computer storage medium should not be interpreted to be a propagating signal per se. Propagated signals per se are not examples of computer storage media. Although the computer storage medium (the memory <NUM>) is shown within the computing apparatus <NUM>, it will be appreciated by a person skilled in the art, that the storage may be distributed or located remotely and accessed via a network or other communication link (e.g. using a communication device <NUM>).

The computing apparatus <NUM> may comprise an input/output controller <NUM> configured to output information to one or more input devices <NUM> and output devices <NUM>, for example a display or a speaker, which may be separate from or integral to the electronic device. The input/output controller <NUM> may also be configured to receive and process an input from the one or more input devices <NUM>, for example, a keyboard, a microphone or a touchpad. In one embodiment, the output device <NUM> may also act as the input device <NUM>. An example of such a device may be a touch sensitive display. The input/output controller <NUM> may also output data to devices other than the output device <NUM>, e.g. a locally connected printing device. In some embodiments, a user may provide input to the input device(s) <NUM> and/or receive output from the output device(s) <NUM>.

In some examples, the computing apparatus <NUM> detects voice input, user gestures or other user actions and provides a natural user interface (NUI). This user input may be used to author electronic ink, view content, select ink controls, play videos with electronic ink overlays and for other purposes. The input/output controller <NUM> outputs data to devices other than a display device in some examples, e.g. a locally connected printing device.

The functionality described herein can be performed, at least in part, by one or more hardware logic components. According to an embodiment, the computing apparatus <NUM> is configured by the program code when executed by the processor(s) <NUM> to execute the embodiments of the operations and functionality described. For example, and without limitation, illustrative types of hardware logic components that can be used include Field-programmable Gate Arrays (FPGAs), Application-specific Integrated Circuits (ASICs), Program-specific Standard Products (ASSPs), System-on-a-chip systems (SOCs), Complex Programmable Logic Devices (CPLDs), Graphics Processing Units (GPUs).

At least a portion of the functionality of the various elements in the figures may be performed by other elements in the figures, or an entity (e.g., processor, web service, server, application program, computing device, etc.) not shown in the figures.

Examples of well-known computing systems, environments, and/or configurations that may be suitable for use with aspects of the disclosure include, but are not limited to, mobile or portable computing devices (e.g., smartphones), personal computers, server computers, hand-held (e.g., tablet) or laptop devices, multiprocessor systems, gaming consoles or controllers, microprocessor-based systems, set top boxes, programmable consumer electronics, mobile telephones, mobile computing and/or communication devices in wearable or accessory form factors (e.g., watches, glasses, headsets, or earphones), network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like. In general, the disclosure is operable with any device with processing capability such that it can execute instructions such as those described herein. Such systems or devices may accept input from the user in any way, including from input devices such as a keyboard or pointing device, via gesture input, proximity input (such as by hovering), and/or via voice input.

A system for hardware offloading, the system comprising:.

The system described above, wherein the network interface card is configured to use the CID to perform a receive side scaling (RSS) operation.

The system described above, wherein the network interface card is configured to use the CID to perform a receive segment coalescing (RSC) operation.

The system described above, wherein the computer program code is further configured to, with the at least one processor, cause the at least one processor to send one or more packets to be transmitted over the network to the network interface card, wherein the network interface card is further configured to:.

The system described above, wherein the network interface card is configured to use the CID to perform a large send offload (LSO) operation.

The system described above, wherein the network interface card is configured to chop up the one or more QUIC data packets using a process that does not result in IP fragmentation.

The system described above, wherein the wherein the computer program code is further configured to, with the at least one processor, cause the at least one processor to offload one of an Advanced Encryption Standard (AES), Galois/Counter Mode (GCM) or ChaCha/Poly crypto to the network interface card as part of a crypto offload.

The system described above wherein the network interface card is configured to use the CID and a <NUM>-tuple of source and destination addresses to perform the crypto decrypt operation.

A computerized method for hardware offloading, the computerized method comprising:.

The computerized method described above, further comprising performing, by the network interface card, a receive side scaling (RSS) operation using the CID when receiving the one or more QUIC data packets.

The computerized method described above, further comprising performing, by the network interface card, a receive a segment coalescing (RSC) operation using the CID when receiving the one or more QUIC data packets.

The computerized method described above, further comprising performing, by the network interface card, a large send offload (LSO) operation using the CID when transmitting the one or more QUIC data packets.

The computerized method described above, further comprising performing, by the network interface card, chopping up the one or more QUIC data packets, using a process that does not result in IP fragmentation, before transmitting the one or more QUIC data packets.

The computerized method described above, further comprising offloading one of an Advanced Encryption Standard (AES), Galois/Counter Mode (GCM) or ChaCha/Poly crypto to the network interface card as part of a crypto offload.

The computerized method described above, further comprising using the CID and a <NUM>-tuple of source and destination addresses to perform the crypto decrypt operation.

One or more computer storage media having computer-executable instructions for hardware offloading that, upon execution by a processor, cause the processor to at least:.

The one or more computer storage media described above, wherein the network interface card is configured to perform receive side scaling (RSS) using the CID when receiving the one or more QUIC data packets.

The one or more computer storage media described above, wherein the network interface card is configured to perform a receive segment coalescing (RSC) operation using the CID when receiving the one or more QUIC data packets.

The one or more computer storage media described above, wherein the network interface card is configured to perform a large send offload (LSO) operation using the CID when transmitting the one or more QUIC data packets.

The one or more computer storage media described above, wherein the network interface card is configured to perform chopping up the one or more QUIC data packets, using a process that does not result in IP fragmentation, before transmitting the one or more QUIC data packets.

The one or more computer storage media described above, wherein the computer-executable further cause the processor to at least offload one of an Advanced Encryption Standard (AES), Galois/Counter Mode (GCM) or ChaCha/Poly crypto to the network interface card as part of a crypto offload, and use the CID and a <NUM>-tuple of source and destination addresses to perform the crypto decrypt operation.

The embodiments illustrated and described herein as well as embodiments not specifically described herein but within the scope of aspects of the claims constitute exemplary means for training a neural network. The illustrated one or more processors <NUM> together with the computer program code stored in memory <NUM> constitute exemplary processing means for using and/or training neural networks.

In some examples, the operations illustrated in the figures may be implemented as software instructions encoded on a computer readable medium, in hardware programmed or designed to perform the operations, or both. For example, aspects of the disclosure may be implemented as a system on a chip or other circuitry including a plurality of interconnected, electrically conductive elements.

Claim 1:
A system (<NUM>) for hardware offloading, the system (<NUM>) comprising:
a plurality of processors (<NUM>);
a network interface card (<NUM>); and
at least one memory comprising computer program code, the at least one memory and the computer program code being configured to:
program the network interface card (<NUM>) with a mapping between (i) a connection identification (CID) for one or more QUIC data packets and (ii) a symmetric key and a crypto algorithm;
receive one or more data packets over a network,
parse the one or more data packets to identify the one or more data packets as QUIC data packets and then obtain the CID for the QUIC data packets,
send the CID to the network interface card (<NUM>), wherein the network interface card (<NUM>) is configured to:
identify the symmetric key and the crypto algorithm based on the CID;
select one or more processors (<NUM>) of the plurality of processors (<NUM>) to process the QUIC data packets, the one or more processors (<NUM>) being selected using a mapping in a hash table based on the CID,
process the QUIC data packets using the selected one or more processors (<NUM>), the processing comprising performing a crypto decrypt operation on the QUIC data packets, and reassembling the QUIC data packets, and
receive the reassembled QUIC data packets from the network interface card (<NUM>).